Summary

Two symptoms observed in psmux since commit 6bcb9f5 (2026-04-10), both absent before it:

1. Cursor-ahead-of-chars. During fast typing, the cursor visibly advances on screen while the typed characters lag behind by 200–500ms, then catch up.
2. Typing freeze. Periodic 200ms–1s windows where cursor and input both stop responding, then catch up at once.

Both symptoms disappear simultaneously on the parent commit 3e61a0d, supporting a single root cause.

Previously investigated in #233 under a "ConPTY splits PSReadLine's atomic repaint" hypothesis. That framing is now suspect — the bisect lands on 6bcb9f5, which doesn't change any ConPTY or PSReadLine interaction.

Bisect result

• b68962b (2026-03-28) — works
• 44f061d (2026-04-08, PR fix: bounded frame push prevents copy-mode scroll memory leak #190 merge) — works
• b91542d (2026-04-08 pre-fix: bounded frame push prevents copy-mode scroll memory leak #190) — works
• 3e61a0d (2026-04-10 01:53, parent) — works
• 6bcb9f5 (2026-04-10 02:28) — reproduces both symptoms
• e20630b (2026-04-15, pre-PR fix: bounded frame channel to preserve fast typing #225) — still reproduces
• master a138a9e — still reproduces

Single-commit delta: 6bcb9f5 "Adopt scroll_pane_scrollback approach from PR #194" (author: Josh, credit: @jun2077681).

What the commit changes

• src/copy_mode.rs — extracts scroll_pane_scrollback() helper. scroll_copy_up/scroll_copy_down now split their parser-mutex hold into two separate acquisitions with a window in between.
• src/input.rs / src/window_ops.rs — mouse scroll events route to scroll_pane_scrollback when scroll-enter-copy-mode is off.

Leading hypothesis

The split parser-mutex hold in scroll_copy_up/scroll_copy_down is the most likely cause. Both symptoms could follow from a PTY reader touching parser state during the window between the two lock acquisitions:

• Cursor-ahead: server snapshots the parser mid-update, publishes a frame where cursor is advanced but cells not yet written.
• Freeze: PTY reader contends on the lock under scroll activity, new output doesn't reach vt100 for a window, nothing changes on screen.

The obvious secondary hypothesis (a stray scroll event silently shifts scrollback via the new scroll_pane_scrollback path) doesn't fully account for the symptom — scroll-enter-copy-mode defaults to true, so that shortcut isn't taken on default configs.

Repro

• Attach to a psmux session.
• Type at fluent human pace, or mash keys randomly fast.
• Observe periodic 200ms–1s freezes that self-recover, or cursor advancing ahead of visible characters.

Doesn't repro:

• Raw pwsh (no psmux).
• Pre-6bcb9f5 builds.

Environment (confirmed unchanged in last 2 weeks, so not an env regression)

• PSReadLine 2.4.5 (installed 2026-03-17)
• Windows Terminal 1.23.20211.0 (installed 2026-01-27)
• pwsh 7.x
• Originally observed over RDP, reproduces locally too.