Claude in Chrome: `list_connected_browsers` returns generic "Browser 1/2" instead of the names users assign, making the multi-browser picker unusable

Status Open

Maintainer reply None cached

Activity 5 comments · opened Aug 27, 2026

Summary

When more than one Chrome instance is connected, Claude is required to ask the user which browser to
drive. The only identifying information available to Claude is list_connected_browsers, and its
name field returns a generic placeholder — "Browser 1", "Browser 2" — not the name the user
assigned to that browser. The resulting question is unanswerable by the user without guesswork.

What happens

mcp__claude-in-chrome__list_connected_browsers returns:

[{"deviceId":"35194b19-3f2f-4eaa-a327-f7a70e817136","name":"Browser 1",
  "osPlatform":"Windows","connectedAt":1787846006732,"isLocal":true},
 {"deviceId":"2bbdd111-0ea9-453a-bd8e-99b9c6861ab8","name":"Browser 2",
  "osPlatform":"Windows","connectedAt":1787846005179,"isLocal":true}]

Every field that could discriminate is unhelpful in the common case:

| field | value | useful? |
|---|---|---|
| name | "Browser 1" / "Browser 2" | ❌ generic placeholder, not the user's assigned name |
| osPlatform | Windows for both | ❌ |
| isLocal | true for both | ❌ same machine |
| connectedAt | 1.5 seconds apart | ❌ |
| deviceId | raw UUID | ❌ meaningless to a human |

The tool-use instruction attached to the error/listing then says to present the choice
"using the display name as the label, and include the deviceId in parentheses." Following that
literally produces:

1. Browser 1 (Windows) — deviceId: 35194b19-3f2f-4eaa-a327-f7a70e817136 2. Browser 2 (Windows) — deviceId: 2bbdd111-0ea9-453a-bd8e-99b9c6861ab8

which is exactly what the user cannot answer. Verbatim user feedback that prompted this report:

"When you ask me to pick a Chrome, can you tell me the names I've assigned the Chrome instances? The ID numbers you give me aren't useful."

Evidence the names DO exist

The names are clearly held somewhere — they just aren't returned by the listing.
mcp__claude-in-chrome__switch_browser returns:

Connected to browser "Home Chrome".

So "Home Chrome" is a real, user-assigned name that the extension knows and can report. It is
simply absent from list_connected_browsers, which is the one call made before the user has to
choose.

Expected

list_connected_browsers should return the user-assigned browser name in name (or add a
displayName / userAssignedName field alongside it), so the picker can offer:

1. Home Chrome (Windows) 2. Work Chrome (Windows)

Impact

The multi-browser picker is effectively a coin flip whenever a user has two Chromes connected.
Picking wrong drives the wrong browser — for signed-in work (the case here was an authenticated

research session) that means acting in the wrong profile.

The only reliable workaround is to skip select_browser entirely and always call

switch_browser, which prompts every extension and makes the user physically identify the window.
That works, but it costs a round trip and a context switch on every reconnect, and it makes the
documented select_browser path dead weight.

Suggested fix

Populate name in list_connected_browsers from the same source switch_browser reports from.
If a browser genuinely has no user-assigned name, fall back to something a human can act on —

e.g. the Chrome profile name, or the active tab's origin — rather than an ordinal.

Consider relaxing the tool-use instruction's "include the deviceId in parentheses" so raw UUIDs

are not pushed into user-facing labels.

Environment

Claude Code on Windows 11 Pro (26200)
Two Chrome instances, same machine, both with the extension installed and connected
Observed 2026-08-27

View original on GitHub ↗

4 Comments

Fuduntu · 1 month ago

Same symptom on Windows, with two findings that may narrow it down.

Environment: Claude desktop app 1.40609.1 (MSIX) with bundled Claude Code 2.1.255, Windows 11 Pro 25H2 (build 26200). Claude in Chrome 1.0.90 in both Google Chrome 152.0.7977.75 and Microsoft Edge 152.0.4191.53, same account, same machine.

1. The "Browser N" label is assigned per connection, not per device. From %LOCALAPPDATA%\Claude\Logs\main.log, every [Chrome Extension MCP] Paired with line over nine days (deviceIds shortened):

