[BUG] Cmd+W closes two tabs at once in VSCode extension (Antigravity)

Are you sure it closes two at a time always?
I'm experiencing a very similar issue - Cmd+W closes more than 1 tab very often but not always.
I assume this is because it's not debouncing the keypresses enough. So it's registering more than 1 keypress.

Same issue here. Cmd+W often closes two Claude tabs at once (macOS). Very disruptive!

+1 — can confirm this is still happening on v2.1.96 (macOS, Darwin 25.2.0).

Also want to share a related finding: Cmd+N has the same class of bug — it opens two Claude Code tabs instead of one.

Root cause investigation for Cmd+N

The extension registers a single keybinding in package.json:

{
  "command": "claude-vscode.newConversation",
  "key": "cmd+n",
  "mac": "cmd+n",
  "when": "config.claudeCode.enableNewConversationShortcut && (activeWebviewPanelId == 'claudeVSCodePanel' || (claude-vscode.sideBarActive && !editorFocus && !panelFocus))"
}

Only one keybinding is registered, so the duplication appears to be inside the newConversation command handler itself (possibly firing in both sidebar and editor tab contexts simultaneously).

Workaround for Cmd+N (confirmed working)

1. Disable enableNewConversationShortcut in the Claude Code extension settings
2. Add these to VS Code's keybindings.json:

{
    "key": "cmd+n",
    "command": "-workbench.action.files.newUntitledFile"
},
{
    "key": "cmd+n",
    "command": "-claude-vscode.newConversation"
},
{
    "key": "cmd+n",
    "command": "claude-vscode.editor.open"
}

This uses claude-vscode.editor.open ("Open in New Tab") instead of claude-vscode.newConversation, which avoids the double-tab issue entirely.

No similar workaround found for Cmd+W yet — since the extension doesn't register a Cmd+W keybinding, the double-close seems to happen internally when the extension handles the tab close event.

Doesn't happen when the Close command is executed through the Command Palette, does Claude Code registers its own Cmd+W internally, maybe?

Confirming this repro on my end.

Repro: focus an existing Claude tab → cmd+N to open a new Claude tab → cmd+W → both the new tab and the previously focused Claude tab close.

Versions:

• macOS 26.4.1
• VSCode 1.116.0
• Claude Code extension 2.1.116 (darwin-arm64)

Same root cause, different symptom — adding navigation key data

I filed #61382 for what turns out to be the same underlying bug pattern, on a different key:

• #29631 (this issue): Cmd+W closes two Claude Code tabs at once (workbench.action.closeActiveEditor fires twice).
• #61382: Cmd+Option+Right/Left advances two tabs at once (workbench.action.nextEditor / previousEditor fires twice).

I'll close #61382 in favor of this thread since the root cause is the same — sharing the additional findings here so they can be acted on together.

Smoking gun (from #61382, but applies identically to Cmd+W)

VSCode's Developer Troubleshooting log (Cmd+Shift+P → Developer: Toggle Keyboard Shortcuts Troubleshooting) shows two dispatches per keypress, ~8 ms apart:

2026-05-22 14:58:19.814 [KeybindingService]: + Invoking command workbench.action.nextEditor.       ← first fire (keydown)
2026-05-22 14:58:19.821 [KeybindingService]: / Dispatching keybinding triggered via menu entry accelerator - alt+cmd+right
2026-05-22 14:58:19.822 [KeybindingService]: + Invoking command workbench.action.nextEditor.       ← second fire (menu accelerator)

The first dispatch is the normal keydown event. The second is the macOS native menu accelerator firing the same command. This pattern is identical for Cmd+W, Cmd+Option+Arrow, and presumably any other shortcut that maps to a command which is also a menu item.

Why it's Claude Code specific

When focus is in a regular editor (Monaco), VSCode handles event.preventDefault() so the menu accelerator is suppressed. When the Claude Code webview is in the keypress lifecycle (focused, or just present in the editor group cycle on macOS), preventDefault() is not called, and the menu accelerator fires the command a second time.

This is consistent with other Claude Code webview / keyboard quirks already reported:

• #53055 (Cmd+Esc doesn't blur input in Claude Code panel)
• #12358 (Cmd+H, Cmd+M blocked when Claude panel is focused)
• #47876 (paste/copy fails over Remote-SSH due to focus loss)

Workaround that actually works (not the obvious one)

My first attempt was the obvious when guard:

{ "key": "alt+cmd+right", "command": "workbench.action.nextEditor", "when": "!webviewFocus && !terminalFocus" }

This does NOT work. VSCode's macOS menu service registers native menu accelerators WITHOUT evaluating when clauses — it just looks up which key is bound to a given command and registers that key as the accelerator regardless of context. The menu accelerator keeps firing the second dispatch.

Removing the default binding explicitly with -workbench.action.nextEditor then re-adding with a when guard also doesn't work for the same reason — as long as the user binding's command field still names workbench.action.nextEditor, the menu picks it up.

What works: wrap the command in runCommands so the binding's command field is no longer recognised as related to the menu item:

// keybindings.json
[
    { "key": "alt+cmd+right", "command": "-workbench.action.nextEditor" },
    { "key": "alt+cmd+left",  "command": "-workbench.action.previousEditor" },
    {
        "key": "alt+cmd+right",
        "command": "runCommands",
        "args": { "commands": ["workbench.action.nextEditor"] },
        "when": "!webviewFocus && !terminalFocus"
    },
    {
        "key": "alt+cmd+left",
        "command": "runCommands",
        "args": { "commands": ["workbench.action.previousEditor"] },
        "when": "!webviewFocus && !terminalFocus"
    }
]

After a full VSCode restart (Cmd+Q and relaunch — Reload Window is insufficient because the macOS menu cache doesn't refresh), the second dispatch is gone:

[KeybindingService]: + Invoking command runCommands.                                       ← single fire, no menu accelerator

The same pattern should work for Cmd+W:

[
    { "key": "cmd+w", "command": "-workbench.action.closeActiveEditor" },
    {
        "key": "cmd+w",
        "command": "runCommands",
        "args": { "commands": ["workbench.action.closeActiveEditor"] },
        "when": "!webviewFocus && !terminalFocus"
    }
]

(Untested for Cmd+W specifically — would be useful for @Go-Jinhan to confirm.)

Suggested extension-side fix

The Claude Code webview should call event.preventDefault() on intercepted keydown events that map to commands the host is going to handle — at minimum the navigation-class shortcuts (alt+arrow, alt+cmd+arrow, cmd+pageup/pagedown, ctrl+tab) and the close-tab shortcut (cmd+w).

Equivalent alternative: route navigation keys through VSCode's host via postMessage rather than letting the native menu accelerator dispatch a second copy.

Environment

• macOS 26.2 (build 25C56), arm64
• VSCode 1.120.0 (0958016b2af9f09bb4257e0df4a95e2f90590f9f)
• Claude Code extension anthropic.claude-code-2.1.145-darwin-arm64