Claude in Chrome extension: CLI session reports "not connected" indefinitely, even with a fresh native-messaging host, no competing sessions, and the extension showing enabled/connected on the Chrome side

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

Summary
Every call to a mcp__claude-in-chrome__* tool (e.g. tabs_context_mcp) returns "Claude in Chrome is not connected" — persistently, across many retries over an extended troubleshooting session — despite the extension appearing installed, signed in, and connected from the Chrome/extension side.
Steps already tried, all without resolving it
Confirmed the extension is installed and signed in with the same account as the Claude session.
Toggled the extension off/on in chrome://extensions.
Restarted the Claude desktop app.
Reloaded Chrome entirely.
Used the extension's own "link" option (a linking flow surfaced in its UI) to attempt to re-establish the connection.
Investigated for a specific known failure mode — a second, concurrent Claude Code CLI session competing for the same native-messaging host — and ruled it out: found two claude CLI processes running (--resume= and --resume=), closed the other session (kill on its main process and its disclaimer wrapper, confirmed both exited), and retried. Connection still failed.
Killed the chrome-native-host process directly (/Applications/Claude.app/Contents/Helpers/chrome-native-host chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/) to force a fresh instance. Confirmed via ps aux that a new instance of this process spawned with a new PID after reloading Chrome. Connection still failed against the fresh process.
Investigated a separate, differently-named local extension (ant.dir.ant.anthropic.chrome-control, an older/unrelated AppleScript-based Desktop Extension with a completely different tool set — open_url, list_tabs, etc., not the tabs_context_mcp/computer/read_page tools used by Claude in Chrome). Confirmed this was a red herring — its own backend server (server/index.js) was not running, and it appears unrelated/unused, so this is a dead end, not the cause.
Searched the filesystem broadly for any local data/logs tied to the actual Claude in Chrome extension by its real Chrome Web Store ID (fcoeoabgfenejglbffodgkkbkcdhcgfn) — found nothing, suggesting its connection state isn't surfaced anywhere inspectable from the filesystem.
What this rules out
Not a stale extension install/sign-in issue (steps 1-2, 4-5).
Not the known "Desktop app vs Code CLI competing for the native host" conflict, at least not in the simple form of two sessions racing for one host (step 6) — the failure persists with only one Claude Code session running.
Not a wedged/stale native-messaging host process — a completely fresh process still fails to bridge the connection (step 7).
What would help debug this further
Any logging the extension itself writes (e.g. via chrome://extensions → "Inspect views" on its background page/service worker) that would show why the native host handshake is rejected or times out even when a fresh host process exists.
Confirmation of what "connected" actually requires beyond the native host process existing — is there a secondary handshake/token exchange between the CLI session and the extension that could be failing silently?
Impact
This blocks any workflow that depends on Claude in Chrome to interact with an authenticated internal web dashboard (in this case, downloading documents from a company's internal tool to copy into Google Drive) — there is no equivalent authenticated-session alternative available.

### What Should Happen?

The mcp__claude-in-chrome__* tools should successfully connect to the browser extension and allow driving the user's authenticated Chrome session (navigating, reading pages, clicking, etc.) whenever the extension is installed, signed in, and enabled — regardless of how many Claude Code sessions have run previously or how many times the extension has been reloaded. A fresh chrome-native-host process existing should be sufficient for the connection to succeed; it should not remain stuck reporting "not connected" indefinitely with no other diagnostic signal available to the user.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

Have Claude Code running with the Claude in Chrome extension installed, signed in, and showing enabled/connected on the Chrome side.
Call any mcp__claude-in-chrome__* tool (e.g. tabs_context_mcp) — get "Claude in Chrome is not connected."
Retry the same tool call — same error, repeatedly, over an extended period.
Toggle the extension off/on in chrome://extensions — retry — same error.
Fully restart the Claude desktop app — retry — same error.
Fully reload Chrome — retry — same error.
Check for other concurrent Claude Code CLI sessions on the machine; close any found — retry — same error persists even with only one session running.
Kill the chrome-native-host process directly to force a completely fresh instance (confirmed via ps aux that a new process with a new PID spawns after the next Chrome reload) — retry — same error persists against the fresh process.

At no point after step 2 did the connection succeed.

### Claude Model

None

### Is this a regression?

No, this never worked

### Last Working Version

_No response_

### Claude Code Version

claude-code/2.1.260/

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

Start at the mcp__claude-in-chrome__* tool entry point, especially tabs_context_mcp, and trace the connection state through the chrome-native-host handshake. Reproduce on macOS with the extension enabled and inspect the extension service worker logs and any available CLI diagnostics. Done means the tool connects reliably or reports a specific actionable handshake failure.

索引モデルが issue の本文から書いたものです。