Claude in Chrome: MCP client uses Unix socket paths instead of named pipes on Windows

Bug Description

The Claude in Chrome MCP server correctly creates its listener on a Windows named pipe (\.\pipe\claude-mcp-browser-bridge-{username}), but the client-side getSocketPaths function (cc4 in minified code) never includes the named pipe path. It only returns Unix-style paths (/tmp/... and os.tmpdir()/...), so the MCP client never finds the server on Windows.

Environment

• OS: Windows 11 (Build 26200)
• Claude Code: v2.1.37 (npm global install)
• Node.js: v24.11.1
• Chrome: v144.0.7559.133
• Claude Extension: v1.0.47

Steps to Reproduce

1. Install Claude Code globally on Windows via npm
2. Install the Claude Chrome extension
3. Start Claude Code CLI
4. Call tabs_context_mcp — returns "Browser extension is not connected"

Debug Logs

The MCP server (from --claude-in-chrome-mcp process debug log):

[Claude in Chrome] Attempting to connect to: /tmp/claude-mcp-browser-bridge-bigfa
[Claude in Chrome] Socket error (code: ENOENT): Error: connect ENOENT C:\Users\bigfa\AppData\Local\Temp\claude-mcp-browser-bridge-bigfa
[Claude in Chrome] Socket error (code: ENOENT): Error: connect ENOENT /tmp/claude-mcp-browser-bridge-bigfa
[Claude in Chrome] No connected sockets in pool

Meanwhile, the native host (spawned by Chrome) successfully creates:

[Claude Chrome Native Host] Creating socket listener: \.\pipe\claude-mcp-browser-bridge-bigfa

The MCP client tries /tmp/... and os.tmpdir()/... but never tries \.\pipe\....

Additionally, Unix domain sockets (AF_UNIX) fail with EACCES on this Windows build, so even if the paths matched, file-based IPC wouldn't work — only Windows named pipes function correctly.

Root Cause

In the minified CLI source, the getSocketPaths function (cc4) enumerates:

1. .sock files in /tmp/claude-mcp-browser-bridge-{user}/
2. os.tmpdir()/claude-mcp-browser-bridge-{user}
3. /tmp/claude-mcp-browser-bridge-{user}

But it never includes \.\pipe\claude-mcp-browser-bridge-{user}, even though:

• The socketPath function (tW6) correctly returns \.\pipe\... on win32
• The native host creates the pipe at \.\pipe\...

Workaround

Patch cli.js to add the named pipe path to the getSocketPaths return value on Windows:

// In cc4() / getSocketPaths(), before `return A}`:
if (process.platform === "win32") {
  let P = "\\.\pipe\\" + K;
  if (!A.includes(P)) A.push(P);
}

This patch resolves the issue immediately — tabs_context_mcp returns tab data after applying it and restarting the MCP process.

Expected Behavior

The MCP client should include \.\pipe\claude-mcp-browser-bridge-{username} in its list of socket paths to try on Windows, since that's where the native host creates its listener.