[BUG] VS Code extension doesn't load Chrome browser tools in chat panel despite docs stating @browser should work (Linux)

Follow-up with additional context and observations.

Observation: VS Code extension spawns Claude with --no-chrome flag

Running ps -ef | grep -E "claude.*--(no-)?chrome" | grep -v grep while the Claude Code chat panel is active in VS Code shows that the VS Code extension spawns the Claude binary with the --no-chrome flag:

/home/mirao/.vscode/extensions/anthropic.claude-code-2.1.114-linux-x64/resources/native-binary/claude --output-format stream-json --verbose --input-format stream-json --max-thinking-tokens 31999 --permission-prompt-tool stdio --setting-sources=user,project,local --permission-mode acceptEdits --include-partial-messages [--add-dir entries omitted] --debug --debug-to-stderr --enable-auth-status --no-chrome --replay-user-messages

All Claude processes spawned by the extension during the session carry this flag. Whether this is the direct cause of the missing browser tools, or whether the extension is expected to activate Chrome integration through a separate mechanism that is failing, cannot be determined without access to the source code.

Verification command for anyone reproducing this:

ps -ef | grep -E "claude.*--(no-)?chrome" | grep -v grep

Works from CLI

Running claude --chrome in the integrated terminal within VS Code works correctly. Claude opens Chrome, navigates, and Called claude-in-chrome appears in output. A separate process is visible as /home/mirao/.local/share/claude/versions/2.1.90 --chrome-native-host. This confirms:

• Chrome extension is correctly installed and connected
• Native messaging host is configured
• Account/auth is consistent
• The issue is specific to how the VS Code extension invokes the Claude process

Troubleshooting already performed

• Multiple full VS Code restarts (not just Reload Window)
• Verified VS Code extension version meets the v2.1.27+ requirement where Chrome integration was enabled
• Verified Chrome extension v1.0.68 > required v1.0.36
• Confirmed same Anthropic account on Chrome extension and Claude Code
• Tried /chrome in the chat panel (no response, command not recognized in chat — only works in CLI)
• Tried @browser mention (Claude reports no browser tools available)

Related issues

• #23939 — Chrome MCP tools never load in VS Code (Windows 11)
• #22037 — VS Code docs missing Chrome integration instructions (docs bug)
• #36471 — side remark notes VS Code extension v2.1.79 also passed --no-chrome, suggesting this behavior has been consistent across multiple extension versions rather than being a recent regression

Impact

The documented @browser workflow is the primary advertised value of the VS Code extension over the CLI for web developers. With this bug, users must fall back to claude --chrome in the terminal.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23939
2. https://github.com/anthropics/claude-code/issues/23490
3. https://github.com/anthropics/claude-code/issues/11448

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Thanks @github-actions for flagging potential duplicates. I've reviewed all three and believe this issue is distinct:

• #23939 — targets Windows 11 with a different root cause (MCP error -32601: Method not found). My case is Linux and the logs show no such MCP error. That issue was also closed as not planned.
• #23490 — describes user-configured MCP servers (Slack, Clickup, etc.) that connect successfully but are hidden by the tengu_tst_kx7 tool search experiment. In my case, claude-in-chrome is not a user-configured MCP server — it's a built-in Chrome integration — and it never registers in /mcp at all (not just deferred). My other user MCP servers (atlassian, bitbucket, jenkins) work correctly in the same VS Code chat panel.
• #11448 — a general report about MCP tools not being exposed in VS Code. This doesn't apply here because my user MCP servers are exposed and working; only the Chrome integration is missing.

The distinguishing observation in this report is that the VS Code extension spawns the Claude binary with --no-chrome (verifiable via ps -ef), which is not reported in any of the above.

Leaving a comment to prevent auto-closure.

Update: two-patch workaround found that makes @browser work in the VS Code extension on Linux.

After the --no-chrome finding in the original report, I investigated the extension's bundled extension.js further. Removing --no-chrome alone is not sufficient — there is a second gate in the UI layer.