2026-08-24 10:34:12  Browser 1  380b9d1e
2026-08-24 10:34:28  Browser 2  b884bad1
2026-08-26 15:59:42  Browser 1  b884bad1
2026-08-28 11:55:56  Browser 2  b884bad1
2026-08-28 11:57:44  Browser 1  380b9d1e
2026-08-29 17:15:10  Browser 2  b884bad1
2026-08-29 17:21:52  Browser 1  380b9d1e
2026-08-29 17:23:12  Browser 1  380b9d1e
2026-08-29 17:30:24  Browser 2  b884bad1
2026-08-29 17:31:07  Browser 1  380b9d1e
2026-08-31 11:35:42  Browser 1  b884bad1
2026-08-31 12:42:45  Browser 2  380b9d1e
2026-08-31 16:25:29  Browser 2  b884bad1
2026-09-01 21:38:41  Browser 1  380b9d1e

The same deviceId is "Browser 1" one day and "Browser 2" the next, so even a user who has learned which label is which is guessing.

2. The user-assigned name is persisted client-side and never reaches the list. In each browser's profile, Local Extension Settings\fcoeoabgfenejglbffodgkkbkcdhcgfn\*.ldb holds bridgeDeviceId next to displayName: "Chrome browser" in Chrome and "Edge browser personal" in Edge, the names typed in the Connect flow. list_connected_browsers still returns "Browser 1" / "Browser 2" for those same IDs. So the rename is stored locally, and the account-level device list never receives it (or never reads it). Reading that storage was the only way to join a deviceId to a browser.

What is stable: the two bridgeDeviceIds have not changed across those nine days on this machine (unlike the rotation described in #78096), and select_browser with the ID pairs immediately without prompting. The workaround is a hard-coded deviceId-to-browser table in a project instruction file, which is where #78096 landed too.

Exact tool output today:

[{"deviceId":"380b9d1e-1176-40e6-ace3-0140ace2757f","name":"Browser 1","osPlatform":"Windows","connectedAt":1788315762732,"isLocal":true},
 {"deviceId":"b884bad1-ecd1-4666-b7f2-fc1de8e8e67b","name":"Browser 2","osPlatform":"Windows","connectedAt":1788313991273,"isLocal":true}]

Also sent to support@anthropic.com on 2026-09-01. Related: #89302, #78096, #72677 (closed stale).

dzg · 15 days ago

I have this problem on Mac with 3 browsers, same identifier com.brave.Browser but different paths.

Drives me absolutely bonkers.

The prefs are absolutely useless ... cannot identify, cannot rename. Why bother?

dzg · 15 days ago

Reproduces identically on macOS — not Windows-specific.

Environment: macOS 26 (Apple M1 Max), Claude desktop app <VERSION> with bundled Claude Code, Claude in Chrome <VERSION> running in Brave. Three instances connected across two Brave installs (/Applications/Brave Browser.app and /Applications/Brave Shivoo.app, both bundle id com.brave.Browser). Each was named in the Connect flow.

list_connected_browsers today:

[{"deviceId":"85546e9a-…","name":"Browser 1","osPlatform":"macOS","isLocal":true,"onThisComputer":true},
 {"deviceId":"9cffb711-…","name":"Browser 2","osPlatform":"macOS","isLocal":true,"onThisComputer":true},
 {"deviceId":"3a73db59-…","name":"Browser 3","osPlatform":"macOS","isLocal":true,"onThisComputer":true}]

Same generic labels, none of the assigned names. Settings › Browser use shows the same "Browser 1/2/3" with no rename option. Net effect: every fresh session opens with a "which browser?" prompt that can't be answered without guessing.

Could this get platform:macos added (or the platform label dropped)?

dzg · 15 days ago

Temporary workaround here: https://github.com/anthropics/claude-code/issues/74902#issuecomment-5917621810

Showing cached comments. Read the full discussion on GitHub ↗

Claude in Chrome: `list_connected_browsers` returns generic "Browser 1/2" instead of the names users assign, making the multi-browser picker unusable

Summary

What happens

Evidence the names DO exist

Expected

Impact

Suggested fix

Environment

4 Comments

Related Claude Code issues

Browse by topic