[BUG] Chrome integration broken on Windows: MCP server socket discovery missing Windows 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 Chrome native host listens on a Windows named pipe (\\.\pipe\claude-mcp-browser-bridge-{username}) via the uW6() function. However, the MCP server's socket path discovery function (Gc4() in cli.js) never includes Windows named pipe paths in its returned array. It only returns:

1. {os.tmpdir()}\claude-mcp-browser-bridge-{username} (regular file path, doesn't exist as a socket)
2. 2. /tmp/claude-mcp-browser-bridge-{username} (Unix path, doesn't exist on Windows)

The socket pool client (xzq) iterates through the paths returned by Gc4() and never tries the named pipe, so the MCP server never connects to the native host. The Chrome extension reports "Browser extension is not connected."

This affects all Windows users using the npm installation. On Unix/macOS this works because both sides use the same /tmp/ directory convention with .sock files. On Windows, the native host creates a named pipe but the discovery function was never updated to include named pipes.

What Should Happen?

The MCP server's socket path discovery function (Gc4() in cli.js) should include the Windows named pipe path \\.\pipe\claude-mcp-browser-bridge-{username} in its returned array when running on Windows (process.platform === "win32"). This would allow the socket pool client to find and connect to the native host's named pipe, enabling the Chrome integration to work on Windows.

Error Messages/Logs

No error is displayed to the user. The Chrome extension simply reports "Browser extension is not connected" when running `/chrome`.

Debug logging from the MCP server shows it trying these paths and failing:
- C:\Users\{user}\AppData\Local\Temp\claude-mcp-browser-bridge-{user} (doesn't exist as a socket)
- /tmp/claude-mcp-browser-bridge-{user} (doesn't exist on Windows)

Meanwhile the native host is successfully listening on:
- \\.\pipe\claude-mcp-browser-bridge-{user} (never attempted by the MCP server)

Verified the named pipe works by connecting directly:

const net = require('net');
net.createConnection('\\\\.\\pipe\\claude-mcp-browser-bridge-{user}')
  .on('connect', () => console.log('CONNECTED OK'));
// Result: CONNECTED OK

Steps to Reproduce

1. Install Claude Code via npm on Windows: npm install -g @anthropic-ai/claude-code
2. Install Chrome extension "Claude" (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn) and enable it
3. Run /chrome in Claude Code
4. Observe: "Browser extension is not connected"

The native host starts and listens on \\.\pipe\claude-mcp-browser-bridge-{username} successfully, but the MCP server's socket discovery function (Gc4()) never includes this Windows named pipe path in its search list. It only searches:

• {os.tmpdir()}\claude-mcp-browser-bridge-{username} (file path, not a pipe)
• /tmp/claude-mcp-browser-bridge-{username} (Unix path, doesn't exist on Windows)

On Unix/macOS this works because both sides use /tmp/ directory convention with .sock files. On Windows, the native host creates a named pipe but the discovery function never looks for it.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.34

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Root Cause

In cli.js (minified), the Gc4() function discovers socket paths:

function Gc4(){
  let A=[], q=ZQ1(); // "/tmp/claude-mcp-browser-bridge-{user}"
  try{let w=zCY(q); for(let H of w) if(H.endsWith(".sock")) A.push(hR(q,H))} catch{}
  let K=`claude-mcp-browser-bridge-${ILA()}`,
      Y=hR(KCY(),K),   // path.join(os.tmpdir(), bridgeName)
      z=`/tmp/${K}`;    // /tmp/claude-mcp-browser-bridge-{user}
  if(!A.includes(Y)) A.push(Y);
  if(Y!==z && !A.includes(z)) A.push(z);
  return A  // NEVER includes \\.\pipe\... on Windows
}

The native host uses uW6() which correctly returns a Windows named pipe on win32:

function uW6(){
  if(qCY()==="win32") return `\\\\.\\pipe\\${$CY()}`; // \\.\pipe\claude-mcp-browser-bridge-{user}
  return hR(ZQ1(),`${process.pid}.sock`)
}

Suggested Fix

Add Windows named pipe to Gc4():

// After: if(Y!==z && !A.includes(z)) A.push(z);
// Add:
if(process.platform === "win32"){
  let W = `\\\\.\\pipe\\${K}`;
  if(!A.includes(W)) A.push(W);
}
return A;

Environment

• OS: Windows 11
• Claude Code: 2.1.34 (npm installation)
• Node.js: v24.13.0 (via fnm)
• Chrome extension: Claude v1.0.45
• Chrome extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn

Verification

Confirmed the named pipe works by testing directly:

const net = require('net');
net.createConnection('\\\\.\\pipe\\claude-mcp-browser-bridge-{user}')
  .on('connect', () => console.log('CONNECTED OK'));
// Result: CONNECTED OK

After manually patching Gc4() to include the named pipe path, /chrome works correctly on Windows.