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

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

1. Populate name in list_connected_browsers from the same source switch_browser reports from.
2. 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.

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