Hi, I've been using psmux lately for Claude Code with Agent Teams. I don't know Rust at all (all my experience is web code), so I was hesitant to make an issue until Claude tried a fix, and then I rebuilt psmux and the symptom was fixed.

My current setup: Windows 11, PowerShell 7, Windows Terminal, basic config (from your docs for use with Claude Code). I built the psmux binary from the latest commit as of today (May 24th). Some of this report is gonna be pasted from what Claude said. Hopefully this explains the issue clearly, if not let me know and I can relay anything you need

Repo steps:

1. Open a fresh Windows Terminal tab.
2. Run psmux to start a new session.
3. Wait 10+ seconds (rules out PSReadLine cold-start as cause).
4. Press any key OR Ctrl+V paste any text.

Expected: input appears intact.
Actual: first character missing; bell ding; second character onward intact.

Real-world impact: breaks Claude Code agent-team worker spawning. The team-leader's flow is split-window followed by send-keys "cd 'F:\...' && env ... && claude.exe ..." into the freshly-spawned worker pane. The leading c of cd is consumed by the same bug, so the worker pane runs d 'F:\...' and immediately errors with 'd' is not recognized as the name of a cmdlet. The worker never starts and the lead silently hangs waiting for it.

Suspected cause

conpty_preemptive_dsr_response() at src/pane.rs:28-31 writes a raw VT cursor-position-report (\x1b[1;1R, 6 bytes) to the ConPTY input pipe immediately after pane creation. Called from 5 sites: src/window_ops.rs:1315, src/pane.rs:169, src/pane.rs:233, src/pane.rs:285, src/pane.rs:441, and src/popup.rs:88.

The ConPTY is created with PSEUDOCONSOLE_WIN32_INPUT_MODE as a base flag (crates/portable-pty-psmux/src/win/psuedocon.rs:127 and :177), which interprets the input pipe as Win32-input-mode escape sequences of the form \x1b[Vk;Sc;Uc;Kd;Cs;Rc_ - note the underscore terminator. (Exactly the format used by the recent #305 / 60e1714 Ctrl+letter fix.)

\x1b[1;1R shares the \x1b[ prefix and digit-semicolon parameter shape but terminates with R instead of _. Plausible failure mode: the ConPTY input parser begins assembling a key event, hits an unexpected terminator, and is left in an inconsistent half-state until the next byte arrives - which is the user's first keystroke, consumed as the malformed sequence's terminator. PSReadLine receives nothing useful, calls Ding().
Symptom fingerprint that fits this hypothesis:

• 10-second wait still loses the byte (the parser's half-state persists; not a timing race).
• Paste loses its first byte too (bracketed-paste header \x1b[200~ shares the same prefix and trips the same trap; cold-start theories can't explain this).
• Only the first byte is ever lost (the parser unsticks once any byte completes the failed parse).
• Bell every single time, never intermittent.

Confirmation

Locally patched src/pane.rs::conpty_preemptive_dsr_response to a no-op (all 5 call sites become inert with one edit) and rebuilt --release. First-byte-eaten + bell are both gone across fresh sessions, manual splits, and send-keys-driven Claude Code worker spawns. No regressions observed (blank prompts, ConPTY hangs, missing cursor, etc.) on Windows 11 build 26200 with PSEUDOCONSOLE_PASSTHROUGH_MODE active. Happy to test any conditional or format-corrected upstream fix.

Suggested fix

Either skip the DSR response when the ConPTY is in Win32 input mode (likely always on this codebase, per psuedocon.rs:127/:177), or emit it as a valid Win32-input-mode key-event sequence with the underscore terminator, or inject a synthetic cursor-position event via WriteConsoleInputW directly. The original code (72b7998) was written against older portable-pty (≤0.2) - newer ConPTY in Win32 input mode may no longer emit the DSR query at all, making the pre-emptive response either unnecessary or actively harmful.

Environment

• Windows 11 Pro, build 26200
• psmux at HEAD (60e1714 Win32 input mode for Ctrl+letter keys)
• PowerShell 7 default shell
• Windows Terminal
• Default config plus escape-time 0, claude-code-fix-tty on