Claude in Chrome: MCP server uses Unix socket paths instead of Windows named pipe (v2.1.37)

Bug Description

The "Claude in Chrome" MCP server fails to connect to the Chrome native host on Windows because getSocketPaths() only returns Unix domain socket paths, never the Windows named pipe path. The socketPath property IS correctly set to the named pipe, but the socket pool mechanism (getSocketPaths) takes priority in the selection logic, so the named pipe is never tried.

Environment

• Claude Code version: 2.1.37
• OS: Windows 11 24H2 (AzureAD-managed)
• Node.js: v22.22.0 (Bun runtime in claude.exe)
• Chrome extension: v1.0.47 (from Web Store)
• Last working: Feb 3, 2026 (before the Feb 7 update to v2.1.37)

Steps to Reproduce

1. Install Claude Code v2.1.37 on Windows
2. Install the Claude in Chrome extension
3. Complete Chrome onboarding
4. Use any mcp__claude-in-chrome__* tool (e.g., tabs_context_mcp)
5. Get "Browser extension is not connected" error

Expected Behavior

The MCP server should connect to the native host via the Windows named pipe at \\.\pipe\claude-mcp-browser-bridge-{username}.

Actual Behavior

The MCP server only tries Unix domain socket paths and never reaches the named pipe:

[Claude in Chrome] Adding socket to pool: C:\Users\NICOLA~1\AppData\Local\Temp\claude-mcp-browser-bridge-NicolasAlbana
[Claude in Chrome] Adding socket to pool: /tmp/claude-mcp-browser-bridge-NicolasAlbana
[Claude in Chrome] Socket error (code: ENOENT): connect ENOENT C:\Users\NICOLA~1\AppData\Local\Temp\claude-mcp-browser-bridge-NicolasAlbana
[Claude in Chrome] Socket error (code: ENOENT): connect ENOENT /tmp/claude-mcp-browser-bridge-NicolasAlbana
[Claude in Chrome] No connected sockets in pool

Meanwhile, the native host successfully creates the named pipe (verified accessible via PowerShell):

\\.\pipe\claude-mcp-browser-bridge-NicolasAlbana

Root Cause Analysis

Extracted from the bundled source in claude.exe:

Native host (correct - creates named pipe on Windows):

// getPipePath
function getPipePath() {
    if (os.platform() === "win32") return `\\\\.\\pipe\\${bridgeName}`;
    return path.join(socketDir, `${process.pid}.sock`);
}

MCP server (bug - only returns Unix socket paths):

// getSocketPaths
function getSocketPaths() {
    let paths = [];
    // ... scans for .sock files ...
    let tempPath = path.join(os.tmpdir(), bridgeName);  // %TEMP%/bridge-name
    let tmpPath = `/tmp/${bridgeName}`;                   // /tmp/bridge-name
    // Never includes \\.\pipe\... path!
    return paths;
}

Initialization (socketPath set but overridden):

let config = {
    socketPath: getPipePath(),   // \\.\pipe\claude-mcp-browser-bridge-{user} (correct!)
    getSocketPaths: getSocketPaths,  // Only returns Unix socket paths (bug!)
};

Selection logic (getSocketPaths takes priority over socketPath):

function selectConnection(config) {
    return config.bridgeConfig ? useBridge(config) :
           config.getSocketPaths ? useSocketPool(config) :  // <-- Always takes this path
           useSingleSocket(config);  // Would use socketPath (named pipe) but never reached
}

Additional Context

• AF_UNIX sockets fail on this machine with EACCES despite afunix.sys being loaded and Developer Mode enabled (likely AzureAD enterprise policy restriction)
• The native host log shows MCP client connections that immediately disconnect (the MCP server connects to the pipe briefly during initialization but then switches to the socket pool which fails)
• Workaround attempted: Creating a Node.js bridge proxy (Unix socket to named pipe) also fails due to AF_UNIX EACCES
• The VS Code Claude Code extension (same v2.1.37) was verified NOT to be the cause - it uses the identical binary and doesn't introduce conflicts

Suggested Fix

In getSocketPaths(), include the Windows named pipe path on win32 platforms:

function getSocketPaths() {
    let paths = [];
    // ... existing .sock file scanning ...

    if (process.platform === "win32") {
        // Include the named pipe path on Windows
        paths.push(`\\\\.\\pipe\\${bridgeName}`);
    }

    let tempPath = path.join(os.tmpdir(), bridgeName);
    let tmpPath = `/tmp/${bridgeName}`;
    if (!paths.includes(tempPath)) paths.push(tempPath);
    if (tempPath !== tmpPath && !paths.includes(tmpPath)) paths.push(tmpPath);
    return paths;
}

Alternatively, ensure the selection logic falls through to useSingleSocket (which correctly uses the named pipe via socketPath) when the socket pool is empty on Windows.