claude-in-chrome: one-way channel — extension live-renders the same session that gets [] from list_connected_browsers

Still reproduces on 2.1.251 + extension 1.0.85, from a cold start with every variable controlled

Re-tested 2026-08-29. This run closes the variables that were still open in the original report: Chrome was fully quit and cold-started, the extension re-paired from scratch afterwards, the native host respawned from the updated install, and only one Claude Code session was running, so there is no session-picker ambiguity.

| Variable | Value |
| --- | --- |
| OS / arch | macOS 15.7.9, x86_64 |
| Chrome | 151.0.7922.174, fully quit and relaunched at 20:25; one profile opened, signed into claude.ai with the same account as Claude Code |
| extension | 1.0.85 (current on the Web Store), re-paired from pairing.html after the relaunch, browser named |
| native host | pid started 20:25:24, claude --chrome-native-host, launched from the 2.1.251 CLI install |
| bridge socket | published 20:25, i.e. before the session existed |
| session | started 20:27:45, claude --chrome, 2.1.251 |
| other sessions | none |
| desktop-app manifest | still renamed aside/disabled, so no native-messaging host contention |

Result, unchanged from the original report:

list_connected_browsers  ->  []
tabs_context_mcp         ->  "Browser extension is not connected. Please ensure the Claude
                              browser extension is installed and running ..."

The other direction still works. The extension's </> session list shows this session (alongside a remote-control session); selecting it live-renders that session's transcript in the side panel. So the extension can locate and read the very session that Claude Code reports has no browser attached — the one-way channel is intact on current builds.

Additionally ruled out by this run, on top of what the original report ruled out:

• stale native host inherited from a previous Chrome lifetime
• stale or never-refreshed pairing
• version skew — both ends are current (2.1.251 / 1.0.85)
• multiple concurrent sessions confusing session selection
• the 2.1.243 fix "native host now launches via the stable claude launcher" — present here, and not sufficient

Neither side surfaces an error; both report themselves healthy.

Correction from the reporter: my central claim in this issue is wrong. Retracting it, and replacing it with something simpler.

Re-tested 2026-09-09. Before the new evidence, a retraction, because I sent this issue in the wrong direction and it may be why it has sat untouched.

❌ Retracted: "the extension live-renders the same session that gets []"

That is the title of this issue and the core of both prior reports. It is false. What I was actually looking at was claude.ai open in an ordinary tab — claude.ai/code/session_<id>, the cloud session view. That path goes through Anthropic's servers and has nothing to do with the local native-messaging bridge. The extension was never rendering the session.

I confirmed this twice in earlier comments in good faith. I was reading the wrong surface both times. There is no one-way channel; there is no "same two processes, one direction only."

✅ What is actually true, restated plainly

The local native-messaging bridge never establishes. That's the whole bug:

list_connected_browsers  ->  []
tabs_context_mcp         ->  "Browser extension is not connected"

…while every precondition on both sides is satisfied.

New evidence since the last comment

1. Both ends have advanced independently; failure is bit-for-bit identical.

| | previously tested | now |
| --- | --- | --- |
| extension | 1.0.85 | 1.0.91 (auto-updated 2026-09-08) |
| Claude Code | 2.1.251 | 2.1.266 |

1.0.85 was the version in every prior test on this issue. This should retire version skew as a candidate.

2. No permission is being withheld on either side. From Chrome's Secure Preferences for the extension:

disable_reasons         = []
withholding_permissions = false
active_permissions      api: nativeMessaging, debugger, tabs, tabGroups,
                             scripting, webNavigation, activeTab, ...
                        explicit_host: ['<all_urls>']

nativeMessaging active, host access <all_urls> granted and active. On the CLI side: no deny rules, no managed settings / org policy, claudeInChromeDefaultEnabled: true, onboarding completed. (Only system.display is granted-but-inactive — screenshot display metadata, unrelated.)

3. Re-pairing does not restart the bridge. Re-paired from pairing.html; the native host PID and its socket were unchanged before and after — same pid, same socket file, same mtime. Pairing state and the native-messaging channel appear fully independent. Worth stating because "try re-pairing" reads like a connection reset and it is not one.

4. Preconditions for this run, all brought up minutes before the test:

