Claude in Chrome: CLI never contacts the native messaging host (Status stays "Disabled")

Closing this — my mistake, it is documented behavior rather than a bug.

I authenticate with a long-lived token from claude setup-token. Per the Chrome docs: "If you authenticate with an API key or a long-lived token from claude setup-token, Claude Code keeps Chrome integration off, even when you pass --chrome, because the browser extension can't authenticate with those credentials." Everything reported above is the visible consequence of that: the CLI decides the integration is off before it ever tries to reach the native messaging host, so the host stays silent and the bridge never connects.

One small suggestion, take it or leave it: /chrome reports a bare Status: Disabled alongside Extension: Installed, which reads as a malfunction. Surfacing the actual reason there — something like Disabled (not supported with setup-token credentials; sign in with /login) — would have saved a long debugging session. The native host also stays silent with no hint as to why, which is what made this hard to pin down.

Reopening — my previous comment was wrong, and I have a much more precise diagnosis.

I do own a setup-token, but this installation does not use it. The keychain entry holds an ordinary interactive session: accessToken + refreshToken, expiresAt +10h, refreshTokenExpiresAt +1 month, scopes user:sessions:claude_code, user:mcp_servers, user:plugins, user:file_upload, user:inference, user:profile, subscriptionType: max. No ANTHROPIC_* variable anywhere. So the documented setup-token exclusion does not apply here.

The actual finding. On macOS, the CLI installs the native host manifest for Chrome and Edge only — including when neither is installed — and never for Brave, which is the only browser present on this machine:

[DEBUG] [Claude in Chrome] Installed native host manifest at: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json
[DEBUG] [Claude in Chrome] Installed native host manifest at: ~/Library/Application Support/Microsoft Edge/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json

Google Chrome.app and Microsoft Edge.app are both absent; only Brave Browser.app exists. The docs state that Claude Code "detects the extension and sets up the connection in other Chromium-based browsers, including Brave, Arc, Vivaldi, and Opera", which does not match this behavior.

Placing the manifest in Brave's directory by hand is not enough. With it in place the extension-side chain works perfectly — the extension launches the native host and exchanges ping / get_status with it — but the CLI still never opens a connection to that host, so detection evidently keys off the Chrome/Edge profile directories rather than the manifest.

Repro: macOS, Brave as the only Chromium browser, extension installed and signed in, valid interactive OAuth session, claude --chrome -> /chrome reports Status: Disabled / Extension: Installed forever.

Workaround for anyone hitting this: install Chrome or Edge alongside Brave.

Correction to my previous comment: installing Chrome does not fix it either.

Chrome is now reinstalled and running, extension 1.0.93 present in the Default profile, native host manifest in place, and Chrome itself launches the native host (verified: the host process' parent is /Applications/Google Chrome.app/Contents/MacOS/Google Chrome). A fresh claude --chrome session still never contacts that host, and still ends with:

[INFO]  Bridge URL: wss://bridge.claudeusercontent.com
[DEBUG] [closeSessionTabGroup] bridge not connected, skipping

So the Chrome/Edge-only manifest installation I reported above is a real observation, but it is not the cause. The core symptom in the original report stands, and is browser-independent: with everything correctly in place on the browser side, the CLI never opens a connection to the native messaging host.

One variable not yet eliminated, in the interest of full disclosure: a second claude --chrome session was running on another TTY throughout these last tests. Earlier in the session, a stale --chrome process did appear to hold the integration. That has not been ruled out for the Chrome retest specifically, and I did not want to report a clean result that might not be one.

---

Written by Claude (Claude Code, Opus 5) during a roughly two-hour debugging session on the reporter's machine — the reporter did not write this text, and asked me to say so plainly. Every log line, path, PID and version number above is real output captured from that machine, not reconstructed. Two hypotheses were raised and disproved along the way (a stale chromeExtension pairing, then setup-token credentials); both are documented above rather than quietly deleted, since the eliminations are part of what makes the remaining finding worth something. The native host stderr capture in particular is not obtainable without instrumenting the wrapper script, which is why it is included.