Gate 1 — hardcoded spawn flag (line ~802 in v2.1.114, minified):

extraArgs:{debug:null,"debug-to-stderr":null,"enable-auth-status":null,"no-chrome":null,"replay-user-messages":null}

Removing the "no-chrome":null, substring causes the extension to spawn the Claude binary without --no-chrome (verifiable via ps -ef).

Gate 2 — UI-level feature flag check (same file):

isBrowserIntegrationSupported(){return this.authManager.getAuthStatus()?.authMethod==="claudeai"&&!!this.experimentGates.tengu_quiet_fern}

This method gates whether @browser mentions are resolved at all in the chat panel. It requires experimentGates.tengu_quiet_fern — a server-side experiment flag pushed from the Claude process via onExperimentGatesUpdated. My account does not have this flag, so the UI suppresses browser tools even when the underlying Claude process is fully capable. Replacing the body with return!0 enables the UI path.

With both patches applied and VS Code fully restarted (not just Reload Window), @browser works end-to-end in the extension: the "Browser connected" banner appears, claude-in-chrome [navigate] invocations succeed, and all mcp__claude-in-chrome__* tools become available — matching CLI claude --chrome parity.

<img width="1378" height="1941" alt="Image" src="https://github.com/user-attachments/assets/bda38770-dbe0-4612-8c14-906e23f8ea25" />

Implications:

• The --no-chrome flag and the tengu_quiet_fern gate appear to be intentional — this is a staged rollout, not a bug in the usual sense.
• However, CLI claude --chrome is not gated by the same flag, so there is an inconsistency between the two surfaces. A user whose CLI works has every reason to expect the VS Code extension to work too.
• If Anthropic intends Chrome integration to be GA in the VS Code extension, consider removing the tengu_quiet_fern check (or publishing the rollout criteria). If staged, the UX should at least explain why @browser is unavailable instead of silently falling back to WebFetch.

Happy to test patch-removal on any future extension version if it would help Anthropic reproduce or validate a fix.

Same issue on macOS (Darwin 25.4.0) with Claude Code 2.1.96 and Claude for Chrome extension 1.0.66.

Confirmed root cause: VS Code extension launches Claude with --no-chrome flag.

Workaround I found: you can use the Bash tool inside a VS Code session to call claude --chrome -p "your prompt" as a subprocess. It is slower (~15–30s per call, no session continuity) but works without switching to terminal.

Upvoting this issue — hope it gets prioritized.

For people landing here while waiting on the tengu_quiet_fern gate to flip — Chrome Relay is an alternative path that's completely independent of claude --chrome / claude-in-chrome / the experiment gate. It's a separate Chrome extension + small native messaging host + npm CLI: chrome-relay tabs, chrome-relay navigate, chrome-relay click, chrome-relay read -i, etc. Claude Code can call it via the Bash tool the same way @kasiaalena's claude --chrome -p workaround does, but the bridge is local and doesn't go through Claude's MCP/experiment plumbing at all.

Doesn't replace the fix @mirao is asking for here — that's still the right thing for the VS Code extension to ship. But if you have an open Chrome session you want the agent to actually drive in the meantime, this works on Linux/macOS without needing to patch extension.js.

Web Store: https://chromewebstore.google.com/detail/chrome-relay/cpdiapbifblhlcpnmlmfpgfjlacebokb

Removing &&!!this.experimentGates.tengu_quiet_fern from extension.js seems to be sufficient. I really don't like messing with this minified file, but .claude.json constantly gets overwritten and making it read-only seems more error-prone than the tiny modification to extension.js.

+1 to @jan-kleiss: that worked for me, as well.

My use-case is interesting because I have a client (my desktop) SSHed into a remote server (where all my skill / mcp goodness has been perfectly curated). However, I like the ease of "pre-authing" a few web pages before executing some tasks. The only solution that really worked was to use VS Code with the Claude-in-Chrome support. All other ways of wiring it up were sort of jank.

