[BUG] Claude in Chrome with multiple extension instances: stale devices, unstable browser labels, misrouted calls, generic timeouts

Status Open
Reported on v2.1.289
Maintainer reply None cached
Activity 0 comments · opened Oct 4, 2026

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 fresh connectedAt, then select_browser on it returned No connected browser has deviceId … seconds later.

2. "Browser N" labels are unstable and don't match across calls

  • list_connected_browsers renumbers "Browser N" on every call.
  • select_browser confirms a different number than the list just showed (e.g. the list showed ba521368… as "Browser 5"; select_browser on it confirmed Selected browser "Browser 3").
  • The names given in switch_browser ("Dia - Pro", "Dia - Work") show up in the switch_browser result but not in list_connected_browsers, which still says "Browser N".
  • Once, switch_browser reported "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?

  1. Stale registrations expire or are replaced when an extension re-registers, and selecting one fails immediately with a clear "browser is offline" error.
  2. Stable browser labels; the user-given name (from switch_browser) shown everywhere, including list_connected_browsers; the confirmed selection always matches where calls are routed.
  3. 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.
  4. 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

  1. 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.
  2. Restart one browser / extension a few times.
  3. Call list_connected_browsers → more entries than actual instances (7 for 5); labels "Browser N" change between calls.
  4. Call select_browser on an entry from the list → confirmation shows a different "Browser N"; on a stale ID → timeout or No connected browser has deviceId ….
  5. Call switch_browser, click Connect in a profile and give it a name → name appears in the result but not in list_connected_browsers; occasionally calls still route to the previous device.
  6. After a browser restart, pair via switch_browser again → pairing confirmed, but tabs_context_mcp times out with the generic "did not respond in time" error (the tab may actually be created).
  7. (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_browsers has 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 without switch_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).

View original on GitHub ↗