Claude in Chrome: Status stays "Disabled" with zero connection-attempt logs, despite fully clean setup (was working as recently as June 30)

Environment:

• Claude Code: 2.1.216 (native install)
• Claude in Chrome extension: 1.0.81
• macOS: 15.2 (24C101)
• Chrome: 150.0.7871.129
• Install method: native (~/.local/bin/claude)

Summary:

/chrome persistently reports Status: Disabled / Extension: Installed, and no mcp__claude-in-chrome__* tools are ever registered in-session — even after eliminating every known cause of this class of bug. Diagnostic logs show the CLI's in-process Chrome MCP client is not even attempting to start, despite a clean environment.

What I ruled out (in order):

1. Competing native-messaging hosts — found and disabled Claude Desktop's com.anthropic.claude_browser_extension.json manifest (same extension ID as Claude Code's own com.anthropic.claude_code_browser_extension.json). No change.
2. Zombie/duplicate processes — killed all stray claude and chrome-native-host processes; confirmed via ps aux only one clean instance running. No change.
3. Stale extension state — fully removed and reinstalled the Chrome extension. No change.
4. Stale device pairing — found and cleared chromeExtension.pairedDeviceId in ~/.claude.json (was pointing to an old paired-device record from Feb 26). No change; the field never repopulates even after multiple reconnect attempts.
5. Claude Desktop app entirely uninstalled (was not even running/opened, but its native host manifest was present and being spawned by Chrome on demand). No change.
6. Full PC restart, full Chrome restart. No change.
7. Tested both a --resume'd session and a brand-new, non-resumed claude --chrome session in a fresh terminal. Same failure in both.

Hard evidence — this is a client-side regression, not local misconfiguration:

Per-project MCP logs live at ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-claude-in-chrome/*.jsonl. The most recent log file anywhere on this machine, across every project, is from 2026-06-30, and it shows a normal successful handshake:

{"debug":"In-process Chrome MCP server started",...}
{"debug":"Starting connection with timeout of 30000ms",...}
{"debug":"Successfully connected (transport: stdio) in 3ms",...}
{"debug":"Connection established with capabilities: {\"hasTools\":true,...\"serverVersion\":{\"name\":\"Claude in Chrome\",\"version\":\"1.0.0\"}}",...}

(followed by expected "No tab available" errors, since no tab was open — that's a separate, benign condition.)

Since then, zero new log files have been created in that directory tree, despite dozens of /chrome reconnect attempts, fresh sessions, and the full reset steps above. This indicates the CLI is not even invoking its in-process Chrome MCP client anymore — the failure is upstream of the extension handshake entirely.

Steps to reproduce:
Unclear — this appears to be a regression that occurred sometime between 2026-06-30 and today (2026-07-21) without any corresponding local config change I can identify. Given the clean-environment testing above, it does not appear to be reproducible via any local setup change; it looks like a CLI-side change (auto-update?) silently broke the Chrome MCP client startup path.

Expected: /chrome shows Status: Connected and mcp__claude-in-chrome__* tools register, matching the June 30 behavior.

Actual: Status: Disabled permanently, no connection attempt ever logged.