[BUG] macOS Cowork device bridge drops daily for 3+ weeks — bridge_state failed code 4090 "no longer the active worker" + JWT refresh 401 (persists 1.20186.x → 1.24012.11)

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 Desktop (Cowork) on macOS, Apple Silicon
• App 1.24012.11 (Electron 42.7.0) — issue persists across six release lines since onset: 1.20186.x → 1.21459.0/.1/.3 → 1.22209.0 → 1.24012.11
• Single signed-in device; no VPN/proxy; stable network; timestamps below are US Eastern

What happens
Since ~Jul 13, cloud Cowork sessions lose the device bridge to my Mac several times a day, usually while I'm actively using the machine. In-flight sessions report they can't reach my computer, and file staging/commits fail until reconnect (typically 20–90 min unless I restart the app; worst case ~4h of failed retries). The drops also sever GitHub access for cloud sessions mid-task, since credentials and repo worktrees are read through the device mount — and failures cluster between 3–7am ET, repeatedly killing long unattended runs.

Dominant signatures in ~/Library/Logs/Claude/main*.log:

[remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090)
[remote-control] bridge_state: reconnecting — JWT expired — refreshing
[remote-control] bridge_state: failed — JWT refresh failed after 401
[remote-control] bridge_state: failed — Remote credentials fetch failed — see debug log
[remote-control] bridge_state: failed — Session creation failed — see debug log

Representative events (25 failure/reconnect events Jul 18 – Aug 4; ~27 code-4090 failures since Jul 16):

2026-07-19 03:39:52  failed — code 4090
2026-07-20 03:19–11:58  7× reconnecting — JWT expired
2026-07-21 00:32 / 04:39  failed — code 4090
2026-07-23 04:51 / 06:48 / 06:49  failed — code 4090
2026-07-27 09:57  failed — code 4090
2026-08-03 17:59  failed — code 4090
2026-08-04 05:14  failed — code 4090

Timeline / correlation
Disconnect-related log events per day went from ~0 (Jul 2–6) → 184 (Jul 14) → 377 (Jul 16), coinciding with the 1.20186.7 → 1.21459.0 update wave; failures have continued on every active day through 1.24012.11.

Ruled out

• Full sign-out → restart → sign-in (suggested by support Jul 17): completed, no effect — failures resumed Jul 19 03:39
• Clock drift (device within ~1s of NTP) · multi-device conflict (only one device signed in) · VPN (none active) · Wi-Fi faults (zero socket-level errors in two weeks of logs) · Mac sleep (drops occur mid-use; VM shutdowns all graceful) · app crashes (no crash reports) · disk space
• A support ticket opened Jul 17 was closed without the offered engineering escalation; a replacement ticket was opened Aug 4 with the full case file (complete bridge_state history, version timeline, MCP disconnect episodes, memory telemetry) — also available here on request.

Notes
With only one signed-in device, code 4090 ("no longer the active worker") suggests the reconnect path racing itself or server-side worker reassignment rather than a genuine second client.

What Should Happen?

The device bridge stays connected during active use; JWT refresh succeeds (or retries) without dropping the session's active worker; reconnection is transparent to in-flight cloud sessions — no multi-hour windows where the Mac is unreachable and mounted credentials/repos disappear mid-task.

Error Messages/Logs

[remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090)
[remote-control] bridge_state: reconnecting — JWT expired — refreshing
[remote-control] bridge_state: failed — JWT refresh failed after 401
[remote-control] bridge_state: failed — Remote credentials fetch failed — see debug log
[remote-control] bridge_state: failed — Session creation failed — see debug log

Dated failures since the (ineffective) sign-out test, US Eastern:
2026-07-19 03:39:52 failed — code 4090
2026-07-19 16:26:02 failed — code 4090
2026-07-20 03:19:31 / 03:57:58 / 05:03:31 / 05:11:31 / 05:27:15 / 11:19:42 / 11:58:09 reconnecting — JWT expired
2026-07-21 00:32:01 failed — code 4090
2026-07-21 04:39:26 failed — code 4090
2026-07-22 23:31:07 failed — code 4090
2026-07-23 04:51:17 / 06:48:57 / 06:49:03 failed — code 4090
2026-07-27 09:57:51 failed — code 4090
2026-08-03 17:59:16 failed — code 4090
2026-08-04 05:14:04 failed — code 4090

Steps to Reproduce

1. macOS Claude Desktop signed in; start a cloud Cowork session with device folders connected (bridge active).
2. Work normally on the Mac (or leave a long unattended cloud run going overnight).
3. Within hours, [remote-control] bridge_state: failed fires — most often code 4090 — and the cloud session loses the device: file staging/commits fail and mounted credentials/repo worktrees become unreachable mid-task.
4. The bridge self-heals 20–90+ minutes later (worst observed: ~4h of failed retries), or immediately after quitting and reopening the app.

No local trigger identified: happens during active use and idle, across six release lines (1.20186.x → 1.24012.11), and after sign-out/sign-in, clock, VPN, Wi-Fi, sleep, crash, and multi-device causes were each ruled out (details in "What Happened"). Frequency: several times a day since ~Jul 13, 2026.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.20186.1

Claude Code Version

Desktop app 1.24012.11 (Cowork device bridge — not the CLI); VM SDK 2.1.209

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is the Claude DESKTOP app (Cowork cloud-session ↔ device bridge), not the CLI — filed here because Cowork desktop bugs are tracked in this repo; the Terminal/Shell field is N/A.

Support history: a ticket opened Jul 17 via the in-app messenger went through bot triage (sign-out → done, no effect; clock drift → ruled out; a macOS "Settings → Privacy & Security → Keychain" path that does not exist; an unrelated 15-minute Sonnet-5 incident). It was closed without the engineering escalation that was offered. A replacement ticket was opened Aug 4 with the full case file (complete bridge_state history Jul 2 – Aug 4, app version timeline, MCP mass-disconnect episodes, memory telemetry) — happy to attach that file here on request.

Possibly relevant: macOS memory-pressure warnings coincide with the worst failure days (app process tree 5.0–5.4 GB across 36–45 child processes with 5 concurrent CLI sessions), though failures also occur while the Mac is idle. chrome-headless-shell crashed 3× on Jul 15. No Claude crash reports at any point.