[BUG] Claude in Chrome: select_browser is account-wide, so one session silently moves every other session's browser

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)
• [ ] I am using the latest version of Claude Code

Note on the third box: I tested this on 2.1.231 and 2.1.236 is current. I haven't retested on 2.1.236, because reproducing it means disrupting six live Chrome profiles and every running session. Flagging that honestly rather than ticking the box.

Related, but not the same bug: #74902 reports the unstable positional Browser N label, and #77239 reports targeting as nondeterministic across profiles and windows. Both describe the behavior as random or unstable. I think this issue is the mechanism underneath both of them, and it isn't random.

What's Wrong?

select_browser applies to the whole account, not to the calling session. When one session selects a browser, every other session on the same account is moved to it. The other sessions are not told. Their tab group is destroyed and their next navigate lands in the newly selected profile.

I run six Chrome profiles on one Windows machine, each signed into a different account, with the extension connected in all six. Several Claude Code sessions run at once. The practical effect is that a session doing work in one logged-in account can be silently relocated into another account's profile by an unrelated session, and it will keep working as if nothing happened.

This is deterministic, not intermittent. The session that selects last wins, every time.

What Should Happen?

A browser selection should be scoped to the session that made it. A second session selecting a different browser should not move the first one.

Failing that, the first session should at minimum be able to find out that it happened. There is currently no read-only call that returns the deviceId the calling session is pointed at. list_connected_browsers returns the list of connected browsers, not my own current selection. select_browser's confirmation label is a position index rather than an identifier, so it says where the browser sits in a ranking, not which profile I got.

A get_current_browser returning the active deviceId for the calling session would let a session detect this in one call. #74902 asks for the same thing from a different direction.

Error Messages/Logs

No tab group exists for this session yet. Call tabs_context_mcp with createIfEmpty: true first

That message is not itself the bug, but it is worth noting that it is ambiguous. A session that never created a group and a session whose group was destroyed by another session's selection both end up without a group, and the two states cannot be told apart from the messages alone. So an absent tab group cannot be used as a signal that this happened.

Steps to Reproduce

1. Install and connect the Claude in Chrome extension in two different Chrome profiles, A and B, on the same machine and the same Claude account.
2. Start two Claude Code sessions. Call them session 1 and session 2.
3. In session 1, call list_connected_browsers, then select_browser with profile A's deviceId. Navigate to any URL and confirm it loads.
4. In session 2, call select_browser with profile B's deviceId.
5. Back in session 1, without re-selecting, navigate to a distinctive URL, for example https://example.com/?marker=abc123.
6. Session 1 reports a normal successful navigation.

Observed: the marker URL is recorded in profile B's history, not profile A's. Session 1 was never told its browser changed.

To verify where the navigation actually landed, copy each profile's Chrome History file (it is a SQLite database, and it must be copied because Chrome holds it open) and query the urls table for the marker. That is the only method I found that gives ground truth, precisely because no API call reports the session's own current browser.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.231

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Sessions run in the Claude Code desktop app on Windows 11, not in a terminal, which is why I picked Other above.

Two further observations from the same testing, included because they bear on this bug rather than as separate reports:

1. The Browser N label appears to be a position index ordered by connectedAt, newest first, so it renumbers whenever any profile reconnects. I am inferring that ordering from repeated readings, not from documentation, so treat it as a hypothesis. Separately, profiles that had been reporting real names lost them mid-life while connectedAt stayed byte-identical, so nothing reconnected and the name went anyway. #74902 covers the naming behavior in more detail.

1. switch_browser cannot be evaluated in a working setup. It broadcasts to every connected extension and drops the others, so testing whether a name typed there persists means disrupting every profile and every running session at once. That matters because it is the one path that might work around the naming problem.

I mitigated this locally with a PreToolUse hook that refuses a browser call when another of my sessions is holding one, releasing on a short idle timeout. It works, which suggests session-scoped binding is not hard to express. It only covers sessions on one machine with that hook installed, so it is a workaround and not a fix.