[Bug] Claude in Chrome Native Host crashes on Windows 11 - Bun internal assertion failure

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/11201
2. https://github.com/anthropics/claude-code/issues/16566
3. https://github.com/anthropics/claude-code/issues/10021

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

@codex 幫我翻譯成中文

@claude 幫我翻譯成中文

I was previously able to use Claude Code with Chrome but I am now hitting this and haven't been able to figure out what changed. Co-written with Claude.

Environment:

• Claude Code: 2.1.20 (native Windows installer)
• Windows 11
• Bun: 1.3.5 (bundled)

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

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

Additional context:

• Stopped working ~12 hours ago, seemingly randomly
• I had installed Claude Desktop earlier that day. Initially Claude Code with Chrome still worked, so this is possibly unrelated, but noting this as I've seen a number of reports of people having issues after installing Claude Desktop. Have since fully uninstalled Claude Desktop.
• Verified registry entry for com.anthropic.claude_code_browser_extension is correct
• Verified the native host JSON config and batch file exist at expected paths
• Running claude.exe --chrome-native-host directly reproduces the crash immediately

The crash occurs before any connection attempt. The named pipe creation itself triggers the Bun panic.

---
Update (Jan 27): Found a workaround for the Bun crash, but discovered a second issue.

Workaround for Bun crash:
Modified %USERPROFILE%\.claude\chrome\chrome-native-host.bat to use Node.js:
@echo off
"C:\Program Files\nodejs\node.exe" "%APPDATA%\npm\node_modules\@anthropic-ai\claude-code\cli.js" --chrome-native-host

With this, the native host runs successfully and creates the pipe \\.\pipe\claude-mcp-browser-bridge-bleak.

But there's a second issue: Even with the native host working, the extension (v1.0.40) never initiates the connection. Chrome never spawns the native host because the extension never calls connectNative(). The extension UI works fine in browser, but MCP tools still return "Browser extension is not connected."

This suggests two bugs:

1. ~~Bun crash on Windows~~ (worked around with Node.js)
2. Extension doesn't initiate native messaging connection (still broken)

The second issue may be the same root cause as #20298.

Confirming this issue on Claude Code 2.1.20 (latest) - still not fixed.
Environment:

Claude Code: 2.1.20
OS: Windows 11
Bun: 1.3.5 (embedded)
Browser: Brave (Chromium-based)

Same crash output:
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-cerne
Bun v1.3.5 (1e86cebd) Windows x64 (baseline)
panic(main thread): Internal assertion failure
Additional finding: Tested with standalone Bun 1.3.7 - named pipe creation works. This confirms the fix is in Bun 1.3.6+. Upgrading the embedded Bun version should resolve this.
Workaround: The Chrome extension works via Claude.ai (uses WebSocket instead of named pipe).

Confirming this issue - since TODAY (Claude Code v2.1.23) suddenly the Chrome MCP stopped working due to this bug (says Claude).

Claude Code v2.1.23
OS: Windows 11
Bun: 1.3.5 (embedded)
Browser: Chrome (official)

Chrome extension is not working for me too.
Version v2.1.23
Windows11

Same here.

Confirming this issue on Claude Code 2.1.27 (latest as of Jan 30, 2026)

Environment:

• Claude Code: 2.1.27
• OS: Windows 11
• Bun: 1.3.5 (embedded)
• Chrome Extension: 1.0.41

I believe i am having this issue in 2.1.29

PS C:\Users\lboucher> claude.exe --chrome-native-host
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-lboucher
============================================================
Bun v1.3.5 (1e86cebd) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2
Args: "C:\Users\lboucher\.local\bin\claude.exe" "--chrome-native-host"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) jsc standalone_executable
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:path/posix" "node:path/win32" "node:perf_hooks" "node:process" "node:querystring" "node:stream" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:zlib" "node:worker_threads" "undici" "ws" "node-fetch" "node:http2"
Elapsed: 305ms | User: 453ms | Sys: 453ms
RSS: 0.57GB | Peak: 0.57GB | Commit: 0.57GB | Faults: 138622 | Machine: 68.43GB

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

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

Confirmed on Windows 11 with identical crash signature
Environment

OS: Windows 11
Claude Code: 2.1.29 (Claude Code)
Bun: v1.3.5
Chrome Extension: Claude in Chrome (Beta)

Diagnostic Results
All configuration files are correctly set up:

✅ Registry key exists at HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension
✅ Native host manifest exists with correct extension ID
✅ Batch file exists and points to correct claude.exe path
✅ Native host starts successfully when run without input

However, when stdin receives data (simulating Chrome extension communication):
powershellecho '{"type":"ping"}' | claude.exe --chrome-native-host

[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-petter.isaksson
============================================================
Bun v1.3.5 (1e86cebd) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2
...
panic(main thread): Internal assertion failure
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
https://bun.report/1.3.5/e_11e86cebEugggC++08F+mvBoxhkf0389e__0shkwCA0eNrzzCtJLcpLzFFILC5OLSrJzM9TSEvMzCktSgUAiSkKPg
The crash report URL is identical to the one in this issue, confirming it's the same Bun stdin handling bug on Windows.

same issue.
https://bun.report/1.3.5/e_11e86cebEugggC++08F+mvBoxhkf0389e__0shkwCA0eNrzzCtJLcpLzFFILC5OLSrJzM9TSEvMzCktSgUAiSkKPg

Chrome Extension on Windows: 3 Bugs That Completely Break Browser Automation (Root Causes + Fixes)

Environment: Windows 10/11, Claude Code 2.1.x (npm install), Node.js v22.14.0, Chrome Extension v1.0.40+

I spent considerable time debugging why the Chrome extension ("Claude in Chrome") is completely non-functional on Windows. There are three distinct bugs that must all be fixed for it to work. Many of the open issues on this repo are caused by one or more of these bugs. I am documenting all three together because fixing only one or two still leaves the extension broken.

---

Bug 1: Bun runtime crashes on native host startup

Symptom: Running claude.exe --chrome-native-host crashes immediately with panic(main thread): Internal assertion failure in Bun v1.3.5.

Root cause: The embedded Bun v1.3.5 has a bug in its net module when creating Windows named pipes. The crash occurs at socket listener creation for \\.\pipe\claude-mcp-browser-bridge-<user> before any connection is attempted.

Fix: Modify ~/.claude/chrome/chrome-native-host.bat to use Node.js instead of Bun:

@echo off
"C:\Program Files\nodejs\node.exe" "%APPDATA%\npm\node_modules\@anthropic-ai\claude-code\cli.js" --chrome-native-host

Note: This workaround was already suggested in #16691. The proper fix is upgrading the embedded Bun to v1.3.6+ where named pipe creation works correctly, or falling back to Node.js on Windows automatically.

---

Bug 2: getSocketPaths() does not include Windows named pipe path

Symptom: Even after fixing Bug 1 (native host starts successfully and creates the named pipe), the MCP server cannot find the native host. No connection is ever established.

Root cause: In cli.js, the function ro4() (deobfuscated: getSocketPaths) returns an array of candidate socket paths to search for the native host. On Windows it returns paths like:

C:\Users\<user>\AppData\Local\Temp\claude-mcp-browser-bridge-<user>
/tmp/claude-mcp-browser-bridge-<user>

But the native host creates its listener on a Windows named pipe:

\\.\pipe\claude-mcp-browser-bridge-<user>

The function never adds this named pipe path to the candidate list, so the socket pool never finds the native host.

Fix: Add the Windows named pipe path to ro4() before the return statement:

if (platform() === "win32") {
    const pipePath = `\\\\.\\pipe\\${K}`;  // K = "claude-mcp-browser-bridge-<user>"
    if (!A.includes(pipePath)) A.push(pipePath);
}

---

Bug 3: Socket pool (S2q) is incompatible with Windows named pipes

Symptom: After fixing Bugs 1 and 2, tabs_context_mcp works correctly, but all other tools (navigate, screenshot, read_page, computer, etc.) fail with "Browser extension is not connected."

Root cause: The MCP server uses two client strategies selected by B2q():

1. Socket pool (S2q) -- used when getSocketPaths is provided. Designed for Unix, where each session creates a unique .sock file. The pool's refreshClients() periodically creates and destroys client connections.
2. Single socket client (C2q/TV6) -- used when only socketPath is provided. Maintains a single persistent connection.

On Windows, there is only ever one named pipe. The socket pool's refreshClients() cycle destroys and recreates the connection between tool calls, causing it to drop. The tabs_context_mcp tool has special handling (callTabsContext()) that forces a fresh connection each call, which is why it works. All other tools rely on the pool's cached connections, which are stale.

Fix: On Windows, skip providing getSocketPaths so the client strategy selector (B2q()) returns a single persistent socket client instead of a pool. In the dYz() function (deobfuscated: runClaudeInChromeMcpServer):

// In the MCP server config object:
socketPath: YP6(),
...platform() !== "win32" && { getSocketPaths: ro4 },
clientTypeId: "claude-code",

This conditionally omits getSocketPaths on Windows, causing B2q() to select the single-client strategy that maintains a persistent connection to the named pipe.

---

Architecture Reference

Chrome Extension
    |  (stdin/stdout native messaging protocol)
Native Host (chrome-native-host.bat -> cli.js --chrome-native-host)
    |  (Windows named pipe: \\.\pipe\claude-mcp-browser-bridge-<user>)
    |  (Binary framing: 4-byte UInt32LE length prefix + JSON payload)
MCP Server (claude-in-chrome)
    |  (stdin/stdout MCP JSON-RPC protocol)
Claude Code Session

Important protocol detail: The native host uses 4-byte UInt32LE length-prefixed binary messages over the named pipe. Sending Content-Length HTTP-style headers or plain JSON text causes the first 4 bytes to be misinterpreted as a huge length value (often >1MB), triggering immediate connection termination by the native host. This is the Chrome Native Messaging protocol standard.

---

Summary

| Bug | Symptom | Root Cause | Severity |
|-----|---------|------------|----------|
| 1 | Native host crashes on startup | Bun v1.3.5 named pipe bug | Blocking |
| 2 | MCP server can't find native host | getSocketPaths() missing named pipe path | Blocking |
| 3 | Tools fail after tabs_context_mcp works | Socket pool incompatible with single named pipe | Blocking |

All three bugs are blocking -- they form a chain where each must be fixed before the next one is even encountered. This explains why many Windows users report different symptoms: they hit whichever bug comes first in their configuration.

I created a patch script that applies all three fixes to cli.js and chrome-native-host.bat programmatically. Happy to share if useful.

---

Affected Issues

These bugs are the root cause (or a contributing factor) for at least the following open issues:

• #21300 - Claude in Chrome extension not connecting on Windows despite MCP server showing "connected"
• #21301 - claude-in-chrome MCP connection fails despite correct configuration (Windows)
• #21363 - Chrome extension not connecting to Claude Code via native messaging on Windows 11
• #21371 - Claude in Chrome extension not connecting despite being installed and enabled
• #21415 - Claude in Chrome extension not connecting to Claude Code CLI on Windows 11
• #21838 - Chrome extension connection fails: Native messaging host crashes with Bun assertion failure on Windows
• #21954 - Chrome extension not connecting: 'Browser extension is not connected' error
• #22000 - Claude Code in Windows 11 unable to connect to Chrome browser with Claude extension
• #22025 - [BUG] Claude in Chrome extension not connecting to Claude Code CLI on Windows 11
• #22052 - Chrome extension connects to Claude Desktop but not Claude Code on Windows
• #22500 - [BUG] Claude in Chrome extension not connecting - MCP shows connected but extension unresponsive
• #22885 - [Windows] Chrome extension reconnect fails - page closes immediately
• #23218 - Claude in Chrome Extension Not Connecting on Windows 11

I managed to push claude to fix these issues, on itself. After a lot of convincing and pushing it succeeded. It tried many things but I asked Claude to summarize what it did and generate a prompt that others can use to fix their installation:

Workaround that fixes this on Windows (v2.1.37+):

The root cause is that the native claude.exe embeds Bun, which panics when creating/connecting to Windows named pipes. The fix is to use Node.js instead of Bun for both the Chrome native host AND Claude Code itself.

Give this prompt to Claude Code and it'll fix itself:

The Chrome MCP browser integration is broken on Windows because claude.exe uses Bun which crashes on named pipes. Fix it by:
1. Install the npm version: npm install -g @anthropic-ai/claude-code
2. Edit ~/.claude/chrome/chrome-native-host.bat to use Node.js directly: "C:\Program Files\nodejs\node.exe" "%APPDATA%\npm\node_modules\@anthropic-ai\claude-code\cli.js" --chrome-native-host
3. Rename claude.exe to claude-bun.exe in ~/.local/bin/ so the npm/Node.js version takes priority in PATH

After that, close Chrome fully and reopen it, then start a new claude session. The Chrome MCP tools should connect.

Note: After Claude Code updates, a new claude.exe may reappear in .local/bin/ — just rename it again.

Hope this helps someone.

p.s. I noticed that fast mode is only available in the native binary :-(

Confirming this issue on Windows 11. After analyzing the thread, the root cause is clear: Bun v1.3.5 crashes when creating Windows named pipes. The fix documented by @jason12343 (3 bugs chain) is very detailed and accurate. Upgrading the embedded Bun to v1.3.6+ or falling back to Node.js should be the official fix. Hope this gets prioritized soon.