[Bug] Remote control startup fails with intermittent 401s from code-session endpoints

Independent reproduction — different account, machine, and terminal; same afternoon onset. Also ties in #78307: we hit both failure surfaces (create-side and bridge-side) from what looks like one root cause.

Environment: macOS (darwin 25.3), Max subscription, observed on both 2.1.211 and 2.1.212, sessions launched both interactively and under a script -q PTY wrapper.

Timeline (Pacific, 2026-07-16): RC registrations succeeded at 10:22 and 14:06–14:10; first observed failure 16:45; still failing at 18:04. /v1/messages and MCP traffic authenticated fine with the same credentials throughout — sessions that lose RC registration run their whole task locally, they're just invisible/unreachable remotely.

Controlled A/B (alternating launches, minutes apart, same env): per-request 401 rate on POST /v1/code/sessions and POST .../bridge was roughly 50%+. The strongest server-side signal: the same in-memory token fails then succeeds within one process, sub-second apart —

00:48:33.616 [remote-bridge] Created session cse_013JQcX1fvZvgowkxFnUa3re
00:48:33.745 [code-session] /bridge failed 401: Authentication failed
00:48:33.746 [remote-bridge] fetchRemoteCredentials failed (attempt 1/3), retrying in 413ms
00:48:34.844 [remote-bridge] Fetched bridge credentials (expires_in=28800s)

And a run where both endpoints flapped in sequence (this one exhausted the bridge retries and surfaced the "Remote credentials fetch failed" banner, 2.1.212):

00:53:22.218 [code-session] Session create failed 401: Authentication failed
00:53:22.218 [remote-bridge] createCodeSession failed (attempt 1/3), retrying in 602ms
00:53:23.274 [code-session] Session create failed 401: Authentication failed
00:53:23.274 [remote-bridge] createCodeSession failed (attempt 2/3), retrying in 1092ms
00:53:24.590 [remote-bridge] Created session cse_01BNE8XbX7nQLRJHSnaxTG3p
00:53:24.870 [code-session] /bridge failed 401: Authentication failed

Triage note — --debug is a red herring worth ruling out early: across ~a dozen manual samples, adding --debug/--verbose appeared 100% protective and no-flag launches failed ~50% — convincing enough that we initially chased it as a heisenbug. Controlled alternating runs broke the pattern: a --debug launch failed the same way, and every successful debug run still shows 401s that the 3 internal retries happened to rescue. It's retry luck, not a flag effect. Others will likely observe the same correlation.

Given ~50% per-request failure, the 3-attempt/sub-second retry budget on both createCodeSession and fetchRemoteCredentials exhausts easily; a longer/jittered retry window would paper over incidents like this one at the client.

---
Posted by Claude Code (Fable 5), at the account owner's instruction — he has not reviewed this content.

Adding a quantified Windows datapoint that matches this issue's 401 cluster — including before/after rates across an app auto-update boundary, and evidence it is not local.

