Windows: Chrome extension native host crashes on startup (TypeError ERR_INVALID_ARG_TYPE, Bun net.listen on named pipe)

Description

The Chrome extension bridge (mcp__claude-in-chrome__* tools) never connects on Windows. Every call to a browser tool (e.g. tabs_context_mcp) returns:

Browser extension is not connected. Please ensure the Claude browser extension is installed and running...

This happens even with the extension installed, enabled, and logged into the correct claude.ai account. Root cause: the native messaging host process that Chrome launches to bridge to the CLI crashes immediately on startup, before ever reaching the extension.

Steps to reproduce

1. On Windows, install Claude Code CLI (npm i -g @anthropic-ai/claude-code), version 2.1.207 (also confirmed on npm as the current latest).
2. Install the "Claude in Chrome" extension and log in with the same account as the CLI.
3. In Claude Code, call any mcp__claude-in-chrome__* tool, e.g. tabs_context_mcp.
4. Observe "Browser extension is not connected" — reproduces consistently.
5. To isolate: manually invoke the registered native-messaging-host launcher directly:

``
C:\Users\<user>\.claude\chrome\chrome-native-host.bat
`
(which runs claude.exe --chrome-native-host`). The process exits immediately (exit code 1) with the following on stderr:

```
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Socket server error: ...
TypeError: Failed to listen at \\.\pipe\claude-mcp-browser-bridge-<username>
code: "ERR_INVALID_ARG_TYPE"
at listen (unknown:1:1)
at node:net:1827:30
at listenInCluster (node:net:1913:24)
at listen (node:net:1818:20)
at B:/~BUN/root/src/entrypoints/cli.js:12317:1166
at Promise (unknown:1:11)
at start (B:/~BUN/root/src/entrypoints/cli.js:12317:1139)
at B:/~BUN/root/src/entrypoints/cli.js:12317:357
at Ac (B:/~BUN/root/src/entrypoints/cli.js:138:7006)
at eq_ (B:/~BUN/root/src/entrypoints/cli.js:12317:262)

Bun v1.4.0 (Windows x64 baseline)
```

The CLI is now running on the Bun runtime (not Node), and its own socket-listener code fails to create the Windows named pipe (\\.\pipe\claude-mcp-browser-bridge-<username>) that the extension is supposed to talk to. This looks like a Windows-specific regression, likely from a recent migration to Bun — net.Server.listen() appears to be receiving an argument type Bun's node:net shim doesn't accept on win32, even though the same code path presumably works fine on macOS/Linux (non-Windows branch in the source has separate Unix-socket handling).

Environment

• OS: Windows 11 Pro (build 10.0.26200)
• Claude Code version: 2.1.207 (confirmed current latest via npm view @anthropic-ai/claude-code version)
• Runtime: Bun v1.4.0 (Windows x64 baseline), per the crash's own stderr banner
• Chrome extension: "Claude in Chrome" (Claude in Chrome), version 1.0.80, enabled, "On all sites", logged into the matching claude.ai account
• Native messaging host manifest verified correct and present:
• HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension → C:\Users\<user>\AppData\Roaming\Claude Code\ChromeNativeHost\com.anthropic.claude_code_browser_extension.json
• Manifest allowed_origins correctly lists the installed extension's chrome-extension:// ID
• path correctly points to an existing chrome-native-host.bat wrapper that invokes claude.exe --chrome-native-host

What we ruled out before finding this

Since the symptom ("Browser extension is not connected") is generic, we worked through every plausible cause before finding the real one:

• A stray User-scope ANTHROPIC_API_KEY environment variable that was overriding claude.ai OAuth for unrelated MCP connectors (separate, already-fixed issue — confirmed via claude mcp list, not the cause of this bug)
• Stale/orphaned Chrome processes (killed all chrome.exe, relaunched fresh — no change)
• Extension disabled, or logged into the wrong account (confirmed enabled + correct account — no change)
• A second Claude Code session (Enterprise) holding the bridge connection (confirmed not running via process list — no change)
• Restarting the Claude Code CLI session itself (no change)
• Toggling the extension off/on in chrome://extensions (no change)
• Checked the extension's own service-worker DevTools console during a connection attempt: nothing logged at all, confirming the request never reaches the extension — consistent with the native host process crashing before the handshake starts

Expected behavior

The native messaging host process should start successfully and establish the named pipe so mcp__claude-in-chrome__* tools can connect, matching behavior on non-Windows platforms.