[BUG] Claude in Chrome with multiple extension instances: stale devices, unstable browser labels, misrouted calls, generic timeouts
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: Claude Code 2.1.289, macOS 27.0 (26A428), Claude extension 1.0.98. Browsers: Dia 1.51.1 (3 profiles, extension in each) and Google Chrome 154.0.8037.98 (2 profiles, extension in each), all on one machine, same claude.ai account.
I know Dia isn't officially supported. Most of the issues below are on the Claude in Chrome side and would apply to any setup with several extension instances (e.g. multi-profile Chrome). The Dia-specific tab bug has been reported to The Browser Company separately.
1. Stale device registrations stay in list_connected_browsers
Each extension restart (or browser restart) can register a new deviceId, and the old one stays listed. Selecting a stale entry times out instead of failing fast.
- 7 entries were listed for 5 actual extension instances.
- One ID (
41e62e24…) disappeared, reappeared with a freshconnectedAt, thenselect_browseron it returnedNo connected browser has deviceId …seconds later.
2. "Browser N" labels are unstable and don't match across calls
list_connected_browsersrenumbers "Browser N" on every call.select_browserconfirms a different number than the list just showed (e.g. the list showedba521368…as "Browser 5";select_browseron it confirmedSelected browser "Browser 3").- The names given in
switch_browser("Dia - Pro", "Dia - Work") show up in theswitch_browserresult but not inlist_connected_browsers, which still says "Browser N". - Once,
switch_browserreported "Dia - Pro" but tool calls still went to the previously selected (Perso) device.
3. Extension pairs but never answers tool calls → generic timeout
After a browser restart, two extension instances accepted a switch_browser pairing request (the user clicked Connect, the name was confirmed), but every tool call then timed out with the "did not respond in time / computer may be asleep" message. In one case the tab was actually created in the browser; only the reply never arrived.
4. "Not in Claude's tab group" for a tab that is visibly in the group
With a non-primary Dia profile, tabs_context_mcp {createIfEmpty: true} returned a tab and group ID; both test tabs were visibly inside the Claude tab group, but every call right after said Tab 1220558891 is not in Claude's tab group for this session., and tabs_create_mcp returned a new tab with an empty "Available tabs" list. Root cause is Dia (its tab query API returns nothing for that profile), but the extension could detect the inconsistency ("I just created this tab in this group, yet a query of the group returns 0 tabs") and report it, instead of failing on every later call.
What Should Happen?
- Stale registrations expire or are replaced when an extension re-registers, and selecting one fails immediately with a clear "browser is offline" error.
- Stable browser labels; the user-given name (from
switch_browser) shown everywhere, includinglist_connected_browsers; the confirmed selection always matches where calls are routed. - A distinct error when the extension is reachable but the command failed or hung inside the extension (with the underlying error if any), rather than the "computer may be asleep" message.
- The extension detects and reports the inconsistency when a tab it just created in its group isn't returned by a group query, instead of failing every subsequent call.
Error Messages/Logs
No connected browser has deviceId …
The "tabs_context_mcp" tool did not respond in time. If Chrome is on another computer…
Tab 1220558891 is not in Claude's tab group for this session.
Steps to Reproduce
- Install the Claude extension in several browser profiles on one machine (e.g. 2 Chrome profiles + 3 Dia profiles), all signed into the same claude.ai account.
- Restart one browser / extension a few times.
- Call
list_connected_browsers→ more entries than actual instances (7 for 5); labels "Browser N" change between calls. - Call
select_browseron an entry from the list → confirmation shows a different "Browser N"; on a stale ID → timeout orNo connected browser has deviceId …. - Call
switch_browser, click Connect in a profile and give it a name → name appears in the result but not inlist_connected_browsers; occasionally calls still route to the previous device. - After a browser restart, pair via
switch_browseragain → pairing confirmed, buttabs_context_mcptimes out with the generic "did not respond in time" error (the tab may actually be created). - (Dia, non-primary profile)
tabs_context_mcp {createIfEmpty: true}→ returns tab + group; next call on that tab → "not in Claude's tab group".
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.289 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Xterm
Additional Information
Nice to have
- A way to remove/forget dead devices from Claude Code (
list_connected_browsershas no cleanup). - Show the browser / profile name (or profile email) in
list_connected_browsers, so several instances on the same machine can be told apart withoutswitch_browser.
What worked
- Google Chrome, 2 profiles: create/navigate worked in both, no window focusing needed.
- Dia primary profile: fully working.
switch_browser(click Connect in the right profile) was the only reliable way to identify which deviceId belongs to which profile.
Environment: Claude extension 1.0.98; Dia 1.51.1; Google Chrome 154.0.8037.98; macOS 27.0 (26A428).