Chrome MCP: no recovery when native messaging port dies mid-session

Problem

The Chrome browser automation (Claude-in-Chrome MCP) has no reconnect mechanism when the native messaging port between the extension and Claude Code dies mid-session. Once broken, the only recovery is starting an entirely new Claude Code session.

Observed Behavior

1. tabs_context_mcp and tabs_create_mcp continue to work (they use Chrome's chrome.tabs extension API directly)
2. All per-tab commands (read_page, computer, navigate, screenshot) fail with "No tab available"
3. Creating new tabs doesn't help — even freshly-created tabs get "No tab available"
4. Toggling the extension off/on in chrome://extensions doesn't help
5. Clicking the extension icon doesn't help

Root Cause

Chrome native messaging spawns a new host process each time the extension establishes a connection. When the connection dies:

• The current Claude Code session's MCP client is still bound to the old (dead) native host process
• Toggling the extension makes Chrome spawn a fresh native host, but the current session's MCP client doesn't know about it
• Result: two disconnected sides — extension talks to a new host, Claude Code talks to a dead one

Chrome Extension Console Errors

Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
Unchecked runtime.lastError: Debugger is not attached to the tab with id: XXXXXX
Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received
Executing inline script violates the following Content Security Policy directive 'script-src self'...

The CSP errors originate from sidepanel.html — the extension's own inline <script> for dark mode detection is blocked by Manifest V3 CSP.

What Triggers the Break

• Long idle time between browser commands (service worker sleeps, port dies)
• Vite HMR / dev server hot reloads
• Manual interaction with the controlled tab
• Unknown — sometimes it just breaks

Requested Fix

1. MCP client reconnect mechanism — detect when the native messaging port is dead and re-establish the connection without requiring a new session
2. Better error message — "No tab available" is misleading. The tab IS available (proven by tabs_context_mcp). The error should say something like "Native messaging disconnected — reconnecting..." or at minimum "Browser connection lost"
3. Heartbeat/keepalive — periodic ping to detect and recover from broken ports before the user hits a failure

Environment

• Claude Code: 2.1.76
• macOS Darwin 25.4.0
• Chrome with Claude browser extension
• Two native messaging hosts registered: com.anthropic.claude_browser_extension (Claude Desktop) and com.anthropic.claude_code_browser_extension (Claude Code CLI)

Workaround

Start a new Claude Code session. This is the only thing that works — it initializes a fresh MCP client that properly handshakes with Chrome's native messaging.