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

[haxsmert]

Product: Claude in Chrome extension (v1.0.80), used via Claude Code MCP tools (mcp__claude-in-chrome__*).

Filing here since this is the main public feedback repo — please redirect if the Chrome extension has a dedicated tracker.

Summary

Three related problems make it impossible to reliably identify which connected browser a deviceId refers to, and cause the agent to report wrong/garbled browser names.

1. list_connected_browsers returns stale, per-session-cached data

Repeated calls within a single session return identical connectedAt timestamps and never reflect names set via the connect/rename flow. It keeps showing the default Browser 1 / Browser 2 even after a browser has been renamed. The real, user-assigned name was confirmed via the switch_browser handshake, but list_connected_browsers never surfaces it.

2. isLocal is unreliable

Two connections both report isLocal: true, but the host machine runs only one Chrome instance (verified independently via the OS process tree). The second connection is a different physical machine signed into the same Claude account. isLocal appears to mean "same account", not "same host" — which is misleading for any logic that wants to target the local browser.

3. No way to join name ↔ deviceId

• switch_browser returns the real (user-assigned) name, but no deviceId.
• list_connected_browsers returns the deviceId, but only the stale default name.

There is no tool output that contains both, so an agent cannot tell which named/physical browser a given deviceId is. The only workaround was to read the extension's own bridgeDeviceId off local disk to pin which deviceId is the local browser.

Expected

• list_connected_browsers returns live (non-cached) data.
• name reflects the user-assigned name (not a stale default).
• isLocal means same-host — or add a distinct sameHost field, keeping isLocal for same-account.
• switch_browser returns the deviceId alongside the name, so name↔deviceId can be joined.

Environment

• Claude in Chrome extension v1.0.80
• macOS, Chrome (stable)
• Two browsers connected to the same account (one local, one remote)

[imgusev]

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"
   

3. 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.

[imgusev]

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.

[bertshim]

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.

[anandman]

Adding a data point on §2 that runs in the opposite direction to the original report, on extension v1.0.90 (newer than the v1.0.84 confirmed above).

isLocal: false for a browser verified to be on the same host

Setup: a Cowork cloud session linked to a local Mac; two Chrome instances signed into the same Claude account, one on the local Mac and one on another machine.

Ground truth was established without trusting the extension's self-report. The selected browser was navigated to example.com via mcp__claude-in-chrome__navigate, then the local Mac was queried directly through AppleScript:

Chrome windows: 1
  w1 t1: chrome://newtab/
  w1 t2: https://example.com/

The navigation landed in the local machine's own Chrome window, also visually confirmed on screen by the user. That same device reports:

{"deviceId":"c3e7a0f2-…","name":"Browser 1","osPlatform":"macOS","isLocal":false}

This rules out the §2 hypothesis that isLocal means "same account". Both connections here are on the same account, so under that reading both should report true. Both report false. Combined with the original report's remote-but-true observations, the field appears to be wrong in both directions rather than consistently meaning same-account.

Independent confirmation of §1 (stale/cached)

After a switch_browser handshake that returned Connected to browser "minion", list_connected_browsers returned a byte-identical entry — still the stale Browser 1, same connectedAt (1788477393543), same isLocal: false.

connectedAt failing to advance across a successful re-pair seems a fairly direct signal that the cache is never invalidated.

Related to §3: labels are positional, not device-bound

Across two calls in a single session the labels swapped between devices:

Listing	c3e7a0f2…	d1db6dda…
initial	Browser 2	Browser 1
after relaunching local Chrome	Browser 1	Browser 2

So "Browser 1" referred to two different physical machines minutes apart. Since list_connected_browsers instructs the agent to present these labels to the user as the authorization choice, a label that silently reassigns across machines means a user can approve an action in one browser and have it execute in another.

That is what happened here: the user selected "Browser 1" and an admin dashboard was opened on the remote machine's Chrome instead of the one in front of them.

Downstream consequence

This is not only a targeting annoyance. The 1Password credential path appears to gate on isLocal, so a false negative disables it entirely — request_credentials and list_granted_credentials both return {"status":"unavailable","reason":"local_browser_unavailable"} even with the correct local browser selected and 1Password paired and healthy. Details in #87365.

Environment

• Claude desktop app 1.44121.4 (Electron 42.10.0), Cowork cloud session linked to a local Mac
• macOS 26.4.1, Apple Silicon
• Chrome 152.0.7977.77
• Claude in Chrome extension 1.0.90

[anandman]

Correction to my comment above.

The "Downstream consequence" paragraph attributed the 1Password credential failure to the isLocal misreport. That link is not supported by the evidence and I am retracting it.

#79976 carries a better-evidenced explanation: the Claude in Chrome extension's local storage holds no 1Password partner extension ID, consistent with the relay failing no_target. I have since verified the same on extension v1.0.90 — zero occurrences of the 1Password extension ID in the Claude extension's Local Extension Settings, while 14 agentic-related keys are present. So agentic-mode config arrives but no partner ID accompanies it, which needs no isLocal involvement to explain the failure.

The isLocal: false observation, the connectedAt staleness across a successful re-pair, and the positional-label swap all rest on their own independent evidence and stand as written. Only the 1Password causation was wrong. Please follow #79976 for that thread.

[bertshim]

Windows confirmation of the local join, and a correction to my own comment above.

The Local Extension Settings approach works on Windows as well. The path is per Chrome profile:

%LOCALAPPDATA%\Google\Chrome\User Data\<Profile>\Local Extension Settings\fcoeoabgfenejglbffodgkkbkcdhcgfn

Pulling UUIDs out of those LevelDB files on this machine returned a different set for every profile, and the id currently handed back by list_connected_browsers appeared in exactly one of them.

That is also where my earlier comment goes wrong, so I want to correct it rather than leave it standing. I reported that the deviceId of a single physical machine moved: a88b0d8a-... all day on 2026-08-23, gone by evening, and the same desktop back three hours later as 4a1a86cb-.... I read that as the id being unstable across time. It is stored per profile. a88b0d8a-... is still sitting in the storage of a different Chrome profile on this same box, and 4a1a86cb-... is in another one. Opening a different profile presents what looks like a different machine. The hardcode-deviceId-to-purpose table I said I had rewritten twice was keyed on the machine when the id belongs to the profile.

One more field that does not hold, and it bears on §1. name behaves as a position in the response rather than a stored default. Same account, three browsers, two calls on the same day:

first call
  4a1a86cb...  "Browser 1"   connectedAt 03:12
  e1496311...  "Browser 2"   connectedAt 02:47
  6972472d...  "Browser 3"   connectedAt 00:57

second call, same day
  e1496311...  "Browser 1"   connectedAt 16:32
  6972472d...  "Browser 2"   connectedAt 16:15
  4a1a86cb...  "Browser 3"   connectedAt 10:20

Not one deviceId changed in between. The list comes back sorted on connectedAt, newest first, and the names follow that order in both calls, so a browser reconnecting renames every entry below it. Across three days the same physical machine came back as Browser 1, Browser 2 and Browser 3.

That suggests the Expected for §1 needs rewording. A value that describes a position in the response is a different defect from a stale value, and it needs a different fix: the name has to be attached to the device, not to the index.

Last thing from the same dump, in case it helps the join: one UUID appears in all four profiles on this install, while the rest are profile-specific. If that one is a per-install handle, exposing it next to each entry would give the stable key this issue is asking for.