AskUserQuestion keyboard input is unreliable when options include preview (side-by-side layout)

Confirming this on Linux + tmux (issue is currently labelled platform:wsl only), on the current latest build — with one variant worth recording: the mouse is dead too, not just the keyboard.

Environment

• Claude Code 2.1.217 (npm latest)
• Ubuntu, kernel 6.8.0 · tmux 3.6a · TERM=xterm-256color · pane 111x63
• "tui": "fullscreen"
• tmux: escape-time 10, focus-events off, extended-keys off, mouse off — Claude Code enables mouse reporting itself and tmux forwards it (pane reports mouse_any_flag=1)

Symptom

One question, 3 single-select options, each with a multi-line preview → side-by-side layout.

Whenever preview is present the picker is completely inert. From the first deliberate keypress until it suddenly wakes up, nothing registers — no arrow keys, no Enter, no number keys, no mouse click, no hover highlight. This is not intermittent flakiness inside an otherwise working picker: it is a solid dead window that ends on its own after repeated attempts, and from that moment the same picker behaves completely normally for the rest of its life.

Pickers without preview in the same sessions are never affected, so the two layouts are cleanly separable on this machine.

Ruled out on this box

• Not the focus-event class (#75273, #70178): tmux focus-events is off, so focus-in/out is never forwarded into the pane, and the wedge occurs with no app/tab switch at all.
• Not escape-time: it is 10, not the 500ms default.
• Not load starvation as in #78788: 32-core machine, load ~22, the claude processes are not CPU-starved.

The only variable that correlates here is the presence of preview, which matches this report exactly.

Likely the same root cause

• #78306 — "3 options, each with a multi-line preview"; mouse and keyboard both unresponsive; user had to reject the tool call
• #79325 — 2.1.215, keyboard dead mid-session on an interactive picker
• #73932 — option chip intermittently fails to register a click

Open since 2.1.187 with no changelog entry through 2.1.217. Since the side-by-side preview renderer is the only differentiator between working and broken pickers, would it be possible to review its input handling specifically?

Minimal repro, in case it helps pin down the input handler — this triggers it reliably here:

Ask Claude to call AskUserQuestion with one single-select question whose options each carry a multi-line preview, e.g.

{"questions": [{
  "question": "Pick one",
  "header": "Repro",
  "multiSelect": false,
  "options": [
    {"label": "A", "description": "first",  "preview": "line 1\nline 2\nline 3\nline 4"},
    {"label": "B", "description": "second", "preview": "line 1\nline 2\nline 3\nline 4"},
    {"label": "C", "description": "third",  "preview": "line 1\nline 2\nline 3\nline 4"}
  ]}]}

Dropping preview from the three options (everything else identical) makes the picker keyboard- and mouse-driveable again, which is the cleanest A/B I have.

Label request: this is currently tagged platform:wsl, but it is not WSL-specific — the report above is native Linux (Ubuntu 6.8) with tmux 3.6a, and #78306 / #79325 are macOS (PyCharm terminal and Apple Terminal, the latter with no tmux at all). Could the platform label be widened or dropped so platform-filtered triage doesn't skip it?

The focus-change trigger can't be focus events — the CLI never subscribes to them

On 2.1.220 the CLI never enables focus reporting. Captured off the pty with
tmux pipe-pane -O, the complete block it emits on a keystroke is:

ESC(B SI ESC[?1000h ESC[?1002h ESC[?1003h ESC[?1006h

Mouse modes only — no ESC[?1004h, in either a healthy or a wedged session. So a
terminal's focus-in/out sequences are parsed as unknown CSI and discarded; they
can't be what wedges the picker. Matches the report above that reproduced it with
tmux focus-events off.

Previews alone also didn't reproduce for me: the minimal repro from this thread
(1 question, 3 options, 4-line previews) rendered the side-by-side layout and
arrows worked 5/5 in plain tmux on 2.1.220. The second factor is real — it just
isn't focus delivery.

Signature of a wedged instance

Linux, tmux 3.6a, 2.1.220, alternate screen. Picker had previews.

• Renderer fully alive — a resize produced an 11,974-byte correct repaint.
• Input read and discarded — idle, it emits zero bytes; every input byte

produces exactly the 36-byte mode block above and nothing else.

• Dead for everything: Down as tmux named key, raw CSI B, SS3 B, a

printable char, and SGR mouse-motion reports. Attaching a real tmux client and
typing raw arrows into its pty didn't help either.

• Process healthy: main thread in do_epoll_wait, termios byte-identical to a

working pane.

It painted but never committed

The wedged ask was rendered on screen but never written to the session
transcript, while an earlier AskUserQuestion in the same turn was written
normally and answered fine.

So the failure lands after paint, on a path that also does the transcript commit —
consistent with an exception in a continuation doing both the commit and the
input-handler binding, leaving a painted-but-unbound dialog. #84489 may be the
same thing with a trace attached (VirtualMessageList: itemKeys/messages length
desync).

Checking it

tmux pipe-pane -t <pane> -O 'cat > /tmp/x.raw' # idle 20s -> expect 0 bytes
tmux send-keys -t <pane> Down # 36 bytes + no repaint = wedged
grep -c '1004h' /tmp/x.raw # 0 -> focus reporting is off

(Probing trap: Up on the first option legitimately doesn't move, which reads as
a false wedge.)