[BUG] VS Code extension: Alt+K / Ctrl+Esc don't focus the input when the Claude panel is in an auxiliary window; at-mention is broadcast to all visible panels

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Extension 2.1.212 (webview panel, useTerminal: false), VS Code 1.129.1, Ubuntu/GNOME/X11, dual monitors.

With the Claude panel detached into a VS Code auxiliary window ("Move into New Window"), Alt+K (claude-vscode.insertAtMention) and Ctrl+Esc (claude-vscode.focus) raise the Claude window but keyboard focus never lands in the chat input — it stays on workbench chrome until you click or Tab into it. Fully gated on window separation: docked works; editor and panel in different windows breaks, whichever side was detached. The reverse direction (claude-vscode.blur) works — it delegates to the aux-window-aware workbench.action.focusFirstEditorGroup.

With multiple Claude panels in separate windows (confirmed):

1. Duplicate insertion: Alt+K inserts the @-mention into every visible Claude input (detached panels are all simultaneously visible).
2. Reveal fight: one keypress triggers competing reveal() calls from every panel; focus ping-pongs between OS windows until focus-stealing prevention kicks in.

Root cause (from the bundled extension.js / webview/index.js, 2.1.212):

• Both command handlers fire the @file#L1-L2 string on a single shared EventEmitter; every webview connection subscribes, posts insert_at_mention to its webview, and calls panelTab.reveal() (preserveFocus: false). No targeting of the most-recently-active panel — hence duplicate insertion and the N-way reveal fight.
• The webview handler gates only on visibility, then immediately calls inputRef.current?.focus(). In a not-yet-OS-focused window this only sets the iframe's internal activeElement; when the aux window then gains focus from reveal(), the workbench restores focus to its own last-focused part (tab/panel chrome), not the webview. Nothing re-asserts input focus after activation (visibility_changed just flips a flag).

Evidence for the no-retry theory: binding claude-vscode.focus unconditionally (no when) fixes the single-panel case — a second tap/autorepeat re-fires the focus message after the aux window is active, and the inner focus() then succeeds. Ctrl+Esc can't retry: after the first press editorTextFocus is false and the key matches claude-vscode.blur instead.

What Should Happen?

Alt+K / Ctrl+Esc should land focus in the chat input of exactly one Claude panel (the most recently active), in main or auxiliary windows alike.

Suggested fixes: (1) defer/re-assert input focus until the webview's window actually gains focus, instead of a one-shot focus() that may run in a background window; (2) route the at-mention/focus event to the most-recently-active Claude webview only — fixes duplicate insertion and the reveal fight.

Error Messages/Logs

Steps to Reproduce

1. Open the Claude panel (webview mode) on Ubuntu, two monitors.
2. Drag the Claude editor tab out (or "Move into New Window") onto the second monitor.
3. In the main window's editor, select lines, press Alt+K (or Ctrl+Esc).
4. Observe: Claude window comes forward, @-mention is inserted, but the input textbox is not focused.
5. Open a second Claude panel in another detached window; repeat step 3.
6. Observe: @-mention inserted into BOTH inputs; the windows fight over focus.

Claude Model

_No response_

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.211 (Claude Code); extension 2.1.212

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Prior art: #18266 (same Ctrl+Esc symptom on Linux, closed not-planned — never connected to auxiliary windows), #9751, #8977 (focus loss on window switches). Aux-window gating appears to be the missing diagnostic detail.