[BUG] AskUserQuestion dialog steals focus and captures keystrokes while user is typing in VS Code

Still reproducing on Claude Code 2.1.123 (VS Code extension, macOS 15.4) — a month after filing.

The pattern is consistent: extension is mid-task, I start typing in the input box, an AskUserQuestion dialog renders, and the next keystroke selects whichever option matches the digit I happened to be typing. There's no visual delay or focus indicator that gives the user a chance to react.

Linking the prior reports again so the duplicate trail is visible:

• #28722, #33988, #10971, #22300, #20591 — all closed without resolution

Five prior reports + this one = six instances of the same issue, all marked stale or closed without a fix shipping. The fix is small in scope (gate the dialog's keyboard handler behind a deliberate focus event, or queue the dialog while the input box has focus and content). Asking for this to stay open and get triaged rather than auto-closed.

Cmd+number tab switching (e.g. Cmd+1, Cmd+2) in VS Code triggers number selection in the dialog — the handler appears to not check event.metaKey before treating the keypress as a choice selection.

Adding evidence + a new variant. Up front: the "disable shortcuts" idea below isn't new — it's already in #20591 ("Add configuration option to disable immediate hotkey triggering" / "Require Enter key to confirm number-based selections") and #33988 ("Deliberate confirmation: require a specific key combo or double-tap"). What may be new here is the multi-tab manifestation and the Windows 11 + VS Code extension combo.

New variant: cross-tab keystroke capture

Reproduction:

1. Two Claude Code tabs open in VS Code (Tab A and Tab B).
2. Tab B is mid-task, working autonomously.
3. User is composing a fresh prompt in Tab A.
4. Tab B fires AskUserQuestion.
5. Subsequent keystrokes (digits, Enter) meant for Tab A's composer end up answering Tab B's dialog — the user selects an option they never read.

Mechanism unverified. Hypotheses:

• (a) VS Code switches the active editor tab when a background Claude Code webview requests focus on dialog render.
• (b) The dialog's keyboard handler uses a window-level listener that isn't scoped to the firing tab's webview.
• (c) Something else entirely.

Whichever it is, this is worse than the single-tab case in prior reports: with one tab the dialog at least renders over the composer the user is looking at; in the multi-tab case the user is focused on Tab A and may never visually register that Tab B came forward before the answer is submitted.

Environment under-reported

Most prior reports are macOS or Linux. Windows 11 + VS Code extension (Claude Code 2.1.143) reproduces the same focus-theft pattern. #20591 is Windows but Windows Terminal CLI, not the VS Code extension.

Pattern across reports

This bug family has been filed at least 11 times in the last ~6 months: #10971, #16818, #18030, #18227, #19182, #20591, #22300, #23643, #25073, #28722, #33988. Only #19182 closed as COMPLETED — a partial fix appears to have shipped around 2.1.76 for the specific "Other text input" case (per a comment on #22300). The other ten were closed NOT_PLANNED or DUPLICATE, most by bot inactivity rather than explicit decision. The cumulative volume suggests a structural fix is overdue.

Smallest possible fix (already proposed)

Re-amplifying #20591 / #33988 since it keeps not landing: a setting to disable digit + Enter shortcuts on the AskUserQuestion dialog (force click-to-select). Toggle preserves the shortcut for users who rely on it. Doesn't need idle-detection or focus-awareness; fixes the whole class of accidental selection regardless of tab/focus state.

Adding a Windows 11 repro of @Depot404's cross-tab variant, plus a complementary feature ask I don't think the prior reports cover.

Repro confirmed on Windows 11 (VS Code extension, parallel/background sessions): a background session fires AskUserQuestion, its attention notification comes forward and steals keyboard focus from the session I'm actively typing in. Same mechanism @Depot404 describes — the focused session's composer loses focus and keystrokes can land on the background session's dialog.

The angle I want to add: the awareness itself is valuable — I genuinely want to know that a background session has a pending question. The problem is purely that the notification grabs focus and interrupts typing in the session I'm working in. So "queue/suppress the dialog" or "disable digit shortcuts" fixes the accidental-selection half, but it also throws away the useful signal that another session needs my input.

Requested: a setting — e.g. claudeCode.backgroundSessionNotifications — to choose how cross-session attention is surfaced, rather than only whether shortcuts fire:

• toast — current behavior
• statusBar — a count/badge in the status bar, no focus change
• bell — silent entry in VS Code's notification center/bell only
• osNotification — native OS notification (visible even when VS Code isn't frontmost), no in-editor focus steal
• silent — awareness via the Agents/sessions view only

This preserves the cross-session signal while guaranteeing a background session can never pull focus or capture keystrokes from whichever session currently holds the composer.

Current mitigation is too blunt: the only thing that stops it today is VS Code's global Do Not Disturb, which silences all VS Code notifications — far broader than needed. A Claude-scoped setting would let me keep the cross-session awareness without going dark on everything else.

This is still an issue.

Also hitting this on macOS, and I want to add a failure mode that's worse than the focus/keystroke-stealing described above: the dialog auto-submits an option I never clicked when the window gains or loses focus.

Repro:

1. The assistant opens an AskUserQuestion prompt with N options.
2. While it's open, focus changes (alt-tab, clicking another app, a notification stealing focus).
3. The prompt submits on its own, selecting the focused/default option — frequently NOT the one I would have picked. In one case it selected a non-recommended option I had explicitly been advised against.

Expected: a focus change must never submit. Only an explicit click/Enter on a chosen option should submit; focus events should be no-ops.

Impact: over the last 3 days this silently recorded several decisions I never made in multi-step workflows. Because the auto-submitted answer looks like a legitimate user choice, it's easy to miss and the assistant acts on wrong input downstream. This feels high severity — a data-integrity problem for user decisions, not just an annoyance.

Environment: Claude Code on macOS; questions are formatted via gstack 1.58.5.0, which only renders the text — the submit-on-focus behavior is in the client.

Same root cause as the now-closed-as-stale #28722; please keep this one open.