| Variable | Value |
| --- | --- |
| Chrome | started 12:28:59 |
| profile | Default, same account as Claude Code |
| native host | the CLI's (claude --chrome-native-host), 12:29:26 — Claude Desktop's competing native-messaging manifest is disabled, so no host contention |
| bridge socket | published 12:29, 0600, correct uid — predates the session |
| session | 12:44:56, launched with --chrome |
| result | [] |

The part I think is worth a maintainer's attention

I don't think I'm unusually careless, and I burned four sessions across two weeks on this. The reason is that three separate surfaces indicate success while the bridge is dead, and none of them is actually connected to it:

1. claude.ai in a browser tab renders the live session. Cloud path. Looks exactly like "the browser can see my session," which reads as the bridge working.
2. The ✅ Claude (MCP) tab group. This is a saved Chrome tab group whose name contains a literal checkmark emoji, restored on every launch. It is static text. I had it recorded in my own notes as meaning "the bridge is healthy." It means nothing.
3. The pairing tab self-closes on completion, which is indistinguishable from success whether or not pairing achieved anything.

Meanwhile the failure itself is a generic "Browser extension is not connected" and an empty array — no error code, no log, nothing naming which end failed or why.

I count ~11 open issues describing this same symptom in different words (#90013, #89913, #89780, #90385, #90469, #90153, #90306, and others), and one — #89918 — was auto-closed as NOT_PLANNED for needing "a bit more information." I'd suggest the near-duplicate reports and the missing information are downstream of the same cause: there is no way for a user to tell which half is broken. Even a single log line, or having list_connected_browsers distinguish "no browsers paired" from "paired but unreachable," would collapse most of that cluster.

Questions

• Is there a diagnostic mode or a log for the native-messaging host? I can reproduce this on demand and would rather hand over a log than another table of inferences.
• Is a full extension remove-and-reinstall expected to help here, or is the pairing record held somewhere that survives it?

Happy to run anything specific. Environment: macOS 15.7.9 x86_64, Chrome 151, Claude Code 2.1.266, extension 1.0.91.

Follow-up to my previous comment — resolved, and the fix was a plain reinstall, not a version fix.

Removing the Claude extension from Chrome and installing it again fixed it. The version was identical on both sides: 1.0.91 before, 1.0.91 after, same 1.0.91_0 folder on disk. A reload and a full Chrome restart had both already been tried in earlier attempts and did not clear it. Whatever was wedged lived in the extension's registration state, and only a clean reinstall cleared it.

The transition

From a session started as claude --chrome --debug-file /tmp/cic.log:

20:34:28  Bridge received: {"type":"extensions_list","extensions":[]}
20:34:38  NoExtensionConnectedError
                     ---- delete + reinstall extension ----
20:49:35  Bridge received: {"type":"peer_connected","clientType":"chrome-extension",
                            "deviceId":"bf6bf817-..."}
20:57:33  Bridge received: {"type":"extensions_list","extensions":[
                            {"deviceId":"bf6bf817-...","osPlatform":"macOS",
                             "extensionVersion":"1.0.91"}]}

Verified end to end immediately after: created a tab group, navigated to example.com, read the page title back, closed the tab.

Worth stressing: the CLI half authenticated and reached the bridge successfully in every failed attempt (Connection successful, connected=true, authenticated=true, wsState=1). The failure was only ever that no extension had registered at the user-scoped rendezvous.

Two suggestions

1. The error text points the wrong way. It says "ensure the Claude browser extension is installed and running ... you may need to restart Chrome." Here the extension was installed, enabled, service worker started, with a native host spawned by Chrome — and restarting Chrome did not help. Only reinstalling did. Adding "try removing and reinstalling the extension" would have saved three abandoned debugging sessions on my end.

1. The two failure modes are indistinguishable to the user. "Extension not installed" and "extension installed but not registered at the bridge" present identically, and the side panel reported connected throughout. Surfacing the extensions_list state anywhere in the UI — even just "0 browsers registered" — would make this self-diagnosing.

The diagnostic that would have short-circuited it

grep 'extensions_list' /tmp/cic.log | tail -1

Empty array means the extension is not at the bridge, so reinstall it. Everything local — claude mcp list, lsof -iTCP, native-host pid, Chrome profile, concurrent session count — is a red herring, because the rendezvous is a cloud relay and a local-only investigation cannot see the far side of it.