[Remote Control] Inbound cloud-message delivery silently dead on second machine: per-account Cowork registration conflict (409) is never surfaced, behind a bridge-state.json bootstrap catch-22

Environment

• Windows 11 Pro (both machines), Claude Desktop app 1.40609.0, Claude Code CLI 2.1.247–2.1.250
• Same claude.ai account (Max) on two machines: Machine A (working) and Machine B (broken)
• claude doctor clean on Machine B; no proxy, no ANTHROPIC_API_KEY, no telemetry-disable env vars

Summary

On a two-machine account, messages queued with claude -p "<msg>" --cloud <session_01…> deliver into live desktop-session panes on Machine A within seconds, but NEVER deliver on Machine B — no error, no log line, nothing. Root cause chain (established over ~2 days of testing, full timeline below):

1. The desktop sessions-bridge (the component that drains cloud-queued messages into local panes) only initializes if %APPDATA%\Claude\bridge-state.json already contains userConsented: true for the org:account — but that file is normally only written by the bridge's own start-up. A machine that loses the file (e.g. app reinstall) can never re-create it through any user-reachable path. Settings toggle off/on, full app restarts, /remote-control, and fresh-session creation were all tried; none mint the file. (Related: #86084.)
2. Once the file was hand-seeded with the minimal {enabled: true, userConsented: true} object, the bridge initialized for the first time and immediately surfaced the real, previously-invisible blockers:

• Cowork OAuth stale-session (session_stale_relogin); parking bridge until re-login: Session is not fresh enough to grant elevated access. — cleared by signing out/in of the desktop app.
• Then, decisively: Registration conflict (409): A Cowork agent is already registered on <Machine A>. Disconnect it there before registering this device.

1. So inbound cloud-drain registration is a one-per-account singleton. Machine A registered first and works; Machine B can never receive cloud-queued messages while Machine A holds the slot. None of this is ever shown to the user — without the hand-seeded file the app fails 100% silently, and the drain simply doesn't happen.

Meanwhile, messages typed into the session's claude.ai/code web page DO deliver into Machine B's pane (live socket path), which is how we confirmed the rest of the pipeline is healthy.

Repro (condensed)

1. Two Windows machines, one account, desktop app + Remote Control both apparently working ("Enabling remote control for session …", bridge_state: connected in main.log on both).
2. From Machine A: claude -p "hello" --cloud <machine-B-session-id> → CLI reports "Sent to cloud session."
3. Machine B: message never prints; no queue-operation enqueue record in the session transcript; no error anywhere.
4. Machine B has no %APPDATA%\Claude\bridge-state.json; Machine A has one (created at its most recent session start). Machine B's log contains no [sessions-bridge] Initializing bridge / Registering environment lines, ever.
5. Seed the minimal file on Machine B, restart app → bridge finally initializes → stale-login park → re-login → 409 conflict naming Machine A.

Expected

• Either multi-machine inbound delivery works, or the limitation is surfaced: the 409 (and the stale-login park) should be shown in the UI, and the consent record should be creatable without hand-editing app state.
• At minimum: a machine whose bridge cannot start should log why at startup instead of nothing.

Log excerpts (Machine B, after seeding the file)

10:13:04 [info] [sessions-bridge] Initializing bridge { oauthEnv: 'production', apiHost: 'https://api.anthropic.com', ... }
10:13:04 [info] [sessions-bridge] Registering environment (fresh)...
10:13:04 [warn] [sessions-bridge] Cowork OAuth stale-session (session_stale_relogin); parking bridge until re-login: Session is not fresh enough to grant elevated access. Sign in again to continue.
-- after desktop re-login --
10:15:30 [info] [sessions-bridge] sessionKey rotated; restarting bridge after session_stale_relogin park
10:15:30 [info] [sessions-bridge] Registering environment (fresh)...
10:15:31 [error] [sessions-bridge] Registration conflict (409): Registration: Conflict (409): A Cowork agent is already registered on <Machine A>. Disconnect it there before registering this device. [request-id: req_011CeZ5EgCn5qy82MWFjDxA7]

Before seeding the file, none of these lines ever appear — the bridge never initializes and nothing is logged.

Related issues

• #86084 — enabled state never persisted to bridge-state.json (this report adds the bootstrap catch-22 mechanism and the reinstall-loses-file-forever consequence)
• #45946 — cloud messages never dispatched into local CLI pane (this report adds the root cause on multi-machine accounts: no bridge registration on the receiver)
• #86014 / #80311 — cross-machine session SendMessage success-but-no-delivery (reproduced here too: 8 sends, 8 success reports, 0 deliveries, transcript-verified both directions)
• #87777 / #69543 — session-level Remote Control enable skipped after app restart until first turn or manual /remote-control (reproduced)

Notes

• Verified delivery by the receiver's transcript (queue-operation enqueue records), never by sender success reports.
• Machine B previously had a working bridge-state.json under an older install (April 2026); the app reinstall lost it, which is what stranded the machine permanently.