AskUserQuestion becomes unresponsive to selection keys after window refocus; single-question prompts unanswerable

Summary

An AskUserQuestion prompt regularly becomes completely unresponsive to selection input while still rendering as if it were live. The option caret is still drawn, the footer still reads "Enter to select · Tab/Arrow keys to navigate · Esc to cancel", but no key that selects or navigates within the question does anything.

On a multi-question prompt you can escape: Tab / ← / → still switch questions, and once you switch away and come back the question works normally again. On a single-question prompt there is nothing to switch to, so the prompt cannot be answered at all and the only way out is Ctrl+C.

Environment

• Claude Code 2.1.263 (also reproduced on 2.1.260)
• macOS 15 / iTerm2 3.6.9, and independently on Windows — identical behaviour on both
• "tui": "fullscreen" in settings.json

Observed key matrix (in the broken state)

| Key | Result |
| --- | --- |
| ↑ ↓ | dead |
| Enter | dead |
| j / k | dead |
| 1–9 (option numbers) | dead |
| Esc | dead |
| Tab, ←, → | work — switch question / reach Submit |
| Ctrl+C | works |

Trigger

Reliably reproducible pattern:

• Happens most of the time when the terminal window loses focus and regains it, or after the prompt has been sitting idle for a little while.
• Does not happen when the prompt appears while the window is already focused and it is interacted with immediately.

Recovery

Tab across to the Submit tab, then navigate back to the questions. From that point the question accepts keys normally again. This is the only recovery on a multi-question prompt, and there is none on a single-question prompt.

What this is not

• Not a terminal / escape-sequence problem. ← and → (ESC[D / ESC[C) work while ↑ and ↓ (ESC[A / ESC[B) do not — structurally identical sequences. Enter (a bare \r) is dead while Tab (a bare \t) works. The failure is semantic, not encoding.
• Not wheel-scroll-sending-arrow-keys. Tested directly: scrolling the wheel over an open question does nothing at all, so the arrow-burst path is not involved.
• Not a stuck keybinding chord — the chord timeout is 1s and Ctrl+C (a Global action) still works, so the keybinding dispatcher itself is alive.

Analysis / where to look

The dead set is exactly the keys the question's own subtree owns, and the live set is exactly the keys its ancestor owns. Two separate things appear to be true at once:

1. The option list is disabled. ↓, Enter, j/k and the option numbers dying together is the signature of isDisabled on the Select: it switches off both input paths simultaneously — the select:* keybinding actions (isActive: !isDisabled) and the widget's own raw handleKeyDown, which returns on its first line when disabled. Nothing else in the widget kills both at once. In the question renderer, isDisabled is driven by the "Chat about this" row's focus state, which is set by onDownFromLastItem.

1. The question renderer's own key handler is not firing either. If only (1) were true, ↑ would still work — the renderer's onKeyDown handles up / ctrl+p explicitly to move focus back off the chat row, and it also handles Enter and Esc. All three are dead, which suggests keyboard focus has left the renderer's root Box (tabIndex: 0, autoFocus: true) entirely, while an ancestor continues to handle Tab / ← / →.

That combination would explain the trigger and the recovery together: focus is lost around a terminal blur/focus transition, and switching questions remounts the renderer — restoring autoFocus and resetting the chat-row state in one go.

Worth checking whether the terminal focus-in/focus-out path can leave the ink focus manager with no active element (and the root reclaiming focus), while an AskUserQuestion is open.

Repro

1. Have Claude ask a single-question AskUserQuestion.
2. Switch to another window and back, or leave it sitting for a minute.
3. ↑, ↓, Enter, j, k, Esc and the option numbers are all dead. There is no Submit tab to escape to; Ctrl+C is the only way out.