Remote Control: bridge init gives up permanently after 3 retries in ~2s — transient 401 from code-sessions API leaves session running but invisible on claude.ai/code

Summary

When starting claude --remote-control <name>, the Remote Control bridge initialization retries only 3 times over ~2 seconds and then gives up permanently for the lifetime of the process. The code-sessions API (createCodeSession and the /bridge remote-credentials fetch) intermittently returns 401 Authentication failed even with a fully valid OAuth credential — so a launch that hits 3 transient 401s in a row produces a session that runs normally locally but is permanently invisible on claude.ai/code and the mobile app, with no retry, no UI error after startup, and no way to recover short of killing and relaunching the process.

For unattended/headless setups (a watchdog-managed always-on remote-control session), this silently severs remote access until a human notices.

Environment

• Claude Code v2.1.212 (also observed on 2.1.210)
• macOS 26.6 (Apple Silicon), sessions launched in a detached tmux pane
• Claude Max subscription, OAuth keychain credential valid (access token present, hours from expiry; same token serves API traffic and claude.ai MCP proxies fine in the same minute)

Evidence (from --debug-file)

Failure mode A — createCodeSession 401s 3×, init gives up:

16:11:09.858Z [DEBUG] [code-session] Session create failed 401: Authentication failed
16:11:09.858Z [DEBUG] [remote-bridge] createCodeSession failed (attempt 1/3), retrying in 519ms
16:11:10.612Z [DEBUG] [code-session] Session create failed 401: Authentication failed
16:11:10.612Z [DEBUG] [remote-bridge] createCodeSession failed (attempt 2/3), retrying in 1035ms
16:11:11.841Z [DEBUG] [code-session] Session create failed 401: Authentication failed
16:11:11.847Z [DEBUG] [bridge:repl] Init returned null (precondition or session creation failed); consecutive failures: 1

After Init returned null nothing further is attempted — the session stays up for hours with zero bridge connection attempts (verified via lsof over a 6-hour window).

Failure mode B — session creates, then fetchRemoteCredentials 401s 3×, same permanent give-up:

15:49:10.284Z [DEBUG] [remote-bridge] Created session cse_01████
15:49:10.447Z [DEBUG] [code-session] /bridge failed 401: Authentication failed
15:49:10.448Z [DEBUG] [remote-bridge] fetchRemoteCredentials failed (attempt 1/3), retrying in 449ms
15:49:11.306Z [DEBUG] [code-session] /bridge failed 401: Authentication failed
15:49:12.381Z [DEBUG] [code-session] /bridge failed 401: Authentication failed
15:49:12.381Z [DEBUG] [remote-bridge] Creds failed; onStateChange set, msg="Remote credentials fetch failed — see debug log"
15:49:12.384Z [DEBUG] [bridge:repl] Init returned null (precondition or session creation failed); consecutive failures: 1
15:49:12.684Z [DEBUG] [code-session] Archive session_01████ status=200

That the 401s are transient (not a credential problem) is shown by a success minutes later with the same keychain credential, where attempt 1 fails and the in-window retry succeeds:

16:26:07.448Z [DEBUG] [code-session] Session create failed 401: Authentication failed
16:26:07.448Z [DEBUG] [remote-bridge] createCodeSession failed (attempt 1/3), retrying in 450ms
16:26:08.275Z [DEBUG] [remote-bridge] Created session cse_01████
16:26:08.524Z [DEBUG] [code-session] /bridge failed 401: Authentication failed
16:26:09.373Z [DEBUG] SSETransport: Connected

Across one afternoon (same machine, same credential): 10 launches → 4 bridged, 6 permanently failed. Two sessions launched in the same second both succeeded; back-to-back retries seconds apart tended to fail repeatedly, spaced (10-min) retries eventually succeeded — consistent with server-side throttling being surfaced as 401 rather than 429/Retry-After.

Expected behavior

1. Bridge init should keep retrying with exponential backoff (as SSETransport reconnects already do) instead of giving up forever ~2s after launch. A transient server blip at t=0 should not permanently sever remote control for a session that may run for days.
2. If retries are truly exhausted, the failure should be loud: a persistent visible banner in the REPL (currently the "/remote-control is active" line simply never appears) and a non-debug log line. Headless/watchdog setups have to parse --debug-file output today to detect the condition.
3. Server-side: if the 401s are actually rate limiting on session creation, returning 429 with Retry-After would let the client distinguish "back off" from "re-auth".

Repro

Hard to force (server-dependent), but frequent under repeated session creation: launch claude --debug-file /tmp/x.log --remote-control test repeatedly (killing between attempts); a few attempts in, a launch logs 3× 401 → Init returned null and never appears on claude.ai/code while running normally otherwise.

Workaround

External watchdog: launch with --debug-file, treat a trailing Init returned null with no later SSETransport: Connected as bridge-failed, and kill + --resume-relaunch on a ~10-minute cadence until a launch bridges.