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

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

Summary

Naming a Chrome device during the "confirm in browser" pairing flow appears to only apply to the
current session's binding, not to the account-level device registry. A brand new session calling
list_connected_browsers right after still sees the device under its old generic name
(Browser 1/Browser 2/Browser 3), not the name just given it — so the rename never "sticks" for
future sessions.

Environment

• Claude Code CLI, macOS
• Chrome extension: Claude in Chrome, single Chrome profile, one machine with 3 connected browser

entries showing (2 believed to be stale/duplicate registrations from past reconnects)

Steps to reproduce

1. In a session, call list_connected_browsers — note the entries and their generic names

(Browser 1, Browser 2, Browser 3), all with isLocal: true.

1. Call switch_browser (the "open a confirmation screen in every connected Chrome extension" flow).
2. In the actual Chrome browser on the target machine, click "Connect" and give the device a custom

name (e.g. "MY-MACHINE") when prompted.

1. Tool reports success: Connected to browser "MY-MACHINE".
2. Immediately call list_connected_browsers again (same session, or ideally a fresh session).

Expected

The device entry that was just connected/named should show the new name (MY-MACHINE) in
list_connected_browsers, so a future session (including an unattended/scheduled one with no human
available to click "Connect") can reliably select it by name.

Actual

list_connected_browsers returns the exact same list as step 1 — same 3 devices, same generic
names (Browser 1/2/3), same deviceIds, same connectedAt timestamps. The rename from step 3
is not reflected anywhere in that account-level list, even though the connect/bind itself clearly
worked (the session's browser tools correctly operate on the intended Chrome — confirmed via
existing open tabs matching what was expected).

Why this matters

For any workflow that depends on repeatedly/reliably identifying "this machine's browser" across
independent sessions (e.g. scheduled/cron-triggered Claude Code runs with no human present to
disambiguate), a persistent, reliable device name is the only mechanism available — isLocal is not
trustworthy (observed true on every entry, including ones later confirmed to be stale/other-machine
registrations). If naming never persists past the session that set it, there's no way for an
unattended run to safely pick the right browser once more than one device is registered — which
happens easily over time as the extension reconnects (sleep/wake, network drop, extension
reload/update, Chrome restart) and appears to mint a brand-new device entry each time rather than
reusing/updating an existing one.

What we'd expect instead

• Either the name set during the Connect-flow pairing should persist to the account-level device

registry and be visible to list_connected_browsers in later sessions, or

• there should be some other durable, human-assignable identifier for a given browser install that

survives reconnects, so unattended sessions can target a specific machine reliably without a human
needing to click "Connect" every single time.

Happy to provide more repro detail/logs if useful.