Chrome extension device name set via "switch_browser" (Connect flow) doesn't persist in `list_connected_browsers`

Hitting this too, on a different setup — two separate Macs, one Chrome profile each, rather than one machine with stale registrations. Same result: named both via the Connect flow, switch_browser confirms Connected to browser "MacBookProM2", and list_connected_browsers in the same session still returns Browser 1 / Browser 2. Verified twice, hours apart.

Two things that might help whoever picks this up:

deviceId is stable, so it's a usable workaround. The same two UUIDs survived reconnects and a full working day. Selecting by deviceId avoids the pairing dance entirely — the catch is you need to know which is which first.

Identifying them without the dance: serve a random token on 127.0.0.1 bound to loopback, then select_browser each candidate and navigate to it. The browser that reads the token is on this machine; the other gets ERR_CONNECTION_REFUSED. That's how I built a machine→deviceId map once and stopped being asked.

Why it costs more than it looks: the "you must ask the user which browser" mandate is attached to list_connected_browsers' output, so any session that calls it inherits the prompt. Skipping that call and going straight to select_browser is what actually removes the interruption. With the name working, none of this would be necessary.

Following up with a couple more data points from today, on a single Mac with 4 stale/duplicate device registrations (same setup pattern as the original report).

Confirms the original repro exactly: switch_browser → clicked Connect in Chrome, named the device "SJ AGENT" → tool reported Connected to browser "SJ AGENT". Immediately called list_connected_browsers in the same session — same 4 devices, same generic names (Browser 1-4), same deviceIds, same connectedAt timestamps as before the rename. No trace of the new name anywhere in that response.

One clarifying detail that might help narrow down where the bug actually is: the human doing the naming (not the agent) reports that from inside Chrome itself — the extension's own local UI — the name he set does appear to be showing/retained. So the write looks like it succeeds locally on the device, but never gets reflected back to (or read from) the account-level device registry that list_connected_browsers queries. That reads more like a sync/propagation gap between local extension state and the account-level API than a rename that fails outright.

Tried @Zachzeller37's loopback-server suggestion — it doesn't work through the Claude-in-Chrome tools, but not because of anything about which machine is connected. Ran a plain python3 -m http.server on 127.0.0.1, confirmed reachable via curl from the same machine's own shell, then had the connected browser navigate to it — both in an existing tab and a brand-new tab. Both times the navigation silently reverted (back to the prior page, or to chrome://newtab/ for the fresh tab) instead of showing the token, an error page, or anything else — the computer tool even refused to screenshot it ("Can't interact with browser-internal or unparseable URLs"). The same tab loaded a normal https:// site immediately afterward with no issue. This looks like the extension itself silently blocks/reverts navigation to loopback addresses (a reasonable SSRF-style guard on its own), which means it can't be used as a same-machine identity check as suggested — worth flagging so nobody else spends time on that exact approach as a workaround.

deviceId stability itself still holds up as the one reliable fact here (matches what's already been reported) — just still no safe way to map a deviceId to "this machine" without a human clicking Connect once.

Reproduced on Windows 11 / Edge (single Edge install, single profile, one Claude extension installed — fcoeoabgfenejglbffodgkkbkcdhcgfn), so this isn't macOS- or Chrome-specific. Same core result as the original report: switch_browser returned Selected browser "Extension Claude", and the very next list_connected_browsers call showed Browser 1 / Browser 2 with no trace of the name.

Two details differ from the original report, and I think they point somewhere slightly different than "stale cache":

1. The connectedAt timestamps did refresh. The original notes "same connectedAt timestamps" after the connect flow. Here both entries updated — to within 38 ms of each other:

before broadcast:  9c906f95… "Browser 1"  connectedAt 1788912045208
                   e72768ae… "Browser 2"  connectedAt 1788911302209

after  broadcast:  e72768ae… "Browser 1"  connectedAt 1788912596151
                   9c906f95… "Browser 2"  connectedAt 1788912596113

Both entries responding to a single broadcast suggests both registrations are live, not that one is a leftover the list is caching.

2. The labels are positional, not identity-bound. Note the swap above: 9c906f95 was "Browser 1" before and "Browser 2" after, with e72768ae taking the other slot — no action taken on either between those calls other than the broadcast. They appear to be assigned ordinally (most-recently-connected first) at list time rather than stored per device. That would explain why a user-set name has nowhere to live, and it also means a label is unsafe to act on even when one looks real — a session that recorded "Browser 1" from a previous run could act on the wrong device after any reconnect.

Practical note for anyone hitting this meanwhile: switch_browser still works as a workaround, but not because it names anything — it routes on the user's physical click inside the browser, so it's label-independent. It does require a human at the keyboard, which doesn't help the unattended/scheduled case the original report raises.