[BUG] VS Code extension 2.1.235+: a newly loaded Claude panel takes focus but leaves its input unfocused, swallowing every VS Code keybinding until a mouse click

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?

Version note. Every 2.1.23x number in this report is the VS Code extension version, as shown in the Extensions view and in the extension folder name anthropic.claude-code-<version>-win32-x64. The CLI on my PATH is a separate install and reports 2.1.237 (Claude Code) — that is what the Claude Code Version field records. The bug tracks the extension version, not the CLI version.

Since 2.1.235, whenever a Claude Code webview panel finishes its initial load, the panel takes keyboard focus but the message input is left unfocused. In that state VS Code swallows every keybinding — nothing fires at all — until the user clicks with the mouse.

On 2.1.234 the same actions put the caret in the message input and keybindings keep working.

Two independent triggers reproduce it:

1. claude-vscode.editor.open (Claude Code: Open in New Tab). Both a keybinding and the Command Palette reproduce it, so this is not a keybinding-resolution problem.
2. Switching to an existing Claude tab that still has to load — e.g. Alt+<n> right after a window reload. The symptom appears the moment that tab finishes loading.

Trigger 2 matters: this is not specific to the editor.open command. Any path that loads a Claude webview reproduces it.

Opening an ordinary editor tab (a .txt file) does not reproduce it, so this is specific to the Claude webview.

Keys verified as dead while stuck:

| Chord | Command | Stock or custom on my machine |
|-------|---------|------------------------------|
| Ctrl+1 | workbench.action.focusFirstEditorGroup | stock VS Code default |
| Ctrl+2 | workbench.action.focusSecondEditorGroup | stock VS Code default |
| Alt+1 | workbench.action.openEditorAtIndex1 | stock VS Code default |
| Ctrl+Shift+E | workbench.view.explorer | same command, narrowed when clause |
| Ctrl+E | quickPicker.openFilePicker | custom (replaces workbench.action.quickOpen) |

The first three are untouched VS Code defaults, so this is not a broken-custom-binding problem. Nothing fires at all, stock or custom. Typing produces nothing anywhere. A single mouse click anywhere restores normal behaviour.

What the panel looks like in the broken state

The panel itself renders correctly and completely — logo, the "Make a CLAUDE.md file" hint, the announcement card, the composer with its attach / slash-command / model row, and the tab is the active tab in its editor group. Nothing looks broken.

The only visible difference from 2.1.234 is in the composer:

| | 2.1.234 | 2.1.235+ |
|---|---|---|
| Composer caret | present, blinking | absent |
| Composer focus ring | present | absent |
| Composer content | empty and ready for input | placeholder text ctrl esc to focus or unfocus Claude still showing |
| Typing immediately after the tab appears | goes into the composer | goes nowhere |
| VS Code keybindings | work | all swallowed |

So the regression is not a rendering failure. The panel is fully painted and active; focus simply never lands in the composer, and the workbench never gets the keys back either.

There is no keyboard way out on Windows

• claude-vscode.focus is bound to ctrl+escape with when: !config.claudeCode.useTerminal && editorTextFocus. It cannot fire in this state, because there is no editor text focus.
• claude-vscode.blur is bound to the same chord with !editorTextFocus, which does match the stuck state. But on Windows Ctrl+Esc is a reserved shell shortcut: pressing it opens the Start menu and the keystroke never reaches VS Code. Verified with the extension's default keybindings restored.
• So the only recovery is a mouse click. For keyboard-only users the window is effectively unusable until they reach for a pointing device.

The panel's own placeholder text reads ctrl esc to focus or unfocus Claude, which is misleading on Windows for the same reason.

What Should Happen?

When a Claude panel finishes loading, its message input should receive focus (the 2.1.234 behaviour), and VS Code keybindings should keep working.

At minimum, focus should not be parked in the webview in a state where neither the panel nor the workbench accepts keyboard input.

Error Messages/Logs

No errors are produced. The failure is silent.

### Measurement: the OS-level focus state is never disturbed

Please do **not** triage this as OS window-activation theft. I instrumented it to rule that out.

I polled `GetForegroundWindow()` together with `GetGUIThreadInfo(0, ...)` (which reports `hwndActive` and `hwndFocus` for the foreground thread) in a tight loop while reproducing the bug:


