[FEATURE] Don't anonymize user-assigned browser names ("Browser 1", "Browser 2") sent to the model
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
When connecting Claude in Chrome, the extension lets me assign a name to each browser, stores it, and re-proposes it on later connections (e.g. "Laptop (Edge)", "Desktop (Brave)"). However, the data passed to the model via list_connected_browsers replaces these names with generic positional labels: name: "Browser 1", name: "Browser 2". Only the deviceId (a raw UUID) survives.
This breaks the feature in a way that hurts the user it's supposedly protecting:
- The name I authored is hidden, and I'm handed a UUID that is meaningless to a human. When the model shows the browser picker, I cannot tell which entry is which machine.
- For anyone running more than one connected browser/machine, this is a real footgun: selecting the wrong entry means sending browser actions to the wrong computer.
- The "privacy" justification is hard to follow: the name is user-authored data, stored by the extension and shown back to me anyway. Masking it from the model doesn't protect me from myself; it just makes selection unreliable.
Impact: multi-browser / multi-machine users can no longer reliably identify the target browser. The picker degrades from "choose by name" to "guess by UUID and ordering".
Proposed Solution
Pass the user-assigned display name through to the model (or expose an opt-in setting), so list_connected_browsers returns the real label alongside the deviceId. At minimum, make the anonymization toggleable per account.
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
The user defined names were returned until very recently, just as you are suggesting. They've only just broken this feature.
I'm fairly sure it's just a bug - there's no justification for the change on security grounds. The list of returned browser only includes those where I'm signed in with the same Claude account, so it's perfectly safe to tell me what I called them.
Not being able to see which one I'm connecting to is a _security downgrade_.
I name the browsers after their hostnames, so that I can then tell Claude to always connect to the browser with the same hostname given by the env var it is running with.
Although now I see that Claude Code can now use the remote/local status of entries to pick the local one. So will switch to doing that.
Adding a reproducible detail that points to this being a regression rather than an intentional privacy redaction:
When I trigger a browser reconnect, the browser comes back with the name I assigned it (e.g. "Laptop (Edge)") — so the user-assigned label is clearly still stored and available.
But the moment I switch browser (the selection step), the labels are re-anonymized to "Browser 1" / "Browser 2".
So within the same session the real name is exposed on one path and replaced by a generic positional label on the other — the two paths appear to read from different sources, and only the selection / list_connected_browsers path strips the name. The data isn't gone; it just isn't carried through that one path.
Confirming @danielearwicker: this worked until very recently. Please restore the previous behaviour so list_connected_browsers returns the user-assigned name (or at least make the two paths consistent).
Screenshots
<img width="261" height="141" alt="Image" src="https://github.com/user-attachments/assets/e5c4681f-c2ca-4626-823e-bd85b029e775" />
<img width="273" height="182" alt="Image" src="https://github.com/user-attachments/assets/f6788be2-a3ac-438a-8e02-eea18b08816c" />
My comment above mentioned that browser instances have an
isLocalproperty in the list that Claude sees, so I figured I could use that instead of the name to target the right machine.But no! Actual quote from Claude in my current session:
So
isLocalis apparently not an indicator of whether the Chrome instance is on the same machine as Claude code, at least not reliably.Please, I hate that.
<img width="1366" height="302" alt="Image" src="https://github.com/user-attachments/assets/bac2616c-b0a6-4bd0-9be1-25291e3846f0" />
I named the browser, but it doesn't affect this select at all.
+1, with a concrete confirmation of this exact failure mode. macOS, Claude Code desktop app, two Chrome profiles.
I've named both browsers through the extension's Connect screen more than once — because each time, the agent's browser picker still showed me only "Browser 1" / "Browser 2", so I assumed I'd done it wrong and redid it. Per this issue, that's exactly expected: the extension stores my name, but list_connected_browsers hands the model generic positional labels, so my names can never surface in the picker the agent shows me. I was re-doing a step that's designed not to reach me.
The privacy framing doesn't hold up in my case either: it's my own label, on my own machines, that I typed specifically so I could tell the two apart. Hiding it from the model doesn't protect me from anything — it removes the one thing that would let me (or the agent) pick the right browser. And because my two profiles are two different logged-in identities, "guess by UUID" is a wrong-account risk, not just a UX annoyance.
An opt-in to pass the user-assigned name through (as you propose) would fully solve it. Thanks for the extension — the multi-profile case is really the one rough edge.