[BUG] Terminal TUI: AskUserQuestion silently replaces prompt box while user types from scrollback — Enter submits pre-focused option, typed text discarded

Preflight Checklist

• [x] I have searched existing issues — #45374 (open) and #28722 (closed stale) describe the same keystroke-capture class for the VS Code extension; #37955 (closed) for permission modals. This report covers the terminal TUI variant, which has no dedicated issue. Filed per the stale-bot's instruction on #28722 to open a new issue if still relevant.
• [x] This is a single bug report
• [x] Reproduced on the latest version (2.1.228)

What's Wrong?

In the terminal TUI, when an AskUserQuestion menu renders while the user is reading scrollback and typing a reply, the menu silently consumes the input: typed characters are swallowed, and the first Enter submits the pre-focused first option. The user gets no signal that a modal took ownership of the keyboard.

The precise sequence (as experienced):

1. Send a prompt that will generate an option menu after a long assistant answer.
2. Scroll back to read the long answer and start typing a response before the menu is presented.
3. When the menu renders, the prompt box closes — but the screen does not scroll forward, so nothing visible changes in the viewport.
4. Mid-typing, a number or Enter keystroke is routed to the menu. The box "blinks" and returns to its pre-keystroke appearance — easy to miss entirely.

Result: an option is selected while typing, without noticing. No focus-stealing bug is even required — the silent prompt-box replacement plus default-focused first option plus Enter-to-submit is sufficient on its own.

Real-world impact

This is not theoretical. In our session (2026-08-14), an AskUserQuestion asking authorization for a bulk security operation (31 items) recorded its first option — "(Recommended)", the mutating action — two minutes after rendering, while the operator was still reading the explanation above it and typing a reply. The agent executed the batch on that false authorization. The session transcript stores only the resolved answer (no input telemetry), so the misfire was indistinguishable from a deliberate selection.

Controlled reproduction

We then reproduced it deliberately with a throwaway 4-option menu (options labeled to identify which keystroke was captured):

• User scrolled up, typed a sentence containing a digit, pressed Enter.
• Recorded answer: option 1 (pre-focused).
• The typed sentence was silently discarded (not routed to the Other free-text field).
• The digit did not move the selection — only Enter registered, submitting the default.

Expected Behavior

One or more of:

• The menu should not accept Enter as submission until the user has explicitly interacted with it (arrow key, digit, click) at least once.
• Printable characters typed at the menu should route into the Other free-text field instead of being discarded.
• A visible/audible cue (redraw, scroll-to-bottom, bell) when the menu mounts while the viewport is in scrollback.
• Convention/option for the first (default-focused) position to be a safe/no-op choice rather than the recommended action.

Actual Behavior

• Prompt box is silently replaced by the menu; viewport in scrollback shows no change.
• All typed printable characters are discarded.
• First Enter submits the default-focused first option.
• The submitted answer is recorded identically to a deliberate selection.

Environment

• Claude Code 2.1.228 (terminal CLI, not IDE extension)
• macOS (Darwin 25.6.0), zsh, Ghostty (xterm-256color)

Related

• #45374 (open — VS Code: dialog steals focus, captures keystrokes; comments add auto-submit on window focus change)
• #28722 (closed stale — same class, VS Code/Cursor)
• #37955 (closed — permission modal approved by typed keystrokes)
• #68800 (closed — consistent safe-option positioning to prevent accidental approval)
• #72614 / #71468 / #70622 / #75599 (mouse-flavor accidental selection)