Symptom: identical to OP — toggling Remote Control fails 2–5 s after Enabling remote control with bridge_state: failed — Remote credentials fetch failed — see debug log or Session creation failed — see debug log. Nondeterministic per attempt (~25–30% success; success and failure 6–10 s apart on identical local state); retrying eventually succeeds for every session. Every failed disconnect additionally throws Cannot read properties of undefined (reading 'session_url') (157 occurrences in one night), and later DELETE /v1/code/sessions/<id> returns 404 Session not found — appears to leak server-side sessions (same mechanism as #78333).

Environment: Windows 11 Pro 10.0.22631; Claude Desktop MSIX 1.22209.0 (auto-updated from 1.20186.1 at 2026-07-17 01:31:39 UTC after being staged 72 h — [updater] Auto-restarting app after update pending for 72 hours); bundled Claude Code CLI 2.1.209. Residential IPv4-only, no proxy/PAC/VPN, clock skew +0.4 s.

Timeline / quantification (UTC):

• Jul 10–16 on 1.20186.x: 49/51 arm attempts succeeded (96%), last success 2026-07-16 22:09.
• From the FIRST attempt on 1.22209.0 (2026-07-17 01:35): 15/56 succeeded (27%) — close to OP's 22%.
• Unchanged by: OS reboot (~03:49), logout + fresh /authorize re-login (~04:02, auth succeeded, 17 sessions initialized), full MSIX reinstall of the same 1.22209.0 (~04:21).

Evidence it is not local:

• During 33 failures in one window, the same app successfully performed OAuth, message send, plugin sync, and repeated authenticated websocket connects to bridge.claudeusercontent.com — including 2 s before a failure. Endpoint-selective breakage.
• 68 TCP probes to api.anthropic.com / claude.ai from two different network stacks (Windows laptop + a Linux VM behind the same WAN): 0 anomalies, p99 213 ms.
• Success/failure sequence passes a runs test for per-request independence (z = −0.96) — inconsistent with any static local fault.

Notes for triage:

1. Server-side error rates on POST /v1/code/sessions + bridge-credentials issuance in the 2026-07-17 01:35–04:30 UTC window should show this.
2. Status page showed no incident during this window (the 07-16 "Elevated errors" incident resolved 22:53 UTC; this 401 wave continued after it).
3. The disconnect null-deref (session_url) prevents session cleanup, and combined with the 3-transient-failure self-disable (#78364) converts intermittency into a hard outage for automation that relies on Remote Control.
4. The arming retry budget (~3 tries / ~2 s) is too small for a service flaking at 25–30%; a longer backoff-retry would mask brief degradation.

Independent reproduction on macOS / 2.1.212 / claude.ai OAuth (Max), with one datum I haven't seen in this thread yet: the failure reproduces with raw curl, no CLI in the loop at all. That isolates it from the client entirely — not a client bug, not a 2.1.212 regression.

Same token, same minute, two endpoints

| Endpoint | Result |
|---|---|
| GET /v1/sessions (anthropic-beta: ccr-byoc-2025-07-29) | 12/12 → 200 |
| GET /v1/code/sessions | ~35% 200 / ~65% 401 |

n=44 across three samples (12/20, 9/12, 8/12 failing). Identical token bytes throughout (sha256 unchanged, expiresAt valid ~4h out, scopes include user:sessions:claude_code), alternating within seconds:

23:35:43 → 401
23:35:52 → 200      <- same token
23:36:00 → 401

My ~65% independently matches the 13/20 (~65%) that #78366 measured on presence pulses, which suggests one root cause across the code-session endpoints rather than three separate bugs.

The detail that may be the most useful pointer

The 401 response still carries the resolved organization header:

HTTP/2 401
anthropic-organization-id: <my org uuid, redacted — but present and correct>
request-id: req_011Cd7AhB5qjNHJw5qYbyWCk
cf-ray: a1c73c8b9f05cbab-LAX
cf-cache-status: DYNAMIC

{"type":"error","error":{"type":"authentication_error","message":"Authentication failed"},"request_id":"req_011Cd7AhB5qjNHJw5qYbyWCk"}

So the server authenticates the token far enough to resolve the organization, and then returns authentication_error anyway. That points at an inconsistency inside the code-session auth path rather than anything about token validity — consistent with the OP's observation that the same token authenticates /v1/messages and the connector MCP servers without interruption.

Repro (no CLI involved)

KC=$(security find-generic-password -s "Claude Code-credentials" -w \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['claudeAiOauth']['accessToken'])")

for i in $(seq 1 12); do
  printf "%s " $(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer $KC" \
    -H "anthropic-version: 2023-06-01" \
    -H "anthropic-client-platform: cli" \
    https://api.anthropic.com/v1/code/sessions)
done

→ mixed 401 200 401 401 …. Adding x-organization-uuid makes no difference (tested both ways, ~65–75% either way), so it isn't org resolution on the request side.

The archive endpoint is affected too: archiving one session took 6 attempts to get a 200.

Why it surfaces as a hard failure

Matches @evoskamp's analysis in #78323. The bridge's retry wrapper is a plain retry with no token refresh between attempts — budget init_retry_max_attempts: 3, from the tengu_bridge_repl_v2_config dynamic config (server-controlled, so not something users can raise locally). Startup needs two independent chains to land (createCodeSession, then /bridge credentials fetch), so at a ~65% per-call failure rate:

P(one chain fails)   = 0.65^3       ≈ 0.27
P(startup fails)     = 1 - 0.73^2   ≈ 47%

which matches the reported "fails roughly half my launches." Worth noting the retry budget is a symptom amplifier, not the bug — at a 0% server error rate the budget never matters.

Environment / timing

• macOS (darwin 27.0.0), CLI 2.1.212, claude.ai OAuth (Max 20x), single machine.
• Onset here: 2026-07-16 afternoon PT, same window as the other reports.
• status.claude.com showed all-green ("Claude Code: operational", 0 incidents) throughout, including during a run measured at 65% 401.

Happy to supply full --debug-file logs or additional request-ids if useful.

Another independent reproduction, adding two dimensions not yet in this thread: Team plan and the Linux CLI.

Environment: Linux, Claude Code 2.1.212 (stable), claude.ai OAuth, Team subscription (subscriptionType: team), remoteControlAtStartup: true. The same OAuth token drives /v1/messages and several claude.ai connector MCP servers without issue throughout — only the /v1/code/sessions + /bridge calls flap.

Across 3 startup launches within ~13 min I saw all three states described above:

Hard fail — createCodeSession 401 on all 3 attempts → Session creation failed:

06:55:54.733 [code-session] Session create failed 401: Authentication failed
06:55:54.733 [remote-bridge] createCodeSession failed (attempt 1/3), retrying in 522ms
06:55:55.437 [code-session] Session create failed 401: Authentication failed   (attempt 2/3)
06:55:56.774 [code-session] Session create failed 401: Authentication failed   (attempt 3/3)
06:55:56.774 [bridge:repl] state=failed detail="Session creation failed — see debug log"

Bridge-side flap that recovered — create OK, then fetchRemoteCredentials 401 on attempt 1/3, rescued on retry (matches @jaidhyani's sub-second flap):

07:07:34.818 [remote-bridge] fetchRemoteCredentials failed (attempt 1/3), retrying in 515ms
...        [remote-bridge] Created session cse_01Rx9… → connected

Clean connect (one launch).

So ~1/3 of my (small) sample failed outright — consistent with the ~30–65% per-request 401 rates measured above. Confirms this is not Max-specific and not macOS/Desktop-specific: a Team-plan OAuth token on the Linux CLI hits the identical endpoint-selective 401 on /v1/code/sessions. Nothing to add to @djknudson's curl-level isolation — just widening the affected population. Happy to share full --debug logs / feedback ID.

---
Drafted by Claude Code, reviewed and posted by the account owner.