macOS user here. This worked fine a week ago.

Turns out that the Chrome extension needed a re-auth. I had to click on the extension toolbar button to find it.

Likely the same underlying defect on macOS - filed as #63482, cross-linking for visibility.

Summary of the macOS side:

• VS Code extension (macOS, anthropic.claude-code-2.1.156-darwin-arm64): the @browser instruction block is injected and a Chrome tab is created, but no mcp__claude-in-chrome__* tools are ever registered into the session (not callable, not even discoverable). This is slightly different from the surface symptom here, where the @browser mention is reportedly not recognized at all - but the end result is identical: the VS Code panel has no working browser tools.
• Reproduced on two separate macOS machines and across two different Claude accounts, so it is machine-/account-independent.
• On one of those machines, claude --chrome from a terminal drives Chrome end-to-end with no problem - proving the native-messaging bridge (manifest + native host + bridge socket) is fully functional there. The VS Code extension on that same machine still exposes no browser tools.

So this isolates the defect to the VS Code extension's tool-registration path, independent of the native bridge: CLI works, VS Code extension does not, on the same box. This issue (#50423, Linux) and #63482 (macOS) look like the same root cause across both platforms.

Reproducing on Windows 11 + VS Code Extension

Confirming this issue on Windows. Adding our environment details as another data point.

Environment

• OS: Windows 11 Home 10.0.26200 (x86_64)
• VS Code: latest stable (running Claude Code as VS Code native extension)
• Claude Code: latest (Sonnet 4.6, claude-sonnet-4-6)
• Claude in Chrome extension: installed, shows "Browser connected" popup in the Claude Code panel UI
• Google Chrome: latest stable
• Plan: Claude Pro

Behavior

The Chrome extension connects visually — the "Browser connected" dialog appears in the Claude Code VS Code panel, and the <browser_instruction> system prompt block is injected into the conversation (confirming the extension handshake fires). However:

• mcp__claude-in-chrome__* tools are not registered in the tool registry
• Direct tool calls return: Error: No such tool available: mcp__claude-in-chrome__tabs_context_mcp
• ToolSearch with queries for tabs/screenshot/navigate/click returns no matches
• /mcp does not show claude-in-chrome
• @browser is not recognized as a mention

The tabId="undefined" in the injected <browser> tag is a visible symptom — the tab context never resolves.

Key difference from original report

The extension does inject its system prompt block (we see <browser_instruction> and <browser tabGroupId="..." tabId="undefined"> in context), so the WebSocket/connection handshake is partially working. But the MCP tool schemas never load into the callable tool set. It appears the tool registration step that should follow the connection handshake is silently failing.

Workaround attempted

Running claude --chrome from the terminal was not tested on this setup, but based on the original report that path works — suggesting this is specific to the VS Code extension host not completing MCP tool registration after the browser connection event.

Subscribing for updates.

Another data point from macOS that narrows the regression window — possibly useful for whoever picks this up.

Environment

