Jammed background tasks + Remote Control reconnect loops silently consume Max usage window after forced token rotation

Summary

After a Claude Desktop auto-update forced an OAuth token rotation (all sessions invalidated at once), a combination of (a) Desktop background tasks (spawn_task chips) stuck in a jammed state, (b) sessions hosting Remote Control that entered reconnect/fail loops against invalid credentials, and (c) restoring/re-hosting threads into a second account burned through an entire Max 5-hour usage window with zero user-visible progress. There is no circuit breaker, no progress-vs-spend signal, and no per-session usage attribution to identify the burner while it is happening.

Environment

• macOS Darwin 25.5.0 (arm64)
• Claude Desktop 1.32352.1 (auto-updated overnight ~00:14 local; update invalidated all OAuth tokens on the machine)
• Claude Code engine 2.1.229 (Desktop-embedded) / 2.1.235 (CLI)
• Two Max accounts on one machine (separate Desktop profiles via --user-data-dir)

Timeline / mechanism

1. Overnight auto-update rotates tokens; every session on the machine 401s.
2. Sessions that were hosting Remote Control enter reconnect loops; claude.ai threads show recurring 'Remote Control disconnected' banners. Threads whose host process died continue to show 'N running tasks'.
3. Two Desktop spawn_task chips jammed (running, no progress). User forwarded the work to the second Max account and restored/resumed threads there.
4. The second account's 5-hour usage window was fully consumed by this restoration/retry activity without a single task completing.

Problems

1. No circuit breaker: tasks/sessions retrying against a dead or rotated credential (or otherwise not progressing) keep consuming the subscription usage window indefinitely.
2. No attribution: nothing in Desktop or claude.ai shows which session/task is consuming the window, so a runaway burner can only be found by killing things one at a time.
3. Stale 'running tasks' state: threads whose local host process is gone still display running tasks, inviting the user to wait on work that can never complete.
4. Update timing: the auto-updater swaps the binary and rotates tokens while sessions (including Remote Control hosts and background tasks) are live, which is what seeds the loop.

Asks

• Exponential backoff + hard stop for background tasks/hosts that repeatedly fail auth or make no forward progress; surface a 'stalled' state instead of spinning.
• Per-session/per-task usage attribution visible to the user (even a coarse breakdown would let a runaway be identified before the window is gone).
• Reconcile 'running tasks' indicators with actual host liveness.
• Defer binary swap / token rotation while sessions are actively hosting Remote Control or running background tasks, or re-auth them gracefully afterwards.

🤖 Generated with Claude Code