[BUG] Chrome extension bridge: account-level single "active worker" (code 4090) evicts idle/scheduled browser sessions — regression since ~Jul 1 2026

Summary

Since a desktop-app update around June 30 – July 2, 2026, the Claude-in-Chrome extension bridge enforces a single "active worker" per account. Any newer session that connects evicts the session currently holding the bridge with:

[remote-control] bridge_state: failed - Transport closed: this connection is no longer the active worker for the session (code 4090)

Because the bridge is keyed by account (the URL is wss://bridge.claudeusercontent.com/chrome/{ACCOUNT_ID}) — not per-window — this one slot is shared across every desktop window, every claude.ai tab, and every paired device. Combined with remote-control auto-enabling on every session (rcAutoEnable: enable=true), sessions now continuously steal the bridge from each other. Browser-tool sessions that used to sit idle and keep working (e.g. an unattended scheduled task at night) now silently lose their mcp__Claude_in_Chrome__* tools.

This is a regression. The single-active-worker arbitration did not exist before July 1.

Evidence (from the desktop app's own main.log)

Occurrence counts of the eviction message and of remote-control auto-enable, across the app's rotated logs:

| Log window | active worker (code 4090) evictions | rcAutoEnable |
|---|---|---|
| May 11 – Jun 4, 2026 | 0 | 0 |
| Jun 4 – Jul 6, 2026 | 22 | 26 |

• First eviction ever recorded: 2026-07-01 05:23:51 (an overnight time — exactly when unattended browser sessions run).
• rcAutoEnable first appears 2026-07-02.
• Correlated changes in the same window: claude-in-chrome bridge logging first appears 2026-06-30; a persistent bridge-state.json was created 2026-07-02.

Impact

• Scheduled / unattended browser tasks break silently. A scan that ran fine for months with Chrome + the extension idle now spawns without browser tools, because a background/warming session or another device grabs the account-wide bridge slot.
• Multi-window and multi-device users lose browser tools unpredictably — opening a second window or leaving a claude.ai tab open on another machine evicts the working session.
• No mid-session recovery. Once a session starts without the bridge, clicking the extension icon or foregrounding Chrome does not attach the tools; the MCP server binds only when that session is the active worker at startup.
• No user-facing setting to opt out. There is no remote-control / bridge toggle in the desktop Settings UI, so users can't prevent auto-enrollment.

Environment

• Claude desktop app (Windows, MSIX): 1.18286.0.0
• Bundled claude-code: 2.1.197
• OS: Windows 11 (26200)
• Chrome + Claude browser extension installed, paired, enabled

Steps to reproduce

1. Sign in to the Claude desktop app with the Chrome extension paired and browser tools working in a session.
2. Open a second Claude session (another window, a claude.ai tab, or a second paired device) so it auto-enables remote control.
3. Observe the first session's browser tools stop working; main.log shows code 4090 – no longer the active worker for the session.

Expected

Either (a) the browser bridge should support the session that legitimately needs it without an unrelated background/other-device session evicting it, or (b) there should be a per-session/per-device setting to pin or opt out of remote-control auto-enrollment, so an unattended browser session can reliably hold the bridge.

Actual

Every newer session silently steals the single account-wide bridge slot; the evicted session keeps running but with no mcp__Claude_in_Chrome__* tools and no recovery path.

Notes

Possibly related to the extension service-worker reconnection bugs (#16350, #46514), but the root cause here is distinct: it is the new account-level single-active-worker arbitration, not local native-messaging suspension. All account/org/device identifiers and tokens have been redacted from the log excerpts above.