Claude in Chrome: native host spawns but Claude Code CLI never attaches to bridge socket — "Browser extension is not connected" (macOS 26.2 + Chrome 148)

**Update: resolved — and it turned out not to be a version regression.**

It's now working, including on 2.1.160 (the exact version that was failing in the report above) — so the binary/version was not the cause.

What fixed it: re-authenticating the Claude Code session (sign out, sign back in). After that the extension connected immediately, and the native-host bridge handshake that previously never completed now succeeds.

In hindsight the canonical error was hinting at this the whole time — "…ensure you are logged into claude.ai with the same account as Claude Code." The account was already correct; the problem appears to have been a stale/invalid CLI auth token, not a wrong account. Refreshing the credentials let the handshake complete.

Honest caveat on attribution: around the same time I also did a forced clean reinstall (claude install --force) and a full restart of both the CLI and Chrome, so I can't isolate re-auth as the sole cause with 100% certainty. But it's the most likely decisive step, since the same version + config + binary failed before it and worked after.

Two notes for maintainers:

1. When the CLI's auth is stale/expired, a clearer message (e.g. "re-authenticate Claude Code") instead of the generic "Browser extension is not connected" would save people a long native-messaging rabbit hole.
2. The /chrome → select-browser JSON Parse error: Unexpected identifier "Browser" noted above still stands as a separate minor bug (the CLI JSON.parse()-ing the plain-text error string).

Posting in case it helps anyone else who lands here. 🙏

Thank you! That was the only thing I didn't try, and it worked

Confirming this fix worked for me too (macOS, Claude Code CLI + Claude in Chrome extension).

Same symptom: extension installed, correct account logged in, native-messaging host spawned and listening on the bridge socket, but the CLI session's tabs_context_mcp always returned "Browser extension is not connected." I had already tried disabling the Desktop app's native-host manifest, full Chrome restarts, re-verifying the account, fresh CLI sessions, and even uninstalling/reinstalling the extension — none of it helped (this was tracked in a duplicate report, #75434, closed in favor of #73903).

What actually fixed it: claude auth logout followed by claude auth login (re-authenticating the CLI itself, not the extension or the Google account). Ran it in a separate terminal to avoid killing the active session, then immediately re-tested tabs_context_mcp in the still-running Claude Code session — it connected on the first try.

So +1 to the stale/invalid CLI auth token diagnosis. Agree with the suggestion above that a clearer error message here (pointing at CLI re-auth) would save a lot of people a native-messaging rabbit hole, since the generic "Browser extension is not connected" strongly implies the problem is on the extension side.

+1, same failure mode — additional data point on the native host lifecycle and cloud bridge

Environment:

• macOS
• Claude Code: 2.1.212
• Claude in Chrome extension: 1.0.81 (ID fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Plan: Pro (direct account)

Confirms the same core finding: native host manifest, binary, and extension ID all check out, and the host process comes up and listens correctly, but the CLI never seems to hold a stable connection to it.

Two additional things I traced that might narrow this down further:

1. Native host log shows repeated short-lived sessions, not a single stable one:

[INFO chrome-native-host] Socket server listening for connections
...
[INFO chrome-native-host] Chrome disconnected (EOF received)
[INFO chrome-native-host] Shutting down chrome native host

This repeats over and over, with gaps ranging from ~1 second to ~30 minutes between host restarts. This looks consistent with Chrome's Manifest V3 service worker idle-suspend behavior tearing down the native messaging port whenever the extension's service worker goes inactive — i.e. the host isn't crashing, it's being told to shut down because Chrome killed the connection on its end.

2. The extension's cloud relay is healthy and unrelated to the failure. Inspecting the extension's own service worker DevTools (chrome://extensions → "service worker"), the WebSocket to wss://bridge.claudeusercontent.com/chrome/<user-id> establishes with 101 Switching Protocols, stays open, and receives regular {"type":"pong"} heartbeats. So the extension↔cloud pairing is fine — the break is entirely local, between the extension's service worker and the native host process.

Given both this thread's finding (CLI never attaches to the socket) and mine (the local native port keeps getting torn down by what looks like MV3 suspend behavior), my guess is these are two symptoms of the same underlying issue: if the port only exists in short-lived windows, a CLI session started or polling outside that window would never find it live to attach to — matching "socket exists, but no CLI client ever holds it."

Happy to share full native host logs if useful.