Chrome Extension: EADDRINUSE - Native Host and MCP Server both try to create pipe listener

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21512
2. https://github.com/anthropics/claude-code/issues/21753
3. https://github.com/anthropics/claude-code/issues/21363

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

Update: This may be related to Chrome 144 update.

User reports it was working before today's Chrome update. Current Chrome version: 144.0.7559.98

Issue #21330 also reports Chrome 144.0.7559.97 - same version branch.

Additional context:

The extension was working before the Chrome 144 update today (2026-01-29). This strongly suggests Chrome 144 broke something in the Native Messaging flow.

Potential workaround: Downgrade Chrome to version 143.x (not yet tested)

Chrome 144 changes to investigate:

• Possible changes to Native Messaging API
• Possible changes to Named Pipe handling on Windows
• Possible stricter security policies for extensions

This appears to be related to:

• #21512 (EADDRINUSE / pipe conflict)
• #21337 (Windows bridge / native messaging)
• #21363 (Chrome extension Windows 11 collection)

Moving details to #21512.

If it is a Chrome issue, then why did it not break Cursor? Is their implementation more robust?

You're right - Chrome 144 is not the cause. I tested downgrading to Chrome 143 and it didn't help.

The root cause is an architecture bug in Claude Code itself: the native host (--chrome-native-host) tries to create a pipe listener instead of connecting as a client to the existing MCP server.

Workaround: Downgrade to Claude Code 2.1.19 via npm install -g @anthropic-ai/claude-code@2.1.19

Root Cause Found & Fix Identified

After extensive analysis of the minified cli.js between versions 2.1.19 (working) and 2.1.29 (broken), I found the root cause:

The Bug

In v2.1.20, a multi-socket architecture was introduced. Two functions handle socket paths:

1. Rj6() (Native Host) - Returns correct Windows named pipe:

function Rj6() {
  if (platform() === "win32")
    return `\\\\.\\pipe\\claude-mcp-browser-bridge-${username}`;
  return join(tmpDir(), `${process.pid}.sock`);
}

1. xQ4() (MCP Server socket pool) - MISSING Windows support:

function xQ4() {
  let paths = [];
  // Only scans Unix socket files and temp directories
  // Returns: ["C:\\Users\\...\\Temp\\claude-mcp-browser-bridge-user", "/tmp/..."]
  // MISSING: Windows named pipe path!
  return paths;
}

Result on Windows

• Native Host listens on: \\.\pipe\claude-mcp-browser-bridge-user ✓
• MCP Server tries to connect to: C:\Users\...\Temp\... ✗ ENOENT

The Fix

Add Windows check to xQ4():

function xQ4() {
  if (platform() === "win32") {
    return [`\\\\.\\pipe\\claude-mcp-browser-bridge-${username}`];
  }
  // existing Unix logic...
}

Verified Fix

I patched the minified cli.js and confirmed the connection works:

BROKEN paths: C:\Users\...\Temp\... - ENOENT
FIXED path: \\.\pipe\claude-mcp-browser-bridge-user - Connected ✓

Affected Versions

• Last working: 2.1.19
• First broken: 2.1.20 (multi-socket architecture introduced)

The source file to fix is likely packages/cli/src/chrome-extension/socket-bridge.ts or similar - look for getSocketPaths() or getAvailableSocketPaths().

Great work @kimchi-developer, thank you.

thank you. i have put claude code to repair himself. this is plan he made which worked. thank you @kimchi-developer

"# Fix Chrome MCP Server on Windows 11

Problem

Chrome MCP server doesn't work on Windows 11 - function xp4() in cli.js returns Unix socket paths but misses Windows named pipe.

File to Patch

C:\Users\myusername\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code\cli.js

Fix

Add Windows check at start of function xp4():

Find: function xp4(){let A=[],q=bF1()

Replace: function xp4(){if(IEY()==="win32")return[\\\\\.\\pipe\\${FEY()}\];let A=[],q=bF1()

Steps

1. Backup cli.js
2. Apply patch
3. Test Chrome extension connection

"

It's working with 2.1.34, now we need this fix to be official, I don't want to patch at each update

can we update to latest and it would still work? I have intentionally stayed at 2.1.19 for now

oh I still see latest update as 2.1.32, it is fixed in 2.1.34?

it is not for me. 2.1.34 still busted

Thx @kimchi-developer

Because I had the native install I had uninstall the native, reinstall via NPM, then do the patch from Kimchi and it worked.

thank you. i have put claude code to repair himself. this is plan he made which worked. thank you @kimchi-developer "# Fix Chrome MCP Server on Windows 11 ## Problem Chrome MCP server doesn't work on Windows 11 - function xp4() in cli.js returns Unix socket paths but misses Windows named pipe. ## File to Patch C:\Users\myusername\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code\cli.js ## Fix Add Windows check at start of function xp4(): Find: function xp4(){let A=[],q=bF1() Replace: function xp4(){if(IEY()==="win32")return[\\\.\pipe\${FEY()}];let A=[],q=bF1() ## Steps 1. Backup cli.js 2. Apply patch 3. Test Chrome extension connection "

Amazed that nobody from anthropic has picked this up yet. Big impact bug, trivial fix.

2.1.37, windows 11.
Claude for Chrome still not working with Claude Code CLI.

@vinch00 Same setup here (2.1.37, Win11) - got it working with the manual patch from #21512. The root cause and patch instructions are documented there. The fix needs to be reapplied after each update.

Yeah, too bad the fix doesn't apply to the Claude executable on Windows which is required for Claude Cowork. This makes Cowork basically useless on Windows....

For what it's worth, onUI is a browser annotation extension with an MCP server that uses a different architecture — it runs via npx as a stdio-based MCP server rather than a named pipe, which sidesteps the native host port conflict entirely. Might be a useful reference for how other extensions handle the MCP connection.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.