Remote Control: registration reconnect ignores 429 retry-after, causing synchronized reconnect storms with multiple hosts on one account

Summary

When several claude remote-control host sessions run under the same claude.ai account, the bridge relay starts returning HTTP 429 — "Rate limited (429). Polling too frequently." on registration. The client then retries registration on a short fixed backoff (~380–990 ms observed) instead of honoring the server's retry-after. With N standing hosts this becomes a congestion collapse: 9–11 hosts re-register in the same second, re-trip 429, and repeat. Because the throttle is account-wide, it also 429s any new session (terminal, Desktop, phone-spawned) trying to register, so Remote Control intermittently fails to enable on every surface.

Environment

• Claude Code 2.1.150 (also repro under the 2.1.156 Desktop bundle)
• macOS 15 (arm64)
• Auth: claude.ai Max subscription (OAuth), single account
• ~11–12 always-on claude remote-control --name … --spawn worktree host processes (one per repo) + a catch-all --spawn same-dir host

Observed behavior

Host logs (StandardOutPath of each claude remote-control process) show, repeatedly and across all hosts:

Error: Registration: Rate limited (429). Polling too frequently.
·\· Reconnecting · retrying in 378ms · disconnected 0s
·/· Reconnecting · retrying in 989ms · disconnected 10s
[HH:MM:SS] Reconnected after 13s

Reconnect timestamps are synchronized to the second across independent host processes — e.g. in one minute, 9 of 11 hosts reconnect at :26, then 9 again at :42, then 6 at the next cluster. ~5 reconnect events per host per hour, in bursts at irregular intervals (calm stretches between storms).

Likely cause (from the bundled CLI)

The 429 branch parses the server header into retryAfterMs:

case 429: {
  let z = /* parse */ K?.["retry-after"];
  throw Object.assign(Error(`${q}: Rate limited (429). Polling too frequently.`),
                      z !== undefined ? { status, retryAfterMs: z } : { status });
}

…but the registration reconnect path appears to retry on the fixed init_retry_base_delay_ms (~500ms) × jitter 0.25 schedule (per tengu_bridge_repl_v2_config) rather than waiting retryAfterMs. With multiple hosts the ~25% jitter is far too small to de-correlate the herd, so they all retry together and re-trip the per-account limit.

Expected behavior

On a 429 during registration:

1. Honor the server's retry-after (retryAfterMs) before retrying.
2. When multiple sessions share an account, apply backoff + jitter wide enough to de-synchronize the herd so the fleet settles into the *_at_capacity slow-poll mode (multisession_poll_interval_ms_at_capacity: 60000) instead of storming the not_at_capacity (5000 ms) path.

Impact

Remote Control becomes unreliable once more than a small handful of always-on hosts share one account — including blocking brand-new sessions from enabling RC at all, since the limit is account-wide.

Workaround

Reduce the number of concurrent always-on claude remote-control hosts per account. (In our case: 11 → 4 standing hosts stopped the storm.)