VSCode Chrome integration silently fails: 3 distinct bugs

Independently reproduced Bug 3 on a second machine and want to add one upstream gating layer this report doesn't yet cover. (Filed #63482 separately before finding this thread - that one is a duplicate of this and I'm closing it; this is the canonical, more complete report.)

Confirming Bug 3 (setMcpServers silent no-op)

• macOS, VS Code extension 2.1.156, Chrome ext 1.0.74, account = Claude Max.
• Clean state: removed a stale obsolete extension version so only 2.1.156 remained, full Cmd+Q cold restart (so bugs 1 & 2 are not in play).
• Log shows exactly your Bug 3 signature: ensure_chrome_mcp_enabled received → Chrome MCP: Successfully connected to server (host-side client) → no MCP server "claude-in-chrome": Starting connection / Successfully connected on the agent/query side (every other server - xcodebuild, firebase - logs it) → agent ToolSearchTool returns found 0 matches / select failed - none found: mcp__claude-in-chrome__tabs_context_mcp.
• claude --chrome from a terminal on the same machine works end-to-end. So: version-independent, bridge-health-independent - purely the dynamic registration into the running query silently no-ops. Matches your Bug 3 precisely.

Additional layer: the feature is auth-gated (not in this report)

From the shipped extension.js (2.1.156), browser integration is gated before any of the above can run:

// VS Code subclass:
isBrowserIntegrationSupported(){ return this.authManager.getAuthStatus()?.authMethod === "claudeai" }
// base class: return false

And getAuthStatus():

if (BEDROCK || VERTEX || FOUNDRY || SKIP_AUTH_LOGIN) return { authMethod: "3p" }
if (oauthTokens) return { authMethod: oauthTokens.scopes.includes("user:inference") ? "claudeai" : "console" }
if (ANTHROPIC_API_KEY || ANTHROPIC_AUTH_TOKEN) return { authMethod: "3p" }
if (apiKey) return { authMethod: "api-key" }

So browser integration is only offered when authed via a Claude.ai Pro/Max OAuth token (scope user:inference). Console-billing OAuth, API key, Bedrock/Vertex/Foundry, and enterprise auth all disable it entirely - @browser prose may still be injected, but ensure_chrome_mcp_enabled never fires and no tools register. This is a distinct failure from Bug 3: it's "feature off" rather than "registration silently fails." It likely explains reports from Console/enterprise users (and is the failure mode on my own enterprise account, separate from the Max account above where the gate passes and Bug 3 bites).

Suggested framing

• Layer 0 (gate): non-claudeai auth disables browser integration silently. Either support Console/API-key/enterprise auth for browser tools, or surface a clear "browser requires a Claude.ai login" message instead of injecting @browser prose with no tools.
• Bug 3 (this report): when the gate passes, setMcpServers({"claude-in-chrome"}) still silently no-ops.

One small code-level refinement of Bug 3 from the shipped extension.js (2.1.156), in case it helps narrow the instrumentation target.

The hang is in the ensureChromeMcpEnabled -> setMcpServers -> CLI IPC round-trip:

1. ensureChromeMcpEnabled does await V.query.setMcpServers(K) where K = { ...mcpServers, "claude-in-chrome": { type: "stdio", command, args: ["--claude-in-chrome-mcp"], env: { USER_TYPE: "external" } } }.
2. setMcpServers splits servers into sdk-instance vs everything-else. A stdio server like claude-in-chrome goes into the "everything-else" bucket and is forwarded to the CLI subprocess as a single IPC request: this.request({ subtype: "mcp_set_servers", servers }).
3. The returned promise is what ensureChromeMcpEnabled awaits before setting chromeMcpState to connected (success) or error (catch).

What the log shows on a clean, gate-passing (Max/claudeai), single-version, healthy-bridge setup:

• The webview ensure_chrome_mcp_enabled request (requestId X) is received once and never gets a response line.
• The CLI subprocess debug output (which is otherwise very verbose: API requests, tool dispatch, MCP connections for xcodebuild/firebase, etc.) contains no mcp_set_servers / sdk_mcp_set_servers activity and no MCP server "claude-in-chrome": Starting connection.
• chromeMcpState is therefore pushed neither as connected nor error, which is consistent with the await this.request({ subtype: "mcp_set_servers" }) promise never resolving (a silent hang rather than a thrown error). That matches the "no response, no error, no state push" behavior in the original report.

So the concrete suspect is the mcp_set_servers IPC handler in the CLI query (or the request/response correlation for that subtype) failing to ever reply when a stdio MCP server is added mid-session. Instrumenting both ends of that one IPC subtype should surface where it dies.

Reproducing Bug 3 on Windows (the two confirmations above are both macOS).

• OS: Windows
• VS Code extension: broke on 2.1.153, still broken on 2.1.156
• Claude for Chrome extension connected ("Browser connected" banner shown)
• Symptom matches Bug 3 exactly: webview injects the browser context, model is

told it has mcp__claude-in-chrome__*, but the tools never enter the
deferred-tool pool — Claude reports they "weren't in the deferred tools list"

• claude --chrome from the integrated terminal works fine

One data point on the version angle: 2.1.152 happened to work for me while
2.1.153 / 2.1.156 don't. Given your note that the setMcpServers no-op is
intermittent ("the same path does work occasionally"), this may just be luck
rather than a real version boundary — flagging it in case the timing of the
2.1.153 extension change correlates with the IPC regression.

Closing my report #63696 as a duplicate of this one.

Confirming this reproduces on Windows 11 (the report is currently macOS‑only). Same end symptom: @browser injects the browser_instruction prose and <browser tabId="undefined">, but mcp__claude-in-chrome__* never enters the tool pool, so the model is told it has chrome tools it doesn't have. Bug 1 and Bug 3 both reproduce here; Bug 2 does not apply. It works fine from the Claude Code CLI; only the VS Code extension fails.

Environment

• OS: Windows 11 Enterprise (build 26100)
• Claude Code: 2.1.156 (standalone CLI at %USERPROFILE%\.local\bin\claude.exe and the VS Code‑bundled binary both 2.1.156)
• VS Code extension: anthropic.claude-code-2.1.156-win32-x64
• Claude in Chrome extension: fcoeoabgfenejglbffodgkkbkcdhcgfn v1.0.74 (installed in both Edge and Chrome)
• Claude Desktop app also installed and running (Claude_1.9659.2.0_x64)

Bug 1 (wrong native host wins) — reproduces on Windows

Both native‑messaging hosts are registered, in both Chrome and Edge:

HKCU\Software\Google\Chrome\NativeMessagingHosts\
  com.anthropic.claude_browser_extension       -> %APPDATA%\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json        (Claude Desktop)
  com.anthropic.claude_code_browser_extension  -> %APPDATA%\Claude Code\ChromeNativeHost\com.anthropic.claude_code_browser_extension.json (Claude Code)

HKCU\Software\Microsoft\Edge\NativeMessagingHosts\   (identical pair)

The Desktop host is the one the browser actually connects to — its process is live and bound to the extension:

PID 54052: %APPDATA%\Claude\ChromeNativeHost\chrome-native-host.exe
           chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ --parent-window=0

So Claude Code's host (%APPDATA%\Claude Code\ChromeNativeHost\ → %USERPROFILE%\.local\bin\claude.exe --chrome-native-host) is never reached — same Desktop‑wins behavior described in Bug 1, on Windows.

Bug 2 (stale hardcoded path in wrapper) — does NOT apply here

The Claude Code wrapper already targets a version‑agnostic path, which is the fix this report suggests:

%USERPROFILE%\.claude\chrome\chrome-native-host.bat
  -> "%USERPROFILE%\.local\bin\claude.exe" --chrome-native-host

Bug 3 (setMcpServers silent no‑op) — reproduces on Windows (root cause)

From the VS Code extension log (Claude VSCode.log):

• Agent (SDK query) is spawned with --no-chrome; its startup MCP config does not include claude-in-chrome.
• Chrome MCP: Successfully connected to server (extension↔bridge link is up).
• @browser user message injects <browser_instruction>… mcp__claude-in-chrome__* …</browser_instruction> plus <browser tabId="undefined">.
• Main agent model is claude-opus-4-8[1m] (capable; the claude-haiku-4-5 line in the log is only the session‑title generator).
• The claude-in-chrome tools never enter the deferred‑tool pool:
• with tool search on: ToolSearchTool: select failed — none found: mcp__claude-in-chrome__tabs_context_mcp, … and Dynamic tool loading: 0/147 deferred tools included
• with ENABLE_TOOL_SEARCH=false (all tools loaded directly): tools still absent, agent still reports them unavailable.

So it is not tool‑search‑specific, not a model issue, and not a version mismatch — the claude-in-chrome server is never registered into the agent session, exactly matching Bug 3.

Already ruled out on this machine

• Stale extension version (removed leftover 2.1.154; everything is 2.1.156).
• Tool search / dynamic tool loading (reproduces with ENABLE_TOOL_SEARCH=false).
• MCP tool overload.
• Model capability (Opus 4.8).
• Browser pairing (bridge connects; "Browser Connected" banner shows; chromeExtension.pairedDeviceName set).

Happy to provide full logs / process trees if useful.

Reproduced on another machine/account — adding a data point.

Env: macOS Darwin 25.5.0 (arm64) · Chrome 148.0.7778.215 · extension fcoeoabgfenejglbffodgkkbkcdhcgfn v1.0.74 (Default profile) · Claude Code VS Code ext 2.1.159 · CLI 2.1.114 · direct OAuth (not Bedrock/Vertex) · Claude.app desktop also installed.

Confirms Bug 1: the shared extension is bound to the desktop host — PID 729 /Applications/Claude.app/Contents/Helpers/chrome-native-host chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ — and that process survives a full Cmd+Q of Claude.app (Chrome keeps the native port open), so quitting the desktop app does not free the extension. In the VS Code extension, @browser:new_tab yields <browser tabId="undefined"> and mcp__claude-in-chrome__* never enters the deferred-tool pool (ToolSearch … 0 matches).

Notable: on the same machine, same moment, claude --chrome from the CLI pairs and drives Chrome fine — only the VS Code extension path fails. The VS Code extension also has no /chrome command, so there's no in-extension way to force a reconnect.

Fixed on my end 🙂 Closing the issue, will reopen it if error occurs again