AskUserQuestion: mouse clicks are silently discarded in the preview (two-column) layout
Clicking an option in an AskUserQuestion that uses preview never selects it. Arrow keys and Enter work normally, and the plain stacked layout (no preview on any option) clicks fine.
Environment: Claude Code 2.1.220, native install, macOS (Darwin 25.5.0), iTerm2, terminal 36x130.
Reproduction
Call AskUserQuestion with four options, each carrying a preview string. The TUI switches to the two-column layout: option list on the left, preview pane on the right, press n to add notes underneath.
Test 1:
- Click option 3
- Press Enter
Expected option 3. Got option 1.
That result on its own is ambiguous, since a click mis-landing on row 1 and a click dropped entirely (leaving focus on the default first option) both produce it. A second test separates them:
Test 2:
- Click option 3
- Press Down once
- Press Enter
If the click had registered on row 3, Down would give option 4. Got option 2, so focus never left option 1 and Down walked it 1 to 2. The click is discarded rather than mapped to the wrong row.
Both tests used four options whose preview text was individually numbered, so the arriving answer identifies the row that was actually selected.
Ruled out below the application layer
The terminal reports mouse input correctly. A standalone reader enabling mode 1003 with SGR 1006, run in the same iTerm2 profile, logs motion, press, and release events, with every press/release pair landing on identical col/row and all coordinates plausible. iTerm2's Mouse Reporting is true on the active profile.
One further observation, offered as a lead rather than a conclusion: under --debug, five repaints (High write ratio: blit=0, write=1508, screen=36x130) appear while the question is on screen, spaced 1.7s, 0.9s, 0.6s and 0.5s apart. Irregular spacing does not match a fixed-interval spinner, so these may be the clicks arriving and re-rendering the component without a state change. I could not confirm that, because mouse, input, tui, keyboard and render are not valid --debug categories despite appearing as quoted strings in the bundle, and no mouse events are logged under any filter.
Impact
The failure is silent and reads as a hang rather than as rejected input, since nothing on screen changes and no error appears. Every question that uses preview costs a fallback to the keyboard.
Related: #76616 reports the inverse (a focus click unintentionally selecting an option). The surrounding issues (#71547, #72614, #70685, #75599) all describe clicks firing when unwanted. I could not find an existing report of the two-column layout swallowing them.