Claude in Chrome regression (>2.1.212): interactive CLI never starts its in-process Chrome MCP client — /chrome permanently Disabled despite healthy extension + native host

Environment

• Claude Code CLI: tested 2.1.212 (works), 2.1.220 (broken), 2.1.224 (broken), 2.1.228 - latest as of testing (broken)
• Claude browser extension: 1.0.84
• macOS: Tahoe 26.5.2 (Darwin kernel 25.5.0)
• Chrome: current stable
• Install method: Homebrew cask (claude-code)
• Terminal: Ghostty; reproduces both inside a zellij session and in a plain terminal outside zellij (ruled out as a factor)

Symptom

On 2.1.220 and 2.1.224, /chrome shows Extension: Installed, Status: Disabled. Clicking "Reconnect extension" opens a browser tab that closes almost immediately, and focus returns to the CLI menu with no change in status. This reproduces consistently across:

• A single clean CLI session (no concurrent sessions)
• A freshly started claude --chrome session (not --resume)
• Toggling the extension off/on in chrome://extensions
• Full computer restarts
• Both inside and outside a zellij terminal multiplexer session

Downgrading the claude binary to 2.1.212 (both the interactive CLI and the native-messaging host) fixes the issue immediately — Reconnect succeeds and mcp__claude-in-chrome__* tools become available in that session.

Secondary bug found and fixed locally (may be a contributing/related issue)

~/.claude/chrome/chrome-native-host (the shell wrapper registered in the native messaging manifest) hardcodes the full versioned Homebrew Caskroom path, e.g.:

exec "/opt/homebrew/Caskroom/claude-code/2.1.212/claude" --chrome-native-host

When Homebrew upgrades the cask, the old version's directory under Caskroom/claude-code/<old-version>/ is removed, silently breaking this wrapper (exec: no such file or directory) until the next /chrome reconnect regenerates it. Recommend generating this wrapper to point at the stable /opt/homebrew/bin/claude symlink (or equivalent stable path) instead of a version-pinned path, so it survives upgrades.

Diagnostic detail (protocol-level trace on 2.1.220)

Replaced the native-messaging host wrapper with a logging proxy that passes stdin/stdout through to the real claude --chrome-native-host while logging all traffic. Captured trace on a Reconnect click:

chrome->host 19 bytes: b'\x0f\x00\x00\x00{"type":"ping"}'
host-stderr: [Claude Chrome Native Host] Initializing...
host-stderr: [Claude Chrome Native Host] Creating socket listener: /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock
host-stderr: [Claude Chrome Native Host] Socket server listening for connections
host-stderr: [Claude Chrome Native Host] Socket permissions set to 0600
host-stderr: [Claude Chrome Native Host] Handling Chrome message type: ping / Responding to ping
host->chrome 4 bytes: b')\x00\x00\x00'
host->chrome 41 bytes: b'{"type":"pong","timestamp":...}'
chrome->host 25 bytes: b'\x15\x00\x00\x00{"type":"get_status"}'
host-stderr: [Claude Chrome Native Host] Handling Chrome message type: get_status
host->chrome 60 bytes: b'8\x00\x00\x00{"type":"status_response","native_host_version":"1.0.0"}'

So the low-level native-messaging handshake between the extension and the host succeeds correctly (ping/pong, get_status/status_response), and the host opens and holds open a local Unix-socket bridge (/tmp/claude-mcp-browser-bridge-<user>/<pid>.sock) indefinitely afterward.

However, repeated lsof -U polling (including rapid 0.5s-interval polling across a full Reconnect click) never showed any client connection to that bridge socket — only the listener itself. The interactive CLI session (the one showing Status: Disabled) never appears to connect to its own native host's bridge socket. Subsequent Reconnect clicks (while a host process from a prior attempt is still alive) don't even trigger new native-messaging traffic — no new ping observed — yet Status remains Disabled regardless.

This points to a regression in how the interactive CLI session (2.1.213–2.1.224, not yet bisected further) establishes or tracks its connection to the local native-host bridge socket, independent of the (working) extension↔host protocol handshake.

Repro steps

1. Install Claude Code 2.1.220+ via Homebrew cask, with Claude browser extension 1.0.84 installed and enabled in a single Chrome profile.
2. Run claude --chrome in a fresh terminal session.
3. Run /chrome → observe Status: Disabled.
4. Click "Reconnect extension" → tab flashes open/closed, status stays Disabled.
5. Downgrade claude binary to 2.1.212 (e.g. https://downloads.claude.ai/claude-code-releases/2.1.212/darwin-arm64/claude), repeat steps 2-4 → works, Status becomes Enabled.

Impact

Claude in Chrome is completely non-functional on 2.1.220 through at least 2.1.228 (latest release) in this environment, with no available workaround other than staying on 2.1.212 (with auto-updates disabled).