Claude in Chrome: list_connected_browsers reports a live local browser with no browser running, and navigate returns success while doing nothing

Product: Claude in Chrome extension (1.0.92), driven from Claude Code via
mcp__claude-in-chrome__*. Windows 11, Microsoft Edge (stable), single install, single
profile, one extension.

Summary

With no browser process running at all, list_connected_browsers continues to report a
connected browser with isLocal: true and a connectedAt that keeps advancing. Calling
navigate against that registration returns "Navigated to <url>" with a real tab id
and does nothing. No tab, no window, no error. Every subsequent browser call behaves as
though it is driving a real page.

This is not the stale-name/caching problem in #78096 — the entry is not merely
mislabelled, there is no browser behind it.

Reproduction

1. Close every browser. Confirm independently that none is running — on Windows,

Get-Process shows no msedge/chrome; a UI-Automation enumeration of top-level
windows shows no browser window.

1. Call list_connected_browsers.

→ returns one entry, isLocal: true, with a recent connectedAt.

1. Call navigate with any URL.

→ returns Navigated to <url> plus a tab id. Nothing opens.

1. Open the browser. Call list_connected_browsers again.

→ byte-identical entry, same connectedAt. Launching a real browser does not
change the registration.

1. Call switch_browser.

→ "No other browsers available to switch to." — i.e. the live extension is not
connected, while the dead registration continues to be served as the connected one.

Reconnecting the extension by hand (from its toolbar button) does refresh connectedAt,
and one navigate then works correctly.

Observed data

no browser process running:
  list_connected_browsers -> [{ deviceId: 9c9…, name: "Browser 1",
                                osPlatform: "Windows",
                                connectedAt: 1789165039624, isLocal: true }]
  navigate               -> "Navigated to https://news.ycombinator.com/item?id=…"
                            tabId 410375950
  actual browser windows -> none

after launching the browser (no other action):
  list_connected_browsers -> identical, connectedAt unchanged (1789165039624)
  switch_browser          -> "No other browsers available to switch to."

Two things that make this expensive in practice

1. There is no in-band way to tell a real success from a false one. We tested the
obvious candidate: navigate's reply contains two tab-state blocks, and on failures they
disagree. They also disagree on calls that provably succeeded — the second block is
pre-call state by documented design (tabs_context_mcp is run for you before the
navigation and its result appended). So the disagreement fires on every successful call
too. Nothing inside a successful payload distinguishes it from a lying one; the only
reliable check is an out-of-band one, e.g. reading the browser window's address bar
through the OS accessibility API.

2. The failure does not stay silent — it produces a confident wrong diagnosis. After a
navigate that went nowhere, get_page_text on the returned tab id did not error; it hung
for 45 seconds on document_idle, twice. The natural reading is "that website is slow",
and that is what we concluded, wrongly, about an unrelated third-party site. So the first
symptom is a false success and the second is a plausible failure attributed to the wrong
cause.

Recurrence

The reconnection is not durable. After a manual reconnect, one navigate succeeded; ~90
minutes later the same silent failure returned across two independent sessions
simultaneously. The extension directory on disk had been rewritten in the interval, which
is consistent with an extension update dropping the connection without the registration
noticing — offered as correlation, not proven cause.

Expected

• list_connected_browsers should not report a browser that has no running process, or

should carry a field distinguishing "registered" from "currently reachable".

• navigate (and other page-acting tools) should fail loudly when the target extension is

not reachable, rather than returning a success string and a tab id.

• Ideally switch_browser returning "no browsers available" and list_connected_browsers

returning one should not be able to disagree, since they are answering the same question.

Environment

• Claude in Chrome extension 1.0.92 (1.0.91 also present on disk)
• Windows 11, Microsoft Edge stable, one install, one profile
• Claude Code desktop 2.1.260