Claude in Chrome (v1.0.80): list_connected_browsers is stale/cached, isLocal misreports host, and name↔deviceId can't be joined

Confirming this on extension v1.0.84 (macOS, Chrome stable) — the rename behaviour in §1/§3 is unchanged.

Repro from today's session

1. list_connected_browsers → two entries, Browser 1 / Browser 2.
2. switch_browser → user clicks Connect in the intended browser and types a name. The call returns the name correctly:

``
Connected to browser "MY"
``

1. list_connected_browsers immediately after — and again a minute later, after unrelated tool calls — still returns:

``
Browser 1 (deviceId A)
Browser 2 (deviceId B)
``
The user-assigned name never appears.

The user has renamed these browsers repeatedly across past sessions with the same outcome, so this is not a one-off.

Data point on isLocal

In this setup both connections really are on the same Mac (two Chrome profiles, one personal MY and one for work WORK), and both report isLocal: true — correct in this case. So the field is not always wrong, but as §2 notes it still cannot distinguish same-host from same-account, so it is unusable for targeting.

Practical impact

Because the only stable identifier is an opaque deviceId, the agent has to ask "Browser 1 or Browser 2?" — a question the user cannot answer either, since nothing inside Chrome shows which is which. In this session the user picked the wrong one, the agent opened a page in WORK instead of MY, and it surfaced only when an expected login session was missing. Workaround: hardcoding deviceId → purpose in the agent's long-term memory.

Smallest fix that would unblock this

Have switch_browser return the deviceId alongside the name. That alone makes name↔deviceId joinable, without touching the caching behaviour described in §1.

**Follow-up: the mapping is recoverable locally, which makes the missing join look even more like a gap in the tool surface.**

In this setup the two "browsers" turned out to be two profiles of a single Chrome install — which is why both report isLocal: true. Each profile's deviceId is stored in the extension's own Local Extension Settings, so it can be joined to a profile with no tool support at all:

EXT=fcoeoabgfenejglbffodgkkbkcdhcgfn
for p in "Default" "Profile 1"; do printf "%-10s " "$p"
  strings ~/Library/Application\ Support/Google/Chrome/"$p"/Local\ Extension\ Settings/$EXT/* 2>/dev/null \
    | grep -oE '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}' | sort -u | head -3
done

Cross-referencing that with the profile display names in Chrome's Local State (profile.info_cache[*].name) yields an exact profile name ↔ deviceId mapping — which is precisely what list_connected_browsers should have returned in the first place.

So the data exists on disk and is stable; only the API omits it. Having to shell out and grep a LevelDB store to answer "which browser is this?" seems a strong argument for returning the deviceId from switch_browser (or the real name from list_connected_browsers).

Tested on extension v1.0.84, which the Chrome Web Store update endpoint currently reports as the latest available version — so the behaviour above is present in the newest release, not just in v1.0.80.

Windows 10 here. The part that broke for me is that the deviceId itself moved, which undercuts the workaround both comments land on.

On 2026-08-23 my desktop sat in list_connected_browsers all day as a88b0d8a-.... Around 19:14 it stopped appearing. At 22:45 the same physical machine was back in the list under 4a1a86cb-.... During the gap, three ids I had no record of showed up at once, one of which turned out to be a laptop I keep around for something unrelated entirely.

I was already doing the hardcode-deviceId-to-purpose thing, in a written table, and I've had to rewrite that table twice in a week. The row that was correct in the morning pointed at nothing by the evening. I lost something like an hour and a half that day just working out which entry was the machine sitting in front of me.

I didn't port your Local Extension Settings grep over to Windows, so I can't tell you whether the on-disk value rotated too, or whether only the API started reporting something different.

Raising it because if the ids do rotate, returning the deviceId from switch_browser makes the join work inside one session but still not across sessions.