[Bug] Claude in Chrome MCP bridge fails on Windows - socket discovery doesn't find named pipes

[Leoezlo]

Bug Description

Claude in Chrome browser automation tools always return "Browser extension is not connected" on Windows, even though the native host is running correctly and the named pipe exists. The MCP server cannot discover the native host's pipe.

Platform

• OS: Windows 10 (build 19045)
• Claude Code: 2.1.20 (latest)
• Browser: Chrome (also tested with Brave)
• Extension: Claude in Chrome (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Node.js: v24.12.0

Root Cause Analysis

The native host (--chrome-native-host, class GvK) creates a named pipe server at \.\pipe\claude-mcp-browser-bridge-<username>.

The MCP server (--claude-in-chrome-mcp, function JvK) uses getSocketPaths() (function Bw7) to discover native host sockets. However, Bw7() only returns file system paths:

1. Lists .sock files in /tmp/claude-mcp-browser-bridge-<username>/ (Unix-only, doesn't exist on Windows)
2. path.join(os.tmpdir(), 'claude-mcp-browser-bridge-<username>') → C:\Users\<user>\AppData\Local\Temp\claude-mcp-browser-bridge-<username> (a file path, not a pipe)
3. /tmp/claude-mcp-browser-bridge-<username> (Unix path, doesn't exist on Windows)

None of these are the Windows named pipe path \.\pipe\claude-mcp-browser-bridge-<username>.

The socketPath from TO1() correctly returns the Windows named pipe path on win32, but either the MCP server doesn't use it for client-side discovery, or it only attempts connection at startup before the native host exists.

Evidence

All verified during debugging:

Check	Result
Registry (HKCU\SOFTWARE\Google\Chrome\NativeMessagingHosts)	Correct: com.anthropic.claude_code_browser_extension only
Native host manifest JSON	Correct path and allowed_origins
Chrome spawns native host	Verified via wmic (parent PID = chrome.exe)
Named pipe exists	\.\pipe\claude-mcp-browser-bridge-jesus present
Pipe accepts connections	Tested with PowerShell NamedPipeClientStream and Node.js net.createConnection
MCP server responds on pipe	Sent native messaging format message, got {"result":{"content":"Unknown method: undefined"}}
Killing native host removes pipe	Pipe disappears → native host owns it (is the server)
MCP server still running after pipe removed	Confirmed → MCP server is not the pipe owner
Temp directory has bridge socket	No claude-mcp-browser-bridge-* file in %TEMP% or /tmp
tabs_context_mcp works	Always returns "Browser extension is not connected"

Steps to Reproduce

1. Install Claude Code 2.1.20 on Windows
2. Install Claude in Chrome extension in Chrome
3. Run claude (starts MCP server subprocess)
4. Open Chrome (extension spawns native host)
5. Call any mcp__claude-in-chrome__* tool → "Browser extension is not connected"

Expected Behavior

The MCP server should discover and connect to the native host's Windows named pipe at \.\pipe\claude-mcp-browser-bridge-<username>.

Suggested Fix

Bw7() (getSocketPaths) should include the Windows named pipe path when process.platform === 'win32':

if (platform === 'win32') {
  paths.push(`\\.\pipe\claude-mcp-browser-bridge-${username}`);
}

Or the MCP server should also try connecting to socketPath (from TO1()) when discovering native hosts, not just the paths from getSocketPaths().

Related Issues

• Claude in Chrome browser extension not connecting to Claude Code CLI #20298, [Bug] Claude Desktop native messaging host intercepts Chrome extension connection, blocking Claude Code integration #20341, [BUG] Chrome extension not connecting to native messaging host (macOS 26.2) #20663, Chrome issue #20779, Chrome MCP: Extension connects to Claude Desktop instead of Claude Code when both are installed #20887 (all macOS - this is the Windows equivalent)

Additional Context

• Claude Desktop was never installed on this machine (or was fully uninstalled including registry entries before testing)
• No competing native messaging hosts
• Extensively debugged over 3+ hours including process analysis, pipe protocol testing, and source code review of the minified cli.js
• Dan Guido's X post documents the macOS version of this issue; this is the Windows-specific variant where the socket discovery architecture fundamentally doesn't work with Windows named pipes

[github-actions]

Found 3 possible duplicate issues:

1. claude-in-chrome MCP connection fails despite correct configuration (Windows) #21301
2. Claude in Chrome extension not connecting on Windows despite MCP server showing "connected" #21300
3. Chrome extension not connecting on Windows 11 (Build 26200) #21330

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

[Leoezlo]

Important Update: This is a regression, not a design flaw

The original report incorrectly characterized this as a fundamental Windows architecture issue. Claude in Chrome has been working flawlessly on this Windows machine for months (across Windows 10 and Windows 11 machines).

Timeline

• 2.1.19 (published Jan 23): Chrome integration was working fine
• 2.1.20 (published Jan 27 at 00:39 UTC): Chrome integration broke — discovered this morning when tabs_context_mcp started returning "Browser extension is not connected"

What this means

The Bw7() / getSocketPaths() function (or the MCP server's socket discovery logic) was finding the Windows named pipe in previous versions. Something in 2.1.20 (or possibly a recent internal refactor) changed the socket discovery or connection architecture in a way that broke Windows named pipe discovery.

The changelog for 2.1.20 does not mention Chrome/MCP/socket changes, so this is likely a side effect of an internal refactor.

Previous version that worked

Unfortunately I cannot confirm the exact last-working version, but 2.1.19 or earlier was functioning correctly on Windows with the Chrome extension.

Suggested investigation

A diff of the socket discovery (getSocketPaths / Bw7) and MCP bridge connection logic between 2.1.19 and 2.1.20 should reveal the regression.

[Leoezlo]

Confirmed: MCP bridge works on 2.1.19, broken in 2.1.20

Environment: Windows 11, Claude Code 2.1.19 (downgraded from 2.1.20)

Test: Called mcp__claude-in-chrome__tabs_context_mcp with createIfEmpty: true

Result on 2.1.19: ✅ Success — returned valid tab context:

{
  "availableTabs": [{"tabId": 1620920280, "title": "New Tab", "url": "chrome://newtab"}],
  "tabGroupId": 934554101
}

Result on 2.1.20: ❌ Fails — MCP server cannot find Windows named pipes (socket discovery in Bw7/getSocketPaths broken).

This confirms the regression was introduced in 2.1.20. The Chrome MCP bridge's Windows named pipe discovery stopped working in that release.

[ajohnclark]

Confirmed downgrading to 2.1.19 fixes this issue on Windows 11-latest/Chrome-latest.

[wickedside]

Same problem here, on 2.1.20/2.1.21.
Claude Code can't connect to claude in chrome extension on Windows 10/11
Downgrading to 2.1.19 works somehow

[ryzamedia]

Today's update to 2.1.21 did not fix it unfortunately.