Desktop app Remote Control repeatedly fails: 'Remote credentials fetch failed' / 'Session creation failed', then silent no-op after reboot; claude.ai session expiry breaks credential refresh

Summary

Remote Control from the Claude Desktop app has been failing repeatedly today. The failure mode has changed over the course of the day: first Remote credentials fetch failed, then Session creation failed, and now (after a PC restart) toggling remote control produces no response and no log activity at all. A claude.ai re-sign-in fixed it once, temporarily, for one session — new sessions then failed again within the hour.

Environment

• Claude Desktop app on Windows 11 Pro (build 10.0.26200), updater shows staged version 1.22209.0
• Bundled Claude Code 2.1.209 (%APPDATA%\Claude\claude-code\2.1.209)
• remoteControlAtStartup: true in ~/.claude/settings.json
• Corporate network; regular chat/inference (api.anthropic.com) worked flawlessly all day — only Remote Control is affected
• Remote Control has worked reliably from this same app/machine/network for the past several weeks

Timeline (all times US Eastern, 2026-07-17, from %APPDATA%\Claude\logs\main.log)

• 03:58 — bridge_state: connected (last known-good; bridges armed on previous days kept working through the whole outage)
• 09:34 — new session auto-arm fails: Remote credentials fetch failed — see debug log. Every manual toggle after this fails the same way (09:34, 11:06, 11:19)
• ~11:33 — app unexpectedly prompts for claude.ai sign-in; user re-authenticates ("new trusted device" email confirms). So the claude.ai web session appears to have expired without any visible indication until this prompt
• 12:00–12:03 — after re-sign-in, arming the existing session succeeds: bridge_state: connected (with one transient Transport closed: this connection is no longer the active worker for the session (code 4090) in between)
• 12:42 — arming a newly created session fails again: Remote credentials fetch failed
• 12:48 — retry gets one stage further, then: Session creation failed — see debug log
• 13:06 — PC restarted. After restart, typing /remote-control in a session produces no visible response and no corresponding log lines whatsoever in main.log (no "Enabling remote control", no bridge_state)

Log excerpts

09:34:18 [info] [remote-control] bridge_state: failed — Remote credentials fetch failed — see debug log
09:34:18 [error] Failed to toggle remote control for local_2db55632-…: Remote credentials fetch failed — see debug log
12:00:49 [info] [remote-control] bridge_state: connected
12:01:25 [info] [remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090)
12:02:59 [info] Enabling remote control for session local_2db55632-…
12:03:00 [info] [remote-control] bridge_state: connected
12:42:22 [error] Failed to toggle remote control for local_aab54a9a-…: Remote credentials fetch failed — see debug log
12:48:07 [error] Failed to toggle remote control for local_aab54a9a-…: Session creation failed — see debug log

Notes

• The errors say "see debug log" but we could not locate any debug log with more detail than main.log (searched ~/.claude, %APPDATA%\Claude, %LOCALAPPDATA%\claude-cli-nodejs). If there is one, the error message should say where it is.
• claude remote-control (CLI server mode) from a terminal on the same machine/network connected fine during the desktop-app outage, so the CLI credential path was unaffected.
• Curl to claude.ai from this network returns a Cloudflare Cf-Mitigated: challenge 403 for non-browser requests — unclear if related; browsers pass fine.

Expected

• Remote Control credential refresh should survive claude.ai web-session expiry (or re-prompt immediately), instead of failing silently for hours.
• Toggling remote control should always produce user-visible feedback and log activity.
• Errors that say "see debug log" should point to an actual findable log file.

Impact

User lost phone access to sessions during a field job that depended on it, and spent a large part of the day (and significant usage) debugging infrastructure instead of working.