claude-in-chrome extension fails to connect (tabs_context_mcp: "Browser extension is not connected") after reinstall + full Chrome restart

Hitting the same thing on macOS — adding details in case it helps narrow it down:

Pattern: intermittent, not permanent. It was working fine a few days ago, then broke again with no clear trigger (no CLI update, no extension update that I initiated).

Environment: macOS, Chrome (was 150.0.7871.129, auto-updated to 150.0.7871.182 mid-troubleshooting — no change in behavior either version).

Things tried, none fixed it:

• Killed orphaned chrome-native-host processes (found 3 running, spawned by Chrome, parented to /Applications/Claude.app/Contents/Helpers/chrome-native-host — the Desktop-app-oriented native host, not the CLI's own copy at ~/.claude/chrome/chrome-native-host)
• Fully quit + relaunched Chrome (this is what triggered the Chrome auto-update above)
• Quit the Claude Desktop app entirely (was running, thought it might be claiming the extension channel) — no change; interestingly, even with Desktop app not running, Chrome still spawned the extension's native host from inside Claude.app, not the CLI's manifest at ~/.claude/chrome/chrome-native-host
• Disabled/re-enabled the extension in chrome://extensions
• Checked both the extension's service worker console and its offscreen document console while retrying — both show zero log output/errors when Claude Code attempts to connect, suggesting the connection attempt never reaches the extension's handshake logic at all

/chrome in the CLI shows Status: Enabled, Extension: Installed, Browser: TSR Chrome (a named Chrome profile), but sits indefinitely on "Looking for connected browsers…"

Happy to grab any logs that would help — just let me know what to pull.

Hitting the same issue. Adding a data point since the timing seems relevant: this started the same day I switched Anthropic accounts (Pro on a personal email → Team on a work email). Like the OP, confirmed CLI and browser were on the matching (new) account throughout.

Additional steps tried beyond what's listed above, none resolved it:

• Full Chrome quit (not just closing windows) + relaunch
• Checked Team org admin settings (I'm the admin) — extension was already enabled org-wide; toggled it off/on anyway
• Cleared browser cookies

Consistent "Browser extension is not connected" through all of it. The account-switch correlation between both reports makes me suspect some pairing/session state isn't being cleanly invalidated when the underlying account changes — possibly something not purely local to the browser, since a full reinstall didn't clear it either.

Follow-up with a concrete lead, from checking native messaging manifests directly (macOS):

Both native-messaging host manifests register the same extension ID as an allowed origin:

• Desktop app's manifest — ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json (host name com.anthropic.claude_browser_extension, path /Applications/Claude.app/Contents/Helpers/chrome-native-host) — dated Jan 27
• CLI's own manifest — .../com.anthropic.claude_code_browser_extension.json (host name com.anthropic.claude_code_browser_extension, path ~/.claude/chrome/chrome-native-host) — dated Jul 21

Both list chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ as an allowed origin.

ps aux showed the running native host process was spawned from the Desktop app's path (/Applications/Claude.app/Contents/Helpers/chrome-native-host), same as @CR88 found — but since the same extension ID is valid for both host names, this looks less like an "orphaned process" issue and more like the extension itself calling chrome.runtime.connectNative(...) with the wrong host name (com.anthropic.claude_browser_extension instead of com.anthropic.claude_code_browser_extension), so Chrome dutifully launches the Desktop app's host instead of the CLI's.

I killed the stray process and retried tabs_context_mcp — it did not respawn any native host process at all, and the connection still failed silently (matching @CR88's observation of zero log output in the extension's service worker / offscreen document consoles — the connection attempt doesn't appear to reach the extension's handshake logic).

Environment: macOS 15.7.4, Chrome 150.0.7871.187, same account-switch trigger as my prior comment (Pro personal → Team work email).

If it's useful, happy to try clearing whatever local extension state maps "current session" to a host name — didn't want to guess and make the account-switch state worse without a pointer to where that's stored.

Same issue here. Extension installed and shows active in the toolbar (Chrome, Windows). Restarted Chrome fully to complete a pending update, confirmed it's enabled in chrome://extensions, reopened the target tab — but the session keeps reporting "Browser extension is not connected" on every attempt.