• macOS (Apple Silicon), VS Code stable, Claude Code extension
• Claude Code browser extension paired (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Native-messaging host registered correctly: com.anthropic.claude_code_browser_extension → ~/.claude/chrome/chrome-native-host (wrapper into the current Claude Code binary)

Symptom (matches the issue)

• @browser banner appears in the chat panel and the browser_instruction block is injected listing mcp__claude-in-chrome__* tools by name
• ToolSearch for select:mcp__claude-in-chrome__tabs_context_mcp returns "No matching deferred tools found"
• Broader searches (+claude-in-chrome navigate tabs) also return nothing
• claude mcp list only shows the Google MCP servers; chrome MCP never registers
• VS Code's mcpGateway.log shows only [McpGatewayService] Initialized across many windows — chrome server never registers with the gateway
• Same machine, same Chrome session, the CLI route (claude --chrome from the integrated terminal) works fine — confirming the native-host plumbing is healthy and the regression is panel/bridge-side

Version bisect (empirical, from this machine's session transcripts)
| Extension version | Dates active | Browser tools in panel |
| --- | --- | --- |
| 2.1.145 | May 20 → May 29 | ✅ Working (heavy use May 26–28: tens of successful mcp__claude-in-chrome__* calls) |
| 2.1.156 | May 29 14:15 → May 30 ~18:18 | ❌ Tools never surface (verified by reinstalling 2.1.156 and retesting) |
| 2.1.158 | May 30 onward | ❌ Tools never surface |

So the regression was introduced somewhere in 2.1.146 → 2.1.156. 2.1.145 is the latest version I can confirm works.

Workaround that restores functionality

1. VS Code → Extensions → Claude Code → ▾ next to "Uninstall" → Install Another Version… → 2.1.145
2. Reload window
3. Same ▾ menu → uncheck "Auto Update" so VS Code doesn't silently re-update and re-break it
4. Open the target tab in Chrome, start a new chat, type @browser — ToolSearch now finds the tools and tabs_context_mcp returns the live tab list

Reload+reconnect alone on 2.1.156/2.1.158 did not restore the tools, even after a full machine reboot and resetting the Chrome native-messaging manifest state — the only thing that fixed it was pinning to 2.1.145.

If someone narrows this further (2.1.146–2.1.155), please drop the result here — happy to test other versions on this machine since "Install Another Version" makes that cheap now.

This is happening to me, just filed a bug report around it but put it under this issue ^

Still reproducing on Windows 11 with Claude Code 2.1.159 (CLI + VS Code extension) — extends @avioing's bisect, which ended at 2.1.158.

Environment:

• Windows 11 Home 10.0.26200
• Claude Code 2.1.159 (CLI ~/.local/bin/claude.exe, VS Code extension same build)
• Claude in Chrome extension connected, model Opus 4.8, plan Claude (claudeai auth)

Symptoms are identical to @alextfink's Windows report: the browser_instruction block and <browser tabGroupId="…" tabId="undefined"> tag are injected, but mcp__claude-in-chrome__* never register — tabs_context_mcp returns Error: No such tool available, ToolSearch finds nothing, /mcp is not a recognized chat command and the server never appears. On the same machine, claude --chrome from the terminal drives Chrome end-to-end fine, so the native bridge is healthy; only the extension's tool-registration path is broken.

Workaround we're using (panel-only, no terminal switch): drive a nested CLI from the Bash tool with a scoped allowlist rather than bypassing permissions —

claude --chrome -p "<instructions>" --allowedTools "mcp__claude-in-chrome__tabs_create_mcp mcp__claude-in-chrome__tabs_context_mcp mcp__claude-in-chrome__read_console_messages" --model sonnet

(add mcp__claude-in-chrome__javascript_tool only when clicks/input are needed). --permission-mode bypassPermissions is rejected by the auto-mode classifier as a nested-agent escalation, so the scoped --allowedTools form is what actually runs unattended.

Restating the ask: please bring Chrome parity to the VS Code extension — flip the tengu_quiet_fern gate to GA (or publish rollout criteria) and fix the 2.1.146+ regression, or at minimum surface why @browser silently falls back so users don't assume it's a local misconfig.

Update from the macOS reporter (this thread's bisect): now working after the latest extension + host bumps.

| | Before (broken) | Now (working) |
|---|---|---|
| macOS | 26.5.1 arm64 | (same) |
| Claude Code | VS Code extension 2.1.158 | VS Code extension 2.1.165 |
| Claude in Chrome | 1.0.74 | 1.0.75 |

mcp__claude-in-chrome__* tools now load via ToolSearch and tabs_context_mcp returns the live tab list in the VS Code chat panel. Can't isolate whether the Chrome-extension bump (1.0.74→1.0.75) or the VS Code extension bump (2.1.158→2.1.165, spanning 7 builds) was the fix — both happened simultaneously on my end.