[BUG] AskUserQuestion preview variant ignores all key input when it renders during blur and focus returns ~90s later

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

An AskUserQuestion dialog that has preview on its options becomes completely
unresponsive to keyboard input under a specific and very common condition: the dialog
renders while the terminal is blurred, and focus returns more than ~90 seconds later.

In that state, none of the following do anything:

• ↑ / ↓
• ctrl+p / ctrl+n
• j / k
• number keys 1-9
• n (the notes field does not open)
• any other key — mashing the keyboard produces no visible reaction at all

Ctrl+C is the only reliable escape. Pressed once it dismisses the dialog and returns to
the chat input without killing the session, which shows the process is alive — only the
dialog's key handling is dead. Esc sometimes works and sometimes does not; there are
cases where repeated Esc presses are ignored as well.

The plain variant (no preview on any option) is not affected: under the exact same
timing it behaves normally, including j/k.

This is easy to hit in normal use. Waiting for a long agent turn, switching to another
application, and coming back a couple of minutes later is precisely the reproduction
recipe.

What Should Happen?

The dialog should accept key input whenever the terminal has focus, regardless of whether
it happened to be rendered while the terminal was blurred or how long the user was away.

Error Messages/Logs

# Nothing is logged at the moment the keys stop working — no error, no exception.
# With `claude --debug`, the only relevant signal is the focus transition timing.

# FAILING run (dialog rendered while blurred, focus returned 1m32s later):
04:41:26.478 [DEBUG] [presence] terminal focus → blurred
04:41:49.902 [DEBUG] executePermissionRequestHooks called for tool: AskUserQuestion
04:43:22.572 [DEBUG] [presence] terminal focus → focused
04:43:28.085 [INFO] Slow permission decision: 98184ms for AskUserQuestion (mode=auto, behavior=ask)
# ^ behavior=ask because the only way out was Esc

# PASSING run (dialog rendered while focused, then away for 2m5s):
04:45:15.549 [DEBUG] executePermissionRequestHooks called for tool: AskUserQuestion
04:45:18.266 [DEBUG] [presence] terminal focus → blurred
04:47:23.713 [DEBUG] [presence] terminal focus → focused
04:47:26.945 [INFO] Slow permission decision: 131398ms for AskUserQuestion (mode=auto, behavior=allow)

Steps to Reproduce

1. Start claude in an interactive terminal.
2. Prompt: Use AskUserQuestion to ask me one question with three options, and attach a preview string to each option.
3. Before the dialog appears, switch focus to another application. The dialog must be

rendered while the terminal is blurred.

1. Stay in the other application for about 2 minutes.
2. Return focus to the terminal (mouse click or Cmd+Tab — both reproduce) and try to move

the selection.

1. Every key is ignored. Ctrl+C gets you out; Esc may or may not work.

Control: repeat with Do not attach previews. in step 2. With the same timing, the dialog
works normally.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Claude Code Version

2.1.224 (Claude Code) — also reproduced on 2.1.223

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2 (also reproduced in Ghostty, and both with and without a terminal multiplexer)

Additional Information

Measured runs

All three conditions below must hold for the failure. I measured focus transitions with
claude --debug ([presence] terminal focus → … lines) against the dialog's
executePermissionRequestHooks called for tool: AskUserQuestion timestamp.

1. At least one option carries a preview
2. The terminal is blurred at the moment the dialog renders
3. Focus returns to the terminal more than ~90 seconds after the dialog rendered

| Focus at render | Render → refocus | Total blur | Result |
|---|---|---|---|
| blurred | 2s | 24s | works |
| focused | 4s | 4s | works |
| focused | 4s | 4s | works |
| blurred | 1m12s | 2m5s | works |
| blurred | 1m32s | 1m56s | all keys dead |
| blurred | 5m11s | 5m39s | all keys dead |
| focused | 2m5s | 2m5s | works |
| blurred | 2m11s | 2m27s | works — no preview |

The threshold sits between 72s and 92s of render-to-refocus time.

Note that total blur duration does not explain it: the 4th row was blurred for 2m5s and
worked, while the 5th was blurred for only 1m56s and failed. What matters is how long the
dialog sat rendered-but-unfocused.

Ruled out

Each of these was tested and eliminated:

• Input method / IME state (reproduces with IME both on and off)
• How focus is restored (mouse click and Cmd+Tab both reproduce)
• Where the focus-restoring click lands (on an option row or outside it — both fine)
• Returning from a fullscreen app / macOS Space switch
• Total blur duration (see above)
• Typing or clicking in the other application before returning
• The notes field having focus (pressing n during the failure does not open notes)
• Terminal emulator and multiplexer (iTerm2 and Ghostty, with and without one)

Possibly related

• #84519 describes the same component from a different angle: the preview variant renders

through a separate component that does not go through the keybinding registry and handles
keys with a raw onKeyDown. That issue covers j/k being unbindable there. This report
is a second symptom of that same component — under the timing above, that raw handler
stops responding to everything.

• #84489 — "options not selectable", accompanied by a VirtualMessageList itemKeys/messages

desync (Windows).

• #84657 — the focus-gaining click is captured as an option selection (Windows). Opposite

symptom, but also in focus handling.

Workarounds

• Ctrl+C once dismisses the dialog without killing the session. This has worked every

time so far, unlike Esc.

• Keeping the terminal focused while the dialog appears avoids it entirely.
• Not attaching preview to options avoids it entirely.