[BUG] VS Code: Ctrl+Shift+Tab (tab switching) also cycles permission mode; Ctrl+Tab sometimes skips a tab
Environment
- Claude Code VS Code extension 2.1.286 (darwin-arm64), VS Code 1.139.1, macOS
- Claude Code opened as an editor tab (not in a sidebar)
- User keybindings:
ctrl+tab→workbench.action.nextEditor,ctrl+shift+tab→workbench.action.previousEditor
Bug 1: Ctrl+Shift+Tab switches tabs and cycles the permission mode
The chat input's keydown handler in webview/index.js checks only shiftKey:
if (e.key === "Tab" && e.shiftKey) { e.preventDefault(); cyclePermissionMode(); return }
if (e.key === "Tab" && suggestion) { e.preventDefault(); acceptSuggestion(); ... }
Modifier chords aren't excluded, so Ctrl+Shift+Tab (and Cmd/Alt+Shift+Tab) is treated as Shift+Tab. preventDefault() doesn't stop the VS Code webview host from forwarding the keydown to the workbench. As a result previousEditor runs and the panel's mode cycles (set_permission_mode … "userInitiated":true in the Claude VSCode output log on every Ctrl+Shift+Tab). The same gap means plain Ctrl+Tab would accept a pending suggestion.
Suggested fix: require !e.ctrlKey && !e.metaKey && !e.altKey on both Tab checks.
Bug 2 (possibly VS Code/Electron, reported here for context): Ctrl+Tab from a Claude tab sometimes moves two tabs
Repro: open a new window, open two Claude Code tabs and then one other editor tab. Then press Ctrl+Shift+Tab, Ctrl+Shift+Tab, Ctrl+Tab, Ctrl+Tab a few times. Starting from a Claude tab, Ctrl+Tab sometimes skips one (e.g. [c] c t → c c [t]).
With Developer: Toggle Keyboard Shortcuts Troubleshooting, each skip shows the forwarded webview keydown dispatching nextEditor, followed about 2 ms later by a second dispatch:
[KeybindingService]: | Resolving ctrl+[Tab]
[KeybindingService]: + Invoking command workbench.action.nextEditor.
[KeybindingService]: / Dispatching keybinding triggered via menu entry accelerator - ctrl+tab
[KeybindingService]: + Invoking command workbench.action.nextEditor.
In one session this happened 5 times out of 34 Ctrl+Tab presses. It never happened for Ctrl+Shift+Tab, presumably because the webview preventDefault()s that key, so the native menu accelerator doesn't also fire. Unhandled modifier+key events in the Claude webview seem to also reach the macOS menu accelerator.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