[BUG] Claude in Chrome MCP server cannot connect to native messaging host on Windows - getSocketPaths missing named pipe path

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?

On Windows, the Claude in Chrome MCP server (--claude-in-chrome-mcp) cannot connect to the native messaging host (--chrome-native-host) because getSocketPaths (the function that discovers available sockets for the MCP pool client) returns only Unix-style file paths but never the Windows named pipe path.

The native messaging host correctly creates a pipe server at \\.\pipe\claude-mcp-browser-bridge-{username} using a different function (yW6), but the MCP pool client only queries getSocketPaths ($c4) which returns:

• {os.tmpdir()}\claude-mcp-browser-bridge-{username} (e.g. C:\Users\Adam\AppData\Local\Temp\claude-mcp-browser-bridge-Adam)
• - /tmp/claude-mcp-browser-bridge-{username}

Neither of these is a Windows named pipe. Node.js net.connect() with a raw file path attempts an AF_UNIX socket connection (which fails with ENOENT on Windows), so the MCP server can never reach the native messaging host.

The result is that tabs_context_mcp and all other Claude in Chrome tools always return "Browser extension is not connected" on Windows, even though the pipe infrastructure is fully functional.

What Should Happen?

getSocketPaths should include the Windows named pipe path \\.\pipe\claude-mcp-browser-bridge-{username} on Windows, so the MCP pool client can discover and connect to the native messaging host's pipe server.

Suggested fix: Add the following to getSocketPaths ($c4) before return:

if (platform() === "win32") {
  let pipePath = `\\\\.\\pipe\\${bridgeName}`;
  if (!paths.includes(pipePath)) paths.push(pipePath);
}

After applying this patch to cli.js, tabs_context_mcp immediately returns connected tabs on Windows.

Error Messages/Logs

// Testing socket paths returned by getSocketPaths ($c4):
net.connect('C:\\Users\\Adam\\AppData\\Local\\Temp\\claude-mcp-browser-bridge-Adam')
// -> ENOENT (AF_UNIX socket, does not exist on Windows)

net.connect('/tmp/claude-mcp-browser-bridge-Adam')
// -> ENOENT

// But the native messaging host pipe IS alive:
net.connect('\\\\.\\pipe\\claude-mcp-browser-bridge-Adam')
// -> Connected!

// tabs_context_mcp always returns:
// "Browser extension is not connected"

Steps to Reproduce

a1. Install Claude Code on Windows (npm install -g @anthropic-ai/claude-code)

1. Install the Claude in Chrome extension (https://claude.ai/chrome)
2. 3. Open Chrome and ensure the extension is active
3. 4. Run claude in terminal
4. 5. Try any Claude in Chrome tool (e.g. tabs_context_mcp)
5. 6. Result: "Browser extension is not connected"

The native messaging host process starts and creates a named pipe at \\.\pipe\claude-mcp-browser-bridge-{username}, but the MCP server's pool client never attempts to connect to it because getSocketPaths doesn't include that path.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.32

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Node.js v24.12.0
• - Chrome Extension v1.0.45 (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
• - - The bug is in getSocketPaths function (minified as $c4 in cli.js). It returns Unix-style socket paths but not the Windows named pipe path that the native messaging host actually listens on.
• - - - The companion function yW6 correctly handles Windows by returning \\.\pipe\claude-mcp-browser-bridge-{username}, but getSocketPaths does not include this path.
• - - - - Verified fix: adding the named pipe path to getSocketPaths on win32 platform immediately resolves the issue.