[BUG] aude in Chrome browser extension not connecting from Claude Code on Windows despite correct configuration

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23466
2. https://github.com/anthropics/claude-code/issues/23526
3. https://github.com/anthropics/claude-code/issues/21404

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

Same issue here!

Confirmed Bun panic crash on Windows 11 - Claude Code v2.1.37

Environment

• OS: Windows 11
• Claude Code: v2.1.37 (native install via ~/.local/bin/claude.exe)
• Bun: Canary v1.3.9-canary.51 (d5628db2) - bundled with Claude Code
• Chrome Extension: Claude in Chrome (Beta) v1.0.47
• Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn

Symptoms

• /mcp shows Claude-in-chrome MCP Server as connected with 17 tools
• Chrome extension is installed, enabled, and has correct permissions (including "Communicate with native applications")
• Registry entry HKCU\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension is correctly set
• Native messaging manifest points to valid chrome-native-host.bat
• But all Chrome MCP tools fail with: "Browser extension is not connected"

Root cause: Bun panic when Chrome launches native host

When Chrome triggers chrome.runtime.connectNative("com.anthropic.claude_code_browser_extension"), Chrome reports runtime.lastError: Native host has exited.

Captured stderr from the native host (by redirecting stderr to a log file in the bat wrapper):

[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-jcardenas
============================================================
Bun Canary v1.3.9-canary.51 (d5628db2) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2
Args: "C:\Users\jcardenas\.local\bin\claude.exe" "--chrome-native-host"
Features: Bun.stdin(2) jsc standalone_executable
Builtins: "bun:main" "node:buffer" "node:child_process" "node:crypto" "node:fs" "node:fs/promises" "node:net" "node:os" "node:path" "node:process" "node:stream" "node:timers/promises" "node:url" "node:util"
Elapsed: 218ms | User: 171ms | Sys: 78ms
RSS: 0.26GB | Peak: 0.26GB | Commit: 0.42GB | Faults: 63169 | Machine: 17.05GB

panic(main thread): Internal assertion failure
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Bun crash report: https://bun.report/1.3.9/e_2d5628dbEkgggC+s1oU+vvkOu8t/uBysi5uB__qt24tCA0eNrzzCtJLcpLzFFILC5OLSrJzM9TSEvMzCktSgUAiSkKPg

Debugging steps taken

1. Verified registry, manifest, and bat file are all correctly configured
2. Removed conflicting Claude Desktop native messaging host registry entry (com.anthropic.claude_browser_extension) which pointed to a non-existent binary
3. Killed stale --claude-in-chrome-mcp zombie processes and restarted session
4. Confirmed crash is reproducible every time Chrome triggers connectNative()
5. The crash happens at the socket listener creation phase - Bun panics with "Internal assertion failure" on the main thread

Additional note

Also had Claude Desktop (com.anthropic.claude_browser_extension) registered with a broken path pointing to C:\Users\...\AnthropicClaude\app-1.1.1520\resources\chrome-native-host.exe which doesn't exist (directory only contains squirrel.exe). The same extension ID appeared in both manifests' allowed_origins, though this was not the root cause.

Update: Resolved with manual patch

Correction

In my previous comment, all paths containing a specific username should be read as generic Windows paths (e.g., C:\Users\%USERNAME%\.local\bin\claude.exe, \\.\pipe\claude-mcp-browser-bridge-%USERNAME%).

Resolution

After deeper investigation, the root cause is actually two compounding bugs as described in #23526 by @insert0name:

1. Bun panic crash — The bundled Bun runtime (v1.3.9-canary.51) crashes with Internal assertion failure when creating Windows named pipes via --chrome-native-host.
2. getSocketPaths() missing Windows pipe — Even if the native host ran without crashing, the MCP server (--claude-in-chrome-mcp) never discovers the Windows named pipe (\\.\pipe\claude-mcp-browser-bridge-%USERNAME%) because getSocketPaths() only returns Unix-style paths.

Workaround applied (confirmed working)

Following the approach from #23526 and the patch by @chriscrosstalk:

1. Installed Claude Code via npm alongside the standalone binary:

``
npm install -g @anthropic-ai/claude-code
``

1. Patched cli.js to add the Windows named pipe to getSocketPaths() (function minified as cc4 in v2.1.37):

``js
// Added before return A in getSocketPaths():
if(process.platform==="win32"){let P=\\\\.\\pipe\\${K};if(!A.includes(P))A.push(P)}
``

1. Modified chrome-native-host.bat to use Node.js instead of the crashing Bun binary:

``bat
@echo off
"C:\path\to\node.exe" "C:\path\to\node_modules\@anthropic-ai\claude-code\cli.js" --chrome-native-host
``

After these changes, Chrome MCP integration works correctly on Windows 11 with Claude Code v2.1.37.

Credits

• @insert0name — Root cause analysis and getSocketPaths() fix in #23526
• @chriscrosstalk — Manual patch script confirming the fix
• @bosmadev — Analysis of standalone vs npm install limitations

---
This issue was diagnosed, debugged, and reported by Claude (Opus 4.6) via Claude Code CLI.

Aqui ainda persiste o problema!

Aqui ainda persiste o problema!

https://github.com/anthropics/claude-code/issues/23828
https://github.com/anthropics/claude-code/issues/23082

Comment for Related Issues (#23539, #23082, #21279, #20862)

---

Additional Root Cause: Windows Username Spaces

I've discovered a third independent bug affecting Windows users with spaces in their usernames (e.g., "John Smith", "Dennis Bosma").

The Problem

Pipe name mismatch:

Native host creates:  \\.\pipe\claude-mcp-browser-bridge-Dennis Bosma
MCP client expects:   \\.\pipe\claude-mcp-browser-bridge-DennisBosma
                                                          ^^^^ sanitized

This causes MCP tools to fail with "Browser extension is not connected" even when:

• ✅ Extension shows "Enabled, Installed"
• ✅ Chrome native messaging works (ping/status)
• ❌ MCP tool calls timeout (pipe name mismatch)

Why This Matters

This bug persists EVEN AFTER applying existing workarounds:

• ✅ Node.js instead of Bun → fixes stdin crash
• ✅ Patched getSocketPaths() → fixes pipe discovery
• ❌ Username space bug still blocks connection

This explains why some users report success with the Node.js + getSocketPaths() patch, but others still fail — it depends on whether they have spaces in their Windows username.

The Fix (One Line)

Add username sanitization in both native host and MCP client:

const username = os.userInfo().username.replace(/\s+/g, '');
const pipeName = `\\\\.\\pipe\\claude-mcp-browser-bridge-${username}`;

Test Evidence

Direct pipe connection test confirms the pipe with space exists:

const net = require('net');
const pipe = '\\\\.\\pipe\\claude-mcp-browser-bridge-Dennis Bosma';
net.createConnection(pipe).on('connect', () => console.log('✓ Pipe exists!'));
// Result: ✓ Pipe exists!

But MCP tools search for the sanitized version (without space) and fail.

Affected Users

• ~30-50% of Windows users (default Windows setup creates usernames with spaces)
• Corporate accounts: "FirstName LastName" format
• Personal PCs: Full names entered during setup
• Domain-joined: AD format "First Last"

Full Diagnosis

See Issue #23828 for comprehensive diagnosis, test evidence, and proposed fixes.

---

TL;DR: If you have spaces in your Windows username, the existing Bun + getSocketPaths() fixes won't help. You need username sanitization in the pipe name generation.

Update: Confirmed fix for v2.1.37

See #23828 (comment) for the complete ESM-safe, version-resilient fix. Key addition since last update:

• ESM bug: require("os") throws in v2.1.37 because cli.js is "type": "module". Use process.env.USERNAME instead.
• Content-based discovery: Find getSocketPaths by anchor string (claude-mcp-browser-bridge), not minified function name. Survives across versions.
• Confirmed working end-to-end on Windows with all Chrome MCP tools.

Update: Published the complete fix (all 3 bugs + username space handling) as an open-source SessionStart hook:

Repo: bosmadev/claude — see scripts/fix-chrome-native-host.py and README > Chrome MCP Fix

Auto-repairs on every launch: BAT rewrite (Bun→Node), pipe patch (getSocketPaths), bridge flag disable, USERNAME space sanitization. Content-based pattern matching survives minification changes. Still needed as of v2.1.39.

Confirmed fix — Windows 11, Claude Code v2.1.44, Chrome Extension v1.0.52

Root Cause

The feature flag tengu_copper_bridge in ~/.claude.json (under cachedGrowthBookFeatures) was set to true. When enabled, Claude Code routes MCP traffic through a websocket bridge (wss://bridge.claudeusercontent.com) instead of the local Windows named pipe (\\.\pipe\claude-mcp-browser-bridge-USERNAME). The websocket bridge fails silently on Windows — the native host starts and handles Chrome's ping/status, but Claude Code's MCP client never connects to the pipe.

Symptom: /chrome shows Status: Enabled, Extension: Installed, but all MCP tool calls return "Browser extension is not connected."

Fix

1. Edit C:\Users\<USERNAME>\.claude.json
2. Find "cachedGrowthBookFeatures" section
3. Change "tengu_copper_bridge": true to "tengu_copper_bridge": false
4. Restart Claude Code completely (exit and start new session)
5. Run /chrome to connect

Additional Setup (may be required)

If the flag fix alone doesn't resolve it, ensure native messaging is properly configured:

• Manifest file: ~/.claude/chrome/com.anthropic.claude_browser_extension.json — must contain correct path to the .bat file and the extension's allowed_origins
• Windows Registry: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension — must point to the manifest JSON
• BAT file: Must invoke node.exe, not Bun — Bun crashes on Windows stdin pipes (see #23828)
• Restart Chrome after any registry changes

Debugging

Check ~/.claude/chrome/debug.log. A working connection shows:

[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-USERNAME
[Claude Chrome Native Host] Socket server listening for connections
[Claude Chrome Native Host] MCP client X connected. Total clients: 1

If you see "connected" followed immediately by "disconnected" with no tool requests, the tengu_copper_bridge flag is still true.

Note

The Chrome window that briefly opens and closes when running /chrome is normal behaviour — the connection happens via the background native messaging host, not the popup window. Don't let that mislead your debugging.

Additional finding: tengu_copper_bridge flag makes native host setup irrelevant

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.