=== focus watch v2 start 11:13:35.135 (duration 25s) ===
FG = OS foreground window / ACTIVE = active window of that thread / FOCUS = keyboard input target
11:13:35.143  ---------------------------------------------
  FG     : 0x40800 Code(pid 14340) cls=Chrome_WidgetWin_1 vis=True [... - Visual Studio Code]
  ACTIVE : 0x40800 Code(pid 14340) cls=Chrome_WidgetWin_1 vis=True [... - Visual Studio Code]
  FOCUS  : 0x40800 Code(pid 14340) cls=Chrome_WidgetWin_1 vis=True [... - Visual Studio Code]

=== sampling: 2049225 samples in 25.0s (81,969 per second), 1 change events ===

=== processes started during the watch window ===
   Id ProcessName StartTime
 8556 claude      11:13:38.824
30820 conhost     11:13:38.835
 3628 cmd         11:13:39.694
15936 conhost     11:13:39.715
13628 node        11:13:39.938
32748 cmd         11:13:40.559
32868 node        11:13:40.584

=== watch end 11:14:00.151 ===


**2,049,225 samples at ~82,000/s, zero change events.** `FG`, `ACTIVE` and `hwndFocus` all stayed on the VS Code HWND for the entire 25 s — including while the symptom was active and while I clicked to recover. Child processes (`claude`, `conhost`, `cmd`, `node`) were spawned at 11:13:38-40, confirming the command ran, but none of them ever became the foreground window.

Conclusion: everything happens inside the renderer. Win32 focus is untouched.

Steps to Reproduce

1. Windows 11, VS Code 1.134.0, extension 2.1.235 or newer.
2. Run Claude Code: Open in New Tab (claude-vscode.editor.open). A Claude tab opens in a new editor group.
3. Look at the composer: no caret, no focus ring, placeholder text still showing.
4. Without touching the mouse, press Ctrl+1, Ctrl+2 or Alt+1 — all three are stock VS Code defaults, so no custom keybindings are needed to reproduce. Nothing happens. Type — nothing appears anywhere.
5. Click anywhere with the mouse. Keybindings work again.

Alternative reproduction (no command involved):

1. Reload the window with one or more Claude tabs open.
2. Press Alt+<n> to switch to a Claude tab that is still loading.
3. The moment that tab finishes loading, the same dead state appears.

Downgrading to 2.1.234 makes both reproductions go away — verified for the command path and for the reload + Alt+<n> path. I am currently pinned to 2.1.234 as a workaround.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.234 (VS Code extension)

Claude Code Version

2.1.237 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Version matrix (VS Code extension versions)

| Extension version | Behaviour |
|-------------------|-----------|
| 2.1.234 | Works — input focused, keybindings fine |
| 2.1.235 | Broken |
| 2.1.236 | Broken |
| 2.1.237 | Broken |
| 2.1.238 | Broken |

All five were tested on the same machine and workspace. The CLI on PATH stayed at 2.1.237 (Claude Code) throughout, so the CLI version is not the variable here — only the extension version changed between the working and broken cases.

Where the change is not

I diffed the 2.1.234 and 2.1.235 extension bundles. The claude-vscode.editor.open handler and the createWebviewPanel call are byte-identical apart from minifier symbol renaming:

// identical in 2.1.234 and 2.1.235 (only one local renamed E -> S)
registerCommand("claude-vscode.editor.open", async (a, b, col) => {
  if (col !== ViewColumn.Active) setPreferredLocation("panel");
  let { startedInNewColumn } = createPanel(a, b, col);
  if (startedInNewColumn) await commands.executeCommand("workbench.action.lockEditorGroup");
});

The panel options (enableScripts, retainContextWhenHidden, enableFindWidget, localResourceRoots) are unchanged too, and the file list of the VSIX is identical. The change is therefore downstream of panel creation — webview/index.js grew from 4,942,539 to 4,943,127 bytes between the two versions, which seems the likeliest place to look.

Relation to existing issues

• #55253 (closed as not planned) documents the general behaviour where the Claude webview swallows workbench commands while the panel is focused. This report is different: I never focused the panel, and the panel's own input is not focused either, so there is nowhere for keystrokes to go. The swallowing mechanism is the same; the regression is that focus lands in the webview without landing in the input.
• Not a duplicate of #32726 (panel steals focus when producing output), #79770 (focus ping-pong between Claude tabs on startup), #83333 (empty editor group beside Cursor Agents), or #78698 (Alt+K / Ctrl+Esc in an auxiliary window).

The measurement above was produced with a small read-only PowerShell script that P/Invokes GetForegroundWindow and GetGUIThreadInfo and logs every change. Happy to attach it if that would help.