Closing Chrome window with Claude-in-Chrome extension crashes CC CLI session (Unix socket MCP disconnection)

Resolved 💬 5 comments Opened Mar 30, 2026 by prodan-s Closed May 2, 2026

Description

When a Chrome window containing an active Claude-in-Chrome extension tab is closed, all Claude Code CLI sessions that previously used mcp__claude-in-chrome__* tools crash immediately. The session exits to the terminal prompt with reason=other — no error output, no graceful degradation.

This is the same class of bug as #18557 (SSE MCP server disconnection crashes session) but for the Unix socket transport used by the Chrome native messaging host bridge.

Architecture (for context)

Chrome Extension
  → Native Messaging (stdio)
    → chrome-native-host binary (creates Unix socket)
      → /tmp/claude-mcp-browser-bridge-<user>/PID.sock
        → CC CLI session connects to this socket for mcp__claude-in-chrome__* tools

When Chrome closes the window:

  1. Chrome sends EOF to native messaging host
  2. Native host shuts down and deletes the Unix socket
  3. CC CLI session gets broken pipe / connection reset on the socket
  4. CC crashes instead of marking the MCP server as failed

Steps to Reproduce

  1. Start a Claude Code CLI session in a terminal
  2. Use any mcp__claude-in-chrome__* tool (e.g., tabs_context_mcp) — this establishes the socket connection
  3. Close the Chrome window that has the orange Claude-in-Chrome border
  4. Observe: CC session exits to terminal prompt immediately

The CC session does not need to be actively using Chrome tools at the time of closure. A session that used Chrome tools hours earlier still crashes when the window closes.

Evidence (timestamped logs from real incident)

~/Library/Logs/Claude/chrome-native-host.log:

[2026-03-29 18:35:31 INFO chrome-native-host] Chrome disconnected (EOF received)
[2026-03-29 18:35:31 INFO chrome-native-host] Shutting down chrome native host
[2026-03-29 18:35:31 INFO chrome-native-host] Cleaned up socket: /tmp/claude-mcp-browser-bridge-prodanstatev/61953.sock
[2026-03-29 18:35:31 INFO chrome-native-host] Chrome native host stopped

SessionEnd hook log (same incident):

2026-03-29 18:35:29 | SESSION_END | session=7c6cb60d | reason=other
2026-03-29 18:35:29 | SESSION_END | session=d9176ef9 | reason=other

Note: CC sessions die at 18:35:29 — 2 seconds before the native host logs the EOF at 18:35:31. The socket breaks before the host finishes its shutdown sequence, and CC reacts to the broken pipe immediately with an unhandled crash.

Expected Behavior

Per #1026 and #15232: when an MCP server disconnects, the session should continue running with the disconnected server marked as failed. Tools from that server become unavailable, but the session stays alive. /mcp reconnect can restore.

Actual Behavior

Session exits completely to terminal prompt with no error output. All work in the session is lost (unless auto-wrapup hooks capture it).

Frequency

This has occurred ~5 times over the past week. Any user who has the Claude-in-Chrome extension installed and occasionally closes Chrome windows will hit this.

Environment

  • Claude Code: 2.1.87
  • macOS: 26.3.1 (25D2128, Apple Silicon)
  • Chrome: 146.0.7680.165
  • Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
  • Native host: /Applications/Claude.app/Contents/Helpers/chrome-native-host

Related Issues

  • #18557 — SSE MCP server disconnection crashes session (same class, different transport — CLOSED)
  • #25533 — Orphaned chrome-native-host processes (related: hosts don't always exit on stdin EOF)
  • #32132 — Intermittent native host EOF disconnects
  • #1026 — Reconnect MCP servers (expected graceful behavior)
  • #15232 — Auto-reconnect for MCP servers

Suggested Fix

The CC CLI's MCP client for the Chrome extension socket should wrap the socket connection in error handling that catches broken pipe / connection reset and marks the server as failed, rather than crashing the process. This is the same fix pattern as #18557 but applied to the Unix socket transport code path.

View original on GitHub ↗

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