[BUG] Desktop: The AskUserQuestion option picker cannot be submitted from the keyboard — number keys highlight an option, Enter does nothing

In the Desktop app's Code tab, the multiple-choice question card that AskUserQuestion renders can be navigated from the keyboard but not answered from it. Highlighting an option works; committing it does not. Submitting one of the offered options requires the mouse.

What happens

• Number keys move the highlight onto the matching option (observed on a four-option card). That matches the documented Desktop shortcut 1–9, "Select item in an open menu" — except that in this card it only highlights.
• With an option highlighted, Enter does nothing. The card stays open and the turn stays blocked.
• Tab never enters the card. From the composer it moves focus to the Stop button beside it, skipping the pending question entirely. Enter there does not answer the question either.
• The one keyboard path that completes the card is the free-text field on the last option: type into it, press Enter, and the answer is sent.
• On a multi-question call there is no keyboard way to advance to the next question, so the rest of the dialog has to be driven with the mouse as well.

So the escape hatch is keyboard-completable and the option list — the thing the card exists for — is not.

Expected

The Desktop card should honor the same contract the CLI picker already documents for its Select context:

• Focus moves into the card when it opens, and returns to the composer after the answer is sent.
• Up/Down move the highlight, alongside the existing 1–9.
• Enter accepts the highlighted option (CLI select:accept), and advances to the next question when the call has more than one.
• Space toggles an option when the question is multiSelect.
• Escape cancels (CLI select:cancel).
• Tab cycles the card's own controls — options, the free-text field, the submit control — instead of jumping past the card to Stop.

Enter is the missing piece. Everything else is a refinement; without an accept key the card cannot be completed from the keyboard at all.

Not tested here: Up/Down, Space, and Escape. Escape in particular was left alone because the expected outcome is discarding the pending question.

Why this is not the existing CLI reports

The CLI has its own, separate defects in this tool's picker — #70577 (side-by-side preview layout swallows input) and #88839 (unusable with NVDA) are both area:tui, reported against a pty-driven terminal renderer. This report is the Desktop app's own React card in the Code tab, which is a different renderer with a different input path, and it fails in a different way: input is received, since number keys visibly move the highlight, but there is no accept key wired up.

The keybindings reference documents select:accept (Enter) and select:cancel (Escape) for the CLI. Desktop does not read keybindings.json at all (#84101), so those defaults are not available here and there is nothing a user can rebind to work around it.

Impact

• Every question card forces a hand off the keyboard, and the card appears at exactly the point where the turn is blocked waiting on the answer.
• For keyboard-only and assistive-technology users it is not friction but a hard stop: The card is unanswerable, and the session cannot proceed past it.
• The workaround — answering through the free-text field — discards the structured option the tool asked for and sends prose instead.

Steps to reproduce

1. In the Desktop Code tab, get Claude to call AskUserQuestion with one single-select question and a few plain options (no preview).
2. Press 2. The second option highlights.
3. Press Enter. Nothing happens.
4. Press Tab. Focus lands on the Stop button, not on the card.
5. Click into the last option's free-text field, type anything, press Enter. That answer sends.

Environment

• Claude Desktop 1.40609.0 (Microsoft Store MSIX build), bundled engine claude-code 2.1.247
• Windows 11 Education 25H2, build 26200
• Confirmed 2026-08-30

Related

Same class, same app — popups and dialogs that render without focus management:

• #82288 — the bypass-permissions confirmation dialog renders off screen and never takes focus
• #82289 — slash-command suggestions render off screen and arrow keys do not move through them
• #84912 — submitting a prompt moves focus to the Stop button, so the next Enter cancels the turn; the same misplaced focus target is what Tab reaches from the composer here

Other reports about this card, none of which covers the missing accept key:

• #77015 — clicking the notification for a pending question cancels it
• #86702 — resizing the window destroys the card, with no way to bring it back