[BUG] Chrome MCP bridge handshake fails on Windows 2.1.138 even though pipe and registry verified OK

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

With Claude Code 2.1.138 on Windows + Claude in Chrome extension v1.0.70 Beta + Claude Desktop also installed on the same machine:

When running claude --chrome and trying any browser MCP tool ("list open Chrome tabs", list_connected_browsers, etc), the response is always:

Browser extension is not connected.

Despite all of the following being verified correct:

• claude.exe --chrome-native-host launches successfully when Chrome calls the .bat
• Pipe \\.\pipe\claude-mcp-browser-bridge-Windows is created and accepts external client connections (verified with PowerShell System.IO.Pipes.NamedPipeClientStream — connect succeeds)
• Process tree confirmed: chrome.exe → cmd.exe → claude.exe --chrome-native-host
• Registry entry, manifest path, allowed_origins, claude.ai login state, Chrome sidebar — all correct
• Tested after a full Windows restart with Chrome opened first and claude --chrome opened second in a clean terminal

Root cause likely identified: When Claude Desktop is also installed, it registers com.anthropic.claude_browser_extension (its own native host), while Claude Code registers a separate name com.anthropic.claude_code_browser_extension. The Chrome extension only calls com.anthropic.claude_browser_extension — never claude_code_browser_extension. Result: the extension talks to Claude Desktop's native host, while Claude Code CLI sits idle waiting for a bridge that never engages.

Workaround attempted (failed): Redirected the claude_browser_extension registry entry to point to Claude Code's .bat. Chrome launched the correct .bat, native host created the pipe, external clients could connect — but claude --chrome CLI session still reported "extension not connected".

Additionally, Claude Desktop overwrites this registry entry every launch, reverting any manual fix.

Earlier bug (already fixed in 2.1.138): Versions 2.1.126 and 2.1.128 had claude.exe --chrome-native-host crash at startup with TypeError: Failed to listen at \\.\pipe\... code: "ERR_INVALID_ARG_TYPE". That listen-side bug is fixed in 2.1.138 — but the handshake-side bug between CLI and native host remains.

What Should Happen?

claude --chrome should be able to communicate with the Chrome extension via the bridge so that browser MCP tools (list_connected_browsers, navigate, read_page, etc.) work end-to-end. The handshake between the CLI and the native host should succeed once the pipe is established.

Suggested fixes (any of these):

1. Have the Chrome extension fall back to com.anthropic.claude_code_browser_extension when com.anthropic.claude_browser_extension doesn't respond to a Claude Code-specific handshake.
2. Use a single shared native host name with a router that forwards to Desktop or Code as needed.
3. Add a --chrome-native-host-name CLI flag so Claude Code can match whatever name the extension is currently calling.
4. Document explicitly that Chrome MCP from CLI requires Claude Desktop to be uninstalled (this seems to be the current de facto behavior on Windows).

Error Messages/Logs

=== Native host crash on 2.1.126/2.1.128 (FIXED in 2.1.138) ===

[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-Windows
[Claude Chrome Native Host] Socket server error
TypeError: Failed to listen at \\.\pipe\claude-mcp-browser-bridge-Windows
 code: "ERR_INVALID_ARG_TYPE"
      at listen (unknown:1:1)
      at listenInCluster (node:net:1423:24)
      at listen (node:net:1331:20)

=== Native host log (Claude Desktop's bundled chrome-native-host.exe v0.1.0) ===
Path: %LOCALAPPDATA%\Claude\Logs\chrome-native-host.log

[2026-05-09 12:36:57 INFO] Chrome native host starting (version 0.1.0)
[2026-05-09 12:36:57 INFO] Creating Windows named pipe: \\.\pipe\claude-mcp-browser-bridge-Windows
[2026-05-09 12:36:57 INFO] Named pipe created successfully
[2026-05-09 12:36:57 INFO] Socket server listening for connections
[2026-05-09 12:48:41 INFO] Accepted new MCP connection (client 1). Total clients: 1
[2026-05-09 12:48:41 INFO] MCP client 1 connected
[2026-05-09 12:48:41 INFO] MCP client 1 disconnected
[2026-05-09 12:48:41 INFO] Cleaned up MCP client 1. Remaining clients: 0

=== Native host running after registry redirect (claude.exe --chrome-native-host, v2.1.138) ===
Process tree confirmed via WMI:
- PID 20336: claude.exe --chrome-native-host (Claude Code 2.1.138 from npm)
- parent PID 17592: cmd.exe running chrome-native-host.bat
- parent PID 10852: chrome.exe

CommandLine of cmd.exe parent (showing Chrome's Native Messaging stdin/stdout pipes):
"chrome-native-host.bat" chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ --parent-window=0
< \\.\pipe\chrome.nativeMessaging.in.4eee3d58547a8230
> \\.\pipe\chrome.nativeMessaging.out.4eee3d58547a8230

claude.exe --chrome-native-host stderr is captured by Chrome Native Messaging — no log file accessible.
Despite all infrastructure being in place (registry, manifest, pipe, native host process alive, Chrome connected to native host stdin/stdout), `claude --chrome` CLI reports "extension not connected" indefinitely.

Steps to Reproduce

1. On Windows 10/11, install both Claude Desktop and Claude Code (via npm install -g @anthropic-ai/claude-code, version 2.1.138).
2. Install the "Claude in Chrome" extension v1.0.70 Beta from the Chrome Web Store.
3. Sign in to claude.ai in Chrome (any plan that includes Claude Code, e.g. Max).
4. Verify both native hosts are registered separately in HKCU\Software\Google\Chrome\NativeMessagingHosts:

• com.anthropic.claude_browser_extension (points to Claude Desktop's bundled chrome-native-host.exe)
• com.anthropic.claude_code_browser_extension (points to Claude Code's chrome-native-host.bat)

1. Open Chrome (the extension auto-loads).
2. Open PowerShell, run: claude --chrome.
3. Wait for the welcome banner. Verify /chrome shows Status: Enabled, Extension: Installed.
4. Type: list my open Chrome tabs (or any browser MCP request).
5. Observe: response is "Browser extension is not connected." even though the extension IS installed, signed in, and visible in Chrome's toolbar.

Additional reproduction with registry redirect workaround applied (also fails)

1. Modify HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension to point to a custom JSON manifest where name=com.anthropic.claude_browser_extension but path=C:\Users\<user>\.claude\chrome\chrome-native-host.bat.
2. Restart Chrome.
3. Verify Chrome now spawns claude.exe --chrome-native-host (process tree visible via WMI / Get-CimInstance Win32_Process).
4. Verify pipe \\.\pipe\claude-mcp-browser-bridge-Windows is created and externally connectable (PowerShell System.IO.Pipes.NamedPipeClientStream connects successfully).
5. Run claude --chrome again, type the same browser MCP request.
6. Same "extension not connected" response.

Note on Claude Desktop interaction

After the workaround above, Claude Desktop will overwrite the registry entry back to its own native host on the next launch (including auto-launch after Windows reboot), reverting the workaround. The two products appear to assume mutual exclusivity on Windows but neither documents this.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.138 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Additional verification done

• The Chrome extension works correctly as a regular Claude.ai sidebar (chat works, sidebar opens, login OK). Only the Claude Code MCP bridge fails, the rest of the extension is fine.
• The Chrome extension's options page (chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/options.html) does NOT expose any setting to choose between Claude Desktop and Claude Code as backend. There is no UI workaround.
• Username on this machine is literally Windows (C:\Users\Windows), so the pipe ends up being \\.\pipe\claude-mcp-browser-bridge-Windows. Mentioning this in case the username string is involved in pipe naming and the literal "Windows" collides with reserved tokens internally (the 2.1.126/2.1.128 listen crash that was fixed in 2.1.138 had this username embedded in the pipe path).
• The Chrome extension service worker (inspected via chrome://extensions → "service worker" link) shows no console errors at all — it just sits idle.
• Avast Antivirus and Windows Firewall are active but not blocking — the pipe is created and external clients (PowerShell test) can connect.
• Affected user has the Claude Max plan with crisantventas@gmail.com directly via Anthropic (not Bedrock / Vertex / Foundry).
• Total time spent debugging: ~3 hours, including a full Windows reboot, version upgrade 2.1.126 → 2.1.138, registry redirect, killing Claude Desktop, and ordered Chrome+CLI restarts. None worked.