[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

1. Install the Claude Chrome extension in two different Chrome profiles (e.g. a personal profile and a work profile).
2. Connect the extension in both profiles.
3. From an agent (Claude Code), call list_connected_browsers.
4. Call select_browser(<deviceId>) for one deviceId, then call it again a few minutes later for the same deviceId.
5. Try switch_browser and note the name it reports vs. what list_connected_browsers shows.
6. Try to identify the Chrome profile (e.g. navigate the extension to chrome://version).

Observed behavior

1. list_connected_browsers returns 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.

1. The "Browser N" label is unstable and positional. select_browser("<uuid-A>") returned Connected to browser "Browser 1" on one call and Connected 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.
2. switch_browser (interactive connect) once reported Connected to browser "Astriata.com" — i.e. a real, meaningful name does exist — but that name never appears in list_connected_browsers and does not persist to subsequent calls.
3. 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 to chrome://newtab/. The default Google account is identical across both profiles, so account identity doesn't distinguish them either.
4. When connecting / opening a tab, connect prompts and/or the new tab appeared in both profile windows near-simultaneously, making manual disambiguation confusing.
5. 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_browser displays) and/or the Chrome profile display name + profile directory in list_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_browser so it appears in later list_connected_browsers/select_browser results.
• Allow select_browser (or a new get_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

1. Install the Claude Chrome extension in two different Chrome profiles (e.g. a personal profile and a work profile).
2. Connect the extension in both profiles.
3. From an agent (Claude Code), call list_connected_browsers.
4. Call select_browser(<deviceId>) for one deviceId, then call it again a few minutes later for the same deviceId.
5. Try switch_browser and note the name it reports vs. what list_connected_browsers shows.
6. 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_