Remote Control (Windows desktop): "Session creation failed" is deterministic while the app's OAuth token sits expired — token is only refreshed lazily on session focus change

Summary

On the Windows desktop app, the "transient 401" behind Session creation failed — see debug log is not random: it is deterministic when the app's cached OAuth access token has already expired.

The desktop app refreshes its OAuth token lazily, only when an [oauth-v2] lookup is triggered (e.g. LocalSessions.setFocusedSession). Enabling Remote Control is not one of those triggers, so a toggle that lands inside the post-expiry window hands the bridge a dead token. createCodeSession then 401s three times in ~2s, the retry budget is exhausted, and the bridge gives up permanently (matching the retry mechanics documented in #78585).

The token lifetime is ~8h, but nothing refreshes it proactively, so the window where it is expired-but-not-yet-refreshed can be over an hour long.

Environment

• Claude Desktop app on Windows 11 Pro (10.0.26200)
• Bundled Claude Code 2.1.219 (%APPDATA%\Claude\claude-code\2.1.219, GIT_SHA 7006c4c, BUILD_TIME 2026-07-24)
• remoteControlAtStartup: true
• Max subscription, residential network, regular inference traffic unaffected throughout

Evidence

[oauth-v2] refreshing token events from %APPDATA%\Claude\logs\main.log — note the 9h11m gap, versus a ~8h token lifetime:

2026-07-26 11:50:50 [info] [oauth-v2] refreshing token for orgId=<redacted>
2026-07-26 21:01:44 [info] [oauth-v2] refreshing token for orgId=<redacted>

The token was therefore expired from roughly 19:50 until 21:01:44. Remote Control was enabled at 21:01:07 — inside that window:

21:01:07 [info] LocalAgentModeSessions.getSupportedCommands: sessionId=undefined, cwd=undefined
21:01:08 [info] LocalSessions.sendMessage: sessionId=local_e4ac4f1b-…
21:01:08 [info] Enabling remote control for session local_e4ac4f1b-…
21:01:10 [info] [remote-control] bridge_state: failed — Session creation failed — see debug log
21:01:10 [error] Failed to toggle remote control for local_e4ac4f1b-…: Session creation failed — see debug log

21:01:44 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
21:01:44 [info] [oauth-v2] lookup orgId=<redacted> cacheKey=<redacted>
21:01:44 [info] [oauth-v2] refreshing token for orgId=<redacted>        <-- refresh happens only now
21:01:44 [info] [CCD] LocalSessions.setFocusedSession: sessionId=local_4e225838-…

21:01:57 [info] Enabling remote control for session local_4e225838-…
21:01:58 [info] [remote-control] bridge_state: ready
21:01:58 [info] Remote control enabled: https://claude.ai/code/session_<redacted>
21:01:58 [info] [remote-control] bridge_state: connected

The refresh at 21:01:44 was triggered by a session focus change, not by the Remote Control toggle. 13 seconds later the identical toggle succeeded.

Enabling remote control → bridge_state: failed is exactly 2 seconds, which matches Bmr() exhausting init_retry_max_attempts: 3 with 500ms base exponential backoff — i.e. all three attempts were rejected immediately, consistent with the 401 traces in #78585 rather than a network blip.

The only other occurrence of this error on this machine (2026-07-17 05:50:40 → 05:50:42) shows the same 2-second signature.

Reproduction

1. Leave the desktop app idle for more than ~8h (long enough for the cached OAuth token to expire without any session focus change).
2. Open a session and enable Remote Control as the first action.
3. → Session creation failed — see debug log.
4. Click another session and back (forces [oauth-v2] lookup → refresh), then enable Remote Control again. → succeeds.

Expected

Enabling remote control should validate/refresh the OAuth token before handing it to the bridge, the same way setFocusedSession does. Alternatively the bridge should treat a 401 on createCodeSession as "refresh credentials and retry" rather than consuming a plain retry attempt.

Workaround

Switch session focus (click another session and back) before enabling Remote Control. After a failure, waiting ~40s and toggling again also works, because the failed attempt itself eventually triggers a lookup.

Side note: local overrides for the bridge config are dead code

While investigating whether the retry budget could be raised locally, tengu_bridge_repl_v2_config turns out to be server-side only — both local override paths are unreachable in the shipped build:

function S8r(){
  if(XXi) return Tst;
  return XXi=!0, Tst;                                // early return
  let e = process.env.CLAUDE_INTERNAL_FC_OVERRIDES;  // unreachable
  ...
}
function Ker(){ return }                             // empty stub

So CLAUDE_INTERNAL_FC_OVERRIDES is silently ignored. If that env var is meant to work, this is a separate bug; if it is intentionally disabled, users have no way to widen the retry budget as a stopgap.

Related

Likely the desktop-app root cause behind the "transient 401" reported in #78585, #78323, #78470. Same environment as #78590 (Windows / desktop / auth), but that report's progression (claude.ai web-session expiry, re-sign-in, post-reboot silent no-op) is different from the plain token-expiry window described here. Also #78380, #78580.