[BUG] Remote Control intermittently fails with 'Remote credentials fetch failed' / 'Session creation failed': transient 401s from code-session service exhaust the 3-attempt retry budget

Environment

• Claude Code v2.1.212 (CLI, interactive and server mode both tested)
• macOS (Darwin 25.5.0), arm64
• claude.ai OAuth login, Max subscription, full-scope token (scopes: user:inference, user:profile, user:file_upload, user:mcp_servers, user:sessions:claude_code)
• No proxy, no ANTHROPIC_BASE_URL, ANTHROPIC_API_KEY unset (and previously present keys are in customApiKeyResponses.rejected, so not used for auth)

Symptom

Remote Control fails intermittently at startup with either:

• Remote Control failed · Remote credentials fetch failed — see debug log, or
• Session creation failed — see debug log

across /remote-control in-session, claude --remote-control, fresh processes, and new sessions. Failures occurred repeatedly on 2026-07-17 between roughly 10:07 and 10:55 UTC. Normal inference traffic worked the entire time.

Evidence: the same token fails and succeeds within 1.6 seconds

Debug logs show the underlying failure is a 401 from the code-session endpoints, and that it is a per-request coin flip rather than a bad credential. One process, one in-memory access token, three attempts:

2026-07-17T10:54:07.170Z [code-session] /bridge failed 401: Authentication failed
2026-07-17T10:54:07.170Z [remote-bridge] fetchRemoteCredentials failed (attempt 1/3), retrying in 492ms
2026-07-17T10:54:07.757Z [code-session] /bridge failed 401: Authentication failed
2026-07-17T10:54:07.758Z [remote-bridge] fetchRemoteCredentials failed (attempt 2/3), retrying in 808ms
2026-07-17T10:54:08.744Z [remote-bridge] Fetched bridge credentials (expires_in=28800s)   <-- attempt 3 succeeds, connects fine

Nothing changed client-side between attempt 2 and attempt 3.

The failure point wanders with the same signature. Earlier runs died one step sooner, on session creation (3/3 401s, so the whole attempt failed):

2026-07-17T10:21:05.968Z [code-session] Session create failed 401: Authentication failed  (attempts 1-3, gave up)
2026-07-17T10:24:02.486Z [code-session] Session create failed 401: Authentication failed  (attempts 1-3, gave up)

And in a run where creation succeeded but /bridge 401'd 3/3, the same token then archived the session successfully one line later:

2026-07-17T10:41:44.048Z [remote-bridge] Created session cse_0169mqRWRPAFBpjAGYpxU5oQ
2026-07-17T10:41:44.156Z [code-session] /bridge failed 401: Authentication failed         (x3, gave up)
2026-07-17T10:41:46.204Z [code-session] Archive session_0169mqRWRPAFBpjAGYpxU5oQ status=200

So the token is accepted by create/archive and by inference throughout, and rejected randomly by individual code-session requests. This window coincided with status.claude.com showing Degraded Performance for api.anthropic.com, claude.ai, and Claude Code (active incident opened 06:47 UTC the same day). Related older reports of RC 401s with valid logins: #30102, #61551.

Why this hurts more than it needs to (feedback)

1. The retry budget is too small for exactly the conditions that cause the error. 3 attempts with ~0.5-1.2s backoff is a ~2 second window. During elevated-error periods a per-request failure rate of p makes the whole Remote Control attempt fail with probability p^3, which at p=0.7 is every third attempt surviving. Session creation and bridge-credential fetch are one-shot startup operations; they could retry over 30-60s with exponential backoff (or keep retrying in the background and connect late) without hurting anyone. The session-create retry could also reuse the already-created cse_ session instead of starting over.

1. "see debug log" points at a log that usually does not exist. Unless the process was started with --debug (or --verbose in server mode), nothing is written; ~/.claude/debug/ may contain only a stale latest symlink from months ago. Either always persist Remote Control failure detail (a one-line file with timestamp, endpoint, and HTTP status would do), or change the message to say how to get a log (claude --debug).

1. Surfacing the HTTP status in the user-facing error would save users an hour. "Remote credentials fetch failed" reads like a local/auth-config problem, and the documented troubleshooting steps (unset ANTHROPIC_API_KEY, re-login, check proxy) all point at the user's machine. "401 from api.anthropic.com (attempt 3/3): check status.claude.com" points at the actual problem. During a status-page incident the CLI could even say so: it already knows how to reach the API.

1. Minor: the ~/.claude/debug/latest symlink is left dangling when the target session log is cleaned up, which makes "see debug log" doubly misleading.

Repro / diagnosis recipe used

# server mode, non-interactive:
script -q /tmp/rc.log claude remote-control --verbose --spawn same-dir --no-create-session-in-dir
# interactive mode (what /rc uses); tail keeps stdin open so the TUI survives EOF:
tail -f /dev/null | script -q /tmp/rc2.log claude --debug --remote-control probe

Then read ~/.claude/debug/<session-id>.txt for the [code-session] / [remote-bridge] lines.