[BUG] Cowork browser picker shows generic "Browser 1/2/3" instead of configured browser names

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?

In Cowork (Claude Desktop), the browser picker used to show the custom names set during pairing (e.g. "MyBrowser-A", "MyBrowser-B"). After a recent update, every connected browser is listed with a generic placeholder — "Browser 1", "Browser 2", "Browser 3" — with no custom names. This makes it impossible to tell browsers apart, forcing an authorization prompt to be broadcast to ALL connected browsers every time.

Root cause evidence (the name isn't deleted, only dropped in the list path):

• list_connected_browsers returns generic names: {"name":"Browser 1"...}, {"name":"Browser 2"...}, {"name":"Browser 3"...}.
• The switch_browser pairing flow still returns the correct custom name — connecting through it reported: Connected to browser "MyBrowser-A".

So the underlying display name is intact and still flows through the pairing path; it's the browser-enumeration/list path that has dropped the display-name field and fallen back to Browser {index}. This looks like a regression in the browser-discovery/relay layer.

Impact: I manage a large number of separate Chrome profiles, each signed into a different Google account. The browser name is the only practical way to distinguish them; numbered placeholders effectively break multi-profile workflows.

What Should Happen?

The browser picker should show each connected browser's configured display name (as the switch_browser pairing flow still does), so multiple browsers/profiles can be told apart at a glance without broadcasting an authorization prompt to every connected browser.

Error Messages/Logs

Steps to Reproduce

1. Connect two or more Chrome browsers via the Claude in Chrome extension, giving each a distinct custom name during pairing (e.g. "MyBrowser-A", "MyBrowser-B").
2. In Cowork (Claude Desktop), trigger an action that requires selecting a browser, so the browser picker/list appears.
3. Observe the picker lists the browsers as "Browser 1", "Browser 2", "Browser 3" instead of their configured names.

Firsthand reproduction from this session:

• list_connected_browsers returned: [{"name":"Browser 1","osPlatform":"macOS"}, {"name":"Browser 2","osPlatform":"Windows"}, {"name":"Browser 3","osPlatform":"macOS"}] — no custom names.
• After choosing "let me pick in Chrome", switch_browser completed with: Connected to browser "MyBrowser-A" — i.e. the real name is still available via the pairing path, just not the list path.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is not the Claude Code CLI. Reported against Claude Desktop (Cowork) + Claude in Chrome extension on macOS. (Happy to add exact Desktop/extension versions if useful.)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Note: this form is tailored to the Claude Code CLI; this bug is in Claude Desktop / Cowork's Chrome browser picker, so CLI-specific fields (Claude Code Version, Terminal/Shell) are marked N/A. Please route to the Cowork / Claude in Chrome team.

• Product: Claude Desktop – Cowork, with the Claude in Chrome extension
• OS: macOS (a connected Windows browser showed the same generic naming)
• Affected surfaces: browser picker / list_connected_browsers
• Not affected: switch_browser pairing flow (still returns the correct custom name)

Business impact: a multi-profile use case with many separate Chrome profiles, each on a different Google account — the custom browser name is the only practical way to distinguish them.