VS Code extension: AskUserQuestion picker steals keyboard focus on mount even when its chat tab is hidden (mount-focus lacks the document.hasFocus gate the 500ms step has)

Environment

• Claude Code VS Code extension 2.1.235, VS Code 1.133.0, Windows 11

What's wrong

When an AskUserQuestion (or permission) prompt mounts in a chat webview, the picker immediately focuses its first option:

se(()=>{let k=f.current;if(!k)return;k.querySelector('[role="radio"], [role="checkbox"]')?.focus()},[n]);

This effect has no visibility/focus gate — it runs even when that chat's tab is a background tab (webviews are retained, so the hidden document keeps executing). Because a webview iframe can pull keyboard focus in VS Code, the mount steals the caret from whatever the user is typing into in a different tab of the same window — another Claude chat's composer included.

Notably, the very next effect in the same component IS gated correctly: the 500 ms "focus the primary button" step checks that the webview document has focus before acting. The mount-focus of the first option lacks the same condition.

Observed (element-level UIA focus trace)

While dictating into chat A's Message input, a background chat B received an AskUserQuestion. Within ~100 ms of the ask arriving, system keyboard focus left chat A's composer and landed inside chat B's (non-visible) webview document — zero clicks, no tab change, window title unchanged. The user's in-flight text went to a non-editable target.

The follow-on hazard is worse than lost keystrokes: with keyboard focus silently inside an invisible picker, a stray Space/Enter selects an option and auto-advances, and a stray Escape rejects the ask — we have separately observed a pending AskUserQuestion resolve as "User rejected tool use" with no click anywhere near the picker.

Suggested fix

Gate the mount/question-change focus effect the same way the 500 ms primary-button step is gated — only focus the option when the webview document has focus (or the panel is visible/active). A user landing on the tab later still gets keyboard-ready options via the existing focus management.

Related

• #63558 fixed this exact principle for the CLI ("Permission prompt immediately steals focus while typing") — this is the VS Code webview/cross-tab variant.
• #88465 (file-preview reveals taking focus) is a sibling report; together they cover the two paths a working/background session can yank the caret from the tab the user is typing in.