[Windows] MCP tools return "Browser extension is not connected" while native host process is alive and pipe is reachable (v2.1.141)

Summary

On Windows 11 with Claude Code v2.1.141, the claude --chrome integration appears fully wired (extension installed, manifest registered, native host process alive for minutes, named pipe reachable by external clients), yet every MCP tool call (e.g. mcp__claude-in-chrome__tabs_context_mcp) returns Browser extension is not connected. This looks like the same family as #23828 / #22890 / #23526 but on the current latest release.

Environment

| Item | Value |
|------|-------|
| OS | Windows 11 Home 10.0.26200 |
| Shell | PowerShell 7 |
| Claude Code CLI | v2.1.141 (npm latest, also next) |
| Chrome | latest stable |
| Claude in Chrome extension | v1.0.70 (Beta), ID fcoeoabgfenejglbffodgkkbkcdhcgfn |
| Started with | claude --chrome |
| npm dist-tags observed | latest=2.1.141, next=2.1.141, stable=2.1.128 |

Steps to reproduce

1. claude --chrome in PowerShell.
2. Open Chrome with the extension installed and signed in (same Anthropic account).
3. Call any mcp__claude-in-chrome__* tool from the Claude Code session.

Expected

Tool call returns tab context / executes the requested action.

Actual

Browser extension is not connected. Please ensure the Claude browser extension is installed and running (https://claude.ai/chrome), and that you are logged into claude.ai with the same account as Claude Code. ...

/chrome slash command shows Status: Enabled, Extension: Installed, but pressing Reconnect opens a Chrome child window that closes immediately.

Diagnostic data — what looks CORRECT

• Single Native Messaging manifest registered:
• Key: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension
• Path: C:\Users\<user>\.claude\chrome\chrome-native-host.bat
• allowed_origins: chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ (matches installed extension exactly)
• .bat wrapper content (160 bytes):

``bat
@echo off
REM Chrome native host wrapper script
REM Generated by Claude Code - do not edit manually
"C:\Users\<user>\.local\bin\claude.exe" --chrome-native-host
``

• Two claude.exe processes alive simultaneously (expected pair):
• Main session: claude.exe --chrome
• Native host: claude.exe --chrome-native-host (parent: cmd.exe ... chrome-native-host.bat ..., with stdin/stdout redirected through \\.\pipe\chrome.nativeMessaging.in/out.<hash>)
• Named pipe \\.\pipe\claude-mcp-browser-bridge-<user> exists and accepts client connections:

``powershell
$c = [System.IO.Pipes.NamedPipeClientStream]::new(".", "claude-mcp-browser-bridge-<user>", "InOut")
$c.Connect(1500) # → Connect OK, IsConnected = True
``

• Native host process stays alive for many minutes (does not exit).
• No CLAUDE_* / ANTHROPIC_* env vars that would disable chrome mode.

Diagnostic data — what looks WRONG

When claude.exe --chrome-native-host is launched manually (without the Chrome stdin/stdout redirect) for inspection, stderr begins with:

[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-<user>
[Claude Chrome Native Host] Socket server error: <minified JS stack trace follows>

So the native host attempts to create a socket listener on a pipe name that is already in use by the running main --chrome session (or by a previously spawned native host instance). The error does not always kill the process, but the integration is left in a half-broken state where MCP requests fail.

Console errors observed inside the extension's DevTools (PermissionManager-*.js):

NATIVE RESULT: Native host has exited.
NATIVE RESULT: Native host has exited.

These appear when calling chrome.runtime.connectNative('com.anthropic.claude_code_browser_extension') from DevTools — likely because a second native host instance dies on pipe-name collision while the first one keeps running. This may be a red herring (side effect of duplicate connectNative()), but the underlying MCP failure persists regardless.

Also seen, but probably unrelated:

Datadog Browser SDK: SDK is loaded more than once.

(Persists even after extension uninstall + reinstall, with Codex extension disabled and Claude Desktop fully uninstalled — likely benign telemetry duplication.)

What I have already tried (none fixed the issue)

• Removed Claude Desktop app entirely (uninstalled via Settings → Apps).
• Backed up and deleted the stale Desktop Native Messaging registry key (com.anthropic.claude_browser_extension).
• Disabled the Codex Chrome extension (hehggadaopoacecdllhhajmbjkdcmajg) and fully restarted Chrome.
• Uninstalled and reinstalled the Claude in Chrome extension via https://claude.ai/chrome.
• Multiple claude --chrome session restarts after each step.
• Verified registry is clean: only com.anthropic.claude_code_browser_extension remains, no HKLM entries.
• Verified no leftover lock/socket/config files under C:\Users\<user>\.claude\chrome\.

Related issues

• #23828 — "native host is alive but MCP is not connected" (very similar pattern)
• #22890 — Windows getSocketPaths() cannot locate the named pipe
• #23526 — Windows Bun named pipe crash
• #20663 — macOS report of "Browser extension is not connected" (mentioned for completeness; current issue is Windows-flavored)

Open questions for maintainers

1. Is the native host meant to be the pipe server (listener), with claude --chrome (or its MCP client) acting as client? If so, why is the native host's Creating socket listener call hitting Socket server error while a pipe with the same name is already alive?
2. Is claude --chrome and claude --chrome-native-host ever expected to coexist as separate processes both touching \\.\pipe\claude-mcp-browser-bridge-<user>?
3. On Windows, what is the canonical way to verify which claude.exe instance owns the pipe handle (no equivalent of lsof available out of the box; handle.exe is not preinstalled)?
4. Is there a known-good rollback version (perhaps stable 2.1.128) where this works?

Verification I can perform on request

Happy to run any additional commands (process listing, registry export, stderr capture with specific flags, debug logging level). All diagnostic data above was captured from PowerShell on a clean system after removing Claude Desktop.