[BUG] Focus ping-pongs between two split Claude Code panels, then becomes unresponsive

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?

When two Claude Code panels are open in split editor groups, invoking the claude-vscode.focus command (bound to a custom keybinding) intermittently causes focus to oscillate back and forth between the two panels instead of settling on one. Once it starts, the window becomes unresponsive to further input until focus is forced elsewhere (e.g. Alt+Tab away and back).

What Should Happen?

Focus moves to one Claude Code panel (whichever was last active) and stays there.

Error Messages/Logs

Steps to Reproduce

1. Open two Claude Code panels in a split editor layout (one left group, one right group).
2. Trigger claude-vscode.focus via a keybinding while VS Code does not have a clearly-established internal focus target — most reliably reproduced right after switching back to VS Code with Alt+Tab from another application (i.e. the OS window regains focus but no specific VS Code part — editor/sidebar/panel — has claimed keyboard focus yet).
3. Observe.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

• VS Code: 1.134.0 - Claude Code extension: v2.1.245

Claude Code Version

• VS Code: 1.134.0 - Claude Code extension: v2.1.245

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Frequency

• Reproduces roughly 20–30% of the time (10 trials, ~2–3 failures) when the command is invoked from a state where no specific VS Code part has focus (post-Alt+Tab).
• Reproduces consistently (near 100% in our testing) when the command is invoked while focus is already inside one of the two Claude Code webview panels.
• Does NOT reproduce when only one Claude Code panel is open — this is specific to having two open simultaneously.

Diagnostics already tried (ruled out as causes)

• Not a physical keyboard issue: reproduced identically on two completely different key combos (Alt+CapsLock and Alt+Backtick), and CapsLock itself was confirmed to toggle normally.
• Not a keybinding-registration issue: the command shows correctly bound in the Keyboard Shortcuts UI with no conflicts, and runs correctly every time when invoked directly via Command Palette ("Claude Code: Focus input").
• Not fixable via a when clause guard: we tried gating the keybinding on editorTextFocus, activeWebviewPanelId != 'claudeVSCodePanel', and combinations of sideBarFocus/panelFocus/terminalFocus/editorFocus. editorTextFocus alone reliably blocks re-invocation from inside an already-focused Claude panel (0/10 failures), but any condition permissive enough to still fire in the "no specific focus" post-Alt-Tab state re-exposes the same ~20–30% race. This suggests the bug is inside claude-vscode.focus's own panel-target resolution logic, not something that can be worked around purely via VS Code context keys.
• Confirmed via "Developer: Toggle Keyboard Shortcuts Troubleshooting" log that the keybinding dispatch layer itself is behaving correctly (matches/doesn't match when clauses as expected) — the bug happens after the command is invoked, not in keybinding resolution.