[BUG] claude-in-chrome MCP can't distinguish two Chrome profiles — `list_connected_browsers` returns unstable generic "Browser 1/2" names, forcing constant disambiguation and wrong-profile risk
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Environment
- OS: Windows 11 Pro (10.0.26200)
- Claude Code version: 2.1.160
- Model: Claude Opus 4.8
- Browser: Google Chrome 149.0.7827.197 with the Claude extension installed in two separate Chrome profiles (one personal, one work). Both extensions are connected at the same time. Extension version:
<paste from chrome://extensions → Claude extension → Details>
Summary
When the Claude Chrome extension is installed and connected in two different Chrome profiles simultaneously, the claude-in-chrome MCP browser tools cannot reliably tell the two browsers apart. list_connected_browsers returns only generic, positionally-assigned names ("Browser 1" / "Browser 2") that are not stable across calls and are not tied to the deviceId or the Chrome profile. As a result the agent is forced to prompt the user to pick a browser on essentially every browser action — or risk silently selecting the wrong profile, which is dangerous for profile-scoped work (wrong logged-in account/session).
Steps to reproduce
- Install the Claude Chrome extension in two different Chrome profiles (e.g. a personal profile and a work profile).
- Connect the extension in both profiles.
- From an agent (Claude Code), call
list_connected_browsers. - Call
select_browser(<deviceId>)for one deviceId, then call it again a few minutes later for the same deviceId. - Try
switch_browserand note the name it reports vs. whatlist_connected_browsersshows. - Try to identify the Chrome profile (e.g. navigate the extension to
chrome://version).
Observed behavior
list_connected_browsersreturns only generic names:
``json``
[{"deviceId":"<uuid-A>","name":"Browser 1","osPlatform":"Windows","isLocal":true},
{"deviceId":"<uuid-B>","name":"Browser 2","osPlatform":"Windows","isLocal":true}]
The user-assigned/profile names are never exposed here.
- The "Browser N" label is unstable and positional.
select_browser("<uuid-A>")returnedConnected to browser "Browser 1"on one call andConnected to browser "Browser 2"a few minutes later — the same deviceId reported a different label. So the label is not tied to the deviceId or the profile. switch_browser(interactive connect) once reportedConnected to browser "Astriata.com"— i.e. a real, meaningful name does exist — but that name never appears inlist_connected_browsersand does not persist to subsequent calls.- There is no programmatic way to map a deviceId → Chrome profile / account.
chrome://version(which would reveal the profile path) is not loadable via the extension — navigating to it bounces tochrome://newtab/. The default Google account is identical across both profiles, so account identity doesn't distinguish them either. - When connecting / opening a tab, connect prompts and/or the new tab appeared in both profile windows near-simultaneously, making manual disambiguation confusing.
- Net effect: the tool forces a "choose Browser 1 or 2" prompt on nearly every browser action, and the only stable handle (deviceId) is opaque and not mappable to a profile — so there is no reliable, non-interactive way to always target the correct profile.
Expected behavior
list_connected_browsers should return a stable, human-meaningful, profile-bound identifier for each connected browser — ideally the user-assigned name (the one switch_browser already knows) and/or the Chrome profile display name + profile directory — that is:
- consistent across calls, and
- 1:1 with a stable deviceId,
so an agent can auto-select the correct profile deterministically (e.g. select_browser by name/profile) without prompting and without risk of picking the wrong profile.
Suggested fixes
- Surface the user-assigned browser name (the one
switch_browserdisplays) and/or the Chrome profile display name + profile directory inlist_connected_browsers. - Make the returned name stable and bound to the deviceId — stop using a positional "Browser N" label that shuffles between calls.
- Persist the name set during
switch_browserso it appears in laterlist_connected_browsers/select_browserresults. - Allow
select_browser(or a newget_current_browser/ profile-info call) to resolve/report the Chrome profile, so agents can map project → profile deterministically.
Impact
Multi-profile setups are common (people separate work/personal, or per-client accounts). Today this makes those setups painful and error-prone: constant disambiguation prompts interrupt every browser task, and there's a real risk of acting in the wrong profile (wrong logged-in account/session). A stable profile-bound identifier would fully resolve it.
What Should Happen?
Expected behavior
list_connected_browsers should return a stable, human-meaningful, profile-bound identifier for each connected browser — ideally the user-assigned name (the one switch_browser already knows) and/or the Chrome profile display name + profile directory — that is:
- consistent across calls, and
- 1:1 with a stable deviceId,
so an agent can auto-select the correct profile deterministically (e.g. select_browser by name/profile) without prompting and without risk of picking the wrong profile.
Error Messages/Logs
Steps to Reproduce
Steps to reproduce
- Install the Claude Chrome extension in two different Chrome profiles (e.g. a personal profile and a work profile).
- Connect the extension in both profiles.
- From an agent (Claude Code), call
list_connected_browsers. - Call
select_browser(<deviceId>)for one deviceId, then call it again a few minutes later for the same deviceId. - Try
switch_browserand note the name it reports vs. whatlist_connected_browsersshows. - Try to identify the Chrome profile (e.g. navigate the extension to
chrome://version).
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.160
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Confirming this on macOS as well (this is currently labeled
platform:windows, but it reproduces identically) — Claude Code desktop app, two Chrome profiles each with the extension connected.list_connected_browsersreturns exactly the generic labels you describe, with no profile/name info:The two
connectedAttimestamps came back 4 ms apart, so the positional "Browser 1/2" ordering is effectively a coin flip on each connection — there's nothing stable to anchor to.Why this is a genuine footgun rather than a papercut, in my setup: the two profiles are two different logged-in identities — one is an admin/primary account (including a primary YouTube channel), the other a secondary account (a different channel). Picking the wrong "Browser N" means the agent could post or act under the wrong identity. So it has to stop and ask me to disambiguate on nearly every browser action — and I can't answer reliably either, because all the picker shows me is "Browser 1 / Browser 2" and a raw UUID.
I've also tried the extension's built-in naming feature repeatedly, and it doesn't help — the names never reach the picker the model shows me (see #70542: the user-assigned names are anonymized before they're passed to the model). Net result: at selection time, neither the agent nor I have any reliable way to tell the two profiles apart.
The fix that would fully solve it: expose a stable, profile-tied identifier through
list_connected_browsers— the user-assigned name, or the Chrome profile name/email — anchored to thedeviceId.Confirming on macOS (Claude Code desktop, two Chrome profiles) and adding one data point: names assigned during the
switch_browserconnect flow don't persist either.Sequence from today, all within one working session:
list_connected_browsersshowed generic "Browser 1" / "Browser 2".switch_browser; the user clicked Connect in the intended profile and named it there. Tool result confirmed:Connected to browser "<name>".list_connected_browsersagain returned "Browser 1" / "Browser 2" with the same two deviceIds. The user-assigned name was gone.So even doing the naming work doesn't stick, and every disambiguation restarts from zero. Since deviceId is stable across all of this, persisting the user's name against the deviceId would fix both the instability described in this issue and the re-prompting: a previously named browser could be
select_browser'd directly without another interactive round-trip — which matters a lot for unattended loops, where the mandated ask-the-user-every-time flow with two browsers connected is a hard blocker.Corroborating this on a different OS and a later version — still present a month on.
Environment: macOS (Darwin 25.5.0), Claude Code CLI, Claude Opus 5, two local Chrome profiles with the extension connected in both.
list_connected_browsersreturns:The two profiles are signed in to different accounts, and only one holds the session the task needed.
The detail I'd add to the original report:
switch_browserexplicitly offers to let the user name the browser at connect time, and the user does name it. That name is not whatlist_connected_browsersgives back — it returns positionalBrowser 1/Browser 2instead. So the product asks for a label, keeps it somewhere, and then hands the agent something else. From the user's side the naming step reads as pointless, which is its own source of frustration on top of the ambiguity.A consequence beyond wrong-profile risk: the disambiguation prompt is unanswerable when the user is away from their machine. That happened to us today. The remaining work was a two-click change in a web dashboard — fully automatable, and blocked solely on "which of these two identically-named browsers is yours?" with nobody at the keyboard to answer. A cosmetic naming gap turns into a hard block on unattended or remote work.
What would fix it for us: have
list_connected_browsersreturn the user-supplied name, falling back to the Chrome profile name, then to positional. Stable identity bound todeviceIdis the deeper fix, but the display string is what makes the picker answerable at all — and that one looks like plumbing a value you already have.