VS Code: intermittent keybinding double-dispatch when a Claude session webview tab is focused (single keypress → command runs twice)

Intermittent double-dispatch of keybindings when a Claude session webview tab is focused

Summary

When a Claude Code session is open as an editor tab (webview) and has focus, a
single keypress of an editor-navigation shortcut intermittently invokes the bound
command twice, ~8 ms apart. Result: pressing "previous/next editor" once jumps two
tabs — it looks like a tab was "skipped." It is intermittent (some presses are clean),
which makes navigating a strip of session tabs by keyboard unreliable.

Environment

• VS Code: 1.129.1 (arm64, commit 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8)
• Claude Code extension: 2.1.237 (darwin-arm64)
• OS: macOS 26.5.1 (build 25F80), Apple Silicon
• claudeCode.preferredLocation: panel (sessions nonetheless opened as editor tabs via "Open in New Tab")

Repro

1. Open several Claude sessions as editor tabs (a strip of session webview tabs).
2. Click into a session tab so the webview has keyboard focus.
3. Press an editor-navigation keybinding once — e.g. cmd+alt+left

(workbench.action.previousEditorInGroup). Also reproduces with
cmd+alt+right, and with cmd+shift+[ / cmd+shift+].

1. Intermittently the active tab moves two tabs instead of one.

Expected vs actual

• Expected: one keypress → one editor step.
• Actual: intermittently two steps — the command fires twice for one keypress.

Evidence

"Developer: Toggle Keyboard Shortcuts Troubleshooting" log — one physical keydown,
two resolutions/invocations, no second keydown event:

11:20:07.083  Received keydown event ... code: BracketRight, key: ]
11:20:07.083  Resolving shift+meta+[BracketRight]
11:20:07.083  matched workbench.action.nextEditorInGroup, source: user
11:20:07.083  + Invoking command workbench.action.nextEditorInGroup      <-- fire #1
11:20:07.091  Resolving shift+meta+[BracketRight]                         <-- no new keydown
11:20:07.091  matched workbench.action.nextEditorInGroup, source: user
11:20:07.091  + Invoking command workbench.action.nextEditorInGroup      <-- fire #2

Corroborating symptom: the intermediate ("skipped") tab is briefly activated — its
unread indicator (the dot marking new assistant output in that session) clears, as if the
tab had been opened and read. So the tab is being visited twice-in-transit, not bypassed.

Ruled out

• Custom keybindings.json — reproduces on stock defaults too.
• Command choice — nextEditor, nextEditorInGroup all affected.
• Key choice — cmd+alt+arrows and cmd+shift+brackets both affected.
• Editor split layout, preview tabs, MRU ordering — none explain it.
• No system key remapper (Karabiner / BetterTouchTool / Hammerspoon) running; macOS key

repeat at defaults.

• Not a human double-tap — the two invocations are 8 ms apart from a single logged keydown.

Likely cause

The session webview forwards keydown events to the workbench (so global keybindings work
while a webview is focused) while the workbench also processes the same event, causing
intermittent double keybinding resolution. Correlates with the active tab being a Claude
session webview.