Remote Control bridge init gives up permanently after 3 retries (~1.3s) — no background retry, no detectable state for unattended sessions

Summary

When --remote-control bridge initialization fails at launch, the CLI retries 3 times over ~1.3s and then gives up permanently for the lifetime of that process. There is no background retry and no machine-readable failure state. For unattended, always-on sessions this converts a transient server-side hiccup into an indefinite outage that no local health check can detect.

Root cause of the underlying failures is tracked in #78469 (intermittent 401s from /v1/code/sessions). This issue is about the client-side behavior that amplifies it: even after the server recovers minutes later, the process never tries again.

Why this is worse than it sounds (unattended scenario)

I run claude --remote-control <name> as a 24/7 supervised session on a headless Linux box (Synology DSM, x86_64), kept alive by cron + tmux, so the session is reachable from the mobile/desktop app at any time. When bridge init loses all 3 attempts:

• the process stays alive and looks completely healthy
• ps shows it running, uptime keeps growing
• ESTABLISHED connections are > 0 (MCP servers + telemetry keep sockets open), so a connection-count health check passes
• the startup banner shows Claude Max — credentials are fine
• no crash, no restart loop, no non-zero exit
• the session simply never appears in the app's host list

The only evidence anywhere is a single line of scrollback text (Remote Control failed / Remote credentials fetch failed). In one incident this left the host invisible in the app for three days while every watchdog I had reported healthy. I now scrape tmux pane text for that string as the sole detection method, which is obviously fragile — it breaks whenever the wording or the TUI layout changes, and it can be polluted by --continue / --resume replaying old transcript text containing the same string.

Repro

1. Launch claude --remote-control <name> while /v1/code/sessions or /bridge is returning 401s (see #78469 for how to reproduce that half; a local proxy returning 401 for those paths works too).
2. Observe in --debug: 3 attempts within ~1.3s, then Creds failed; onStateChange set and handleStateChange state=failed.
3. Restore the endpoint to healthy.
4. Observe: the process never re-attempts bridge init. It remains alive and unregistered indefinitely. Only killing and relaunching the process recovers it.

[code-session] /bridge failed 401: Authentication failed
[remote-bridge] fetchRemoteCredentials failed (attempt 1/3), retrying in 594ms
[code-session] /bridge failed 401: Authentication failed
[code-session] /bridge failed 401: Authentication failed
[remote-bridge] Creds failed; onStateChange set, msg="Remote credentials fetch failed — see debug log"
[bridge:repl] handleStateChange state=failed detail="Remote credentials fetch failed — see debug log"

Requested behavior

Either of these would fully solve the unattended case; the first is preferable:

1. Background retry with exponential backoff. After the initial 3 attempts fail, keep retrying bridge init in the background (e.g. 30s → 1m → 5m, capped) for as long as the process lives. The failure is known to be transient and the fix is already "relaunch the process", which is strictly more disruptive than retrying in place.
2. Expose a machine-readable state. A status file, a --health-port returning registration state as JSON, or a documented stable marker — anything that lets a supervisor detect "process alive but not registered" without scraping TUI text.

A smaller, independently useful improvement: make the retry count/window configurable (env var), so unattended deployments can trade startup latency for resilience.

Environment

• Claude Code v2.1.212
• Linux x86_64 (Synology DSM 7.x), headless, launched under tmux by cron
• Claude Max subscription, claude.ai OAuth (banner confirms Claude Max, not API billing)
• Direct internet connection, no proxy
• First observed: sessions launched 2026-07-14 onward stayed unregistered until manually recycled 2026-07-17

Related

• #78469 — server-side root cause (intermittent 401 on /v1/code/sessions)
• #78597, #78545, #78825 — other surfacings of the same failure at bridge init