chrome-native-host crashes on every invocation (Windows, ERR_INVALID_ARG_TYPE on named pipe listen)

Status Closed — duplicate
Reported on v2.1.220
Maintainer reply None cached
Activity 2 comments · opened Aug 3, 2026 · closed Aug 15, 2026

Environment

  • Claude Code 2.1.220
  • Windows 11, x64
  • Bundled runtime: Bun v1.4.0 (Windows x64 baseline)
  • Native host script: %USERPROFILE%\.claude\chrome\chrome-native-host.batclaude.exe --chrome-native-host
  • Chrome extension: "Claude for Chrome", version 1.0.84, ID fcoeoabgfenejglbffodgkkbkcdhcgfn, enabled, correct native-messaging manifest registered at HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension (verified allowed_origins matches the installed extension ID, manifest file present and valid JSON).

Problem

mcp__claude-in-chrome__tabs_context_mcp (and every other claude-in-chrome MCP tool) fails with "Browser extension is not connected" — every time, regardless of Chrome restarts, extension sign-in state, or /mcp reconnect (which does successfully reconnect the CLI-to-local-MCP-server hop, but not the underlying browser bridge).

Running the native host command directly and manually reproduces a deterministic crash, before it ever gets a chance to accept a connection from Chrome:

"C:\Users\<user>\.local\bin\claude.exe" --chrome-native-host

[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \.\pipe\claude-mcp-browser-bridge-<user>
[Claude Chrome Native Host] Socket server error: ...

TypeError: Failed to listen at \.\pipe\claude-mcp-browser-bridge-<user>
 code: "ERR_INVALID_ARG_TYPE"

      at listen (unknown:1:1)
      at node:net:1847:30
      at listenInCluster (node:net:1933:24)
      at listen (node:net:1838:20)
      at B:/~BUN/root/src/entrypoints/cli.js:20414:1166
      at Promise (unknown:1:11)
      at start (B:/~BUN/root/src/entrypoints/cli.js:20414:1139)
      at B:/~BUN/root/src/entrypoints/cli.js:20414:357
      at zc (B:/~BUN/root/src/entrypoints/cli.js:141:8924)
      at $3_ (B:/~BUN/root/src/entrypoints/cli.js:20414:262)

Bun v1.4.0 (Windows x64 baseline)

100% reproducible across multiple fresh invocations, immediately after process start — this is not a stale-pipe collision (confirmed by re-running after full Chrome + process restart, identical crash every time).

Notably, the un-guarded Unix-socket stale-cleanup logic visible in the trace (if(p4o.platform()!=="win32"){ ...remove stale sockets for dead PIDs... }) is explicitly skipped on win32, so there is no equivalent cleanup path for a Windows named pipe left in a bad state by a previous crashed instance — worth checking whether a prior crash's pipe object can itself cause subsequent .listen() calls to fail in a way that surfaces as this same ERR_INVALID_ARG_TYPE rather than a more diagnosable EADDRINUSE.

Impact

Full loss of Chrome browser automation (navigate, computer, tabs_context_mcp, etc.) for any Claude Code session on an affected Windows machine — extension-side setup is correct, but the bridge process cannot come up at all.

What was already ruled out

  • Extension not installed / not enabled — confirmed installed, "On", correct permissions including "Communicate with cooperating native applications".
  • Wrong Chrome profile — native-messaging manifest is machine/user-scoped (HKCU), not profile-scoped.
  • Stale sign-in — re-signed into claude.ai in the extension's own flow, no change.
  • /mcp not reconnecting — it does reconnect the CLI's MCP client to the local MCP server; the failure is downstream of that, in the server's own bridge to Chrome.
  • Native-messaging manifest pointing at a stale/missing binary — verified claude.exe exists at the path the manifest specifies and is the current 2.1.220 build.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