Desktop app: Remote Control fails with 'Session creation failed — see debug log' on sessions that previously had remote control enabled; new sessions work

Summary

In the Claude desktop app, enabling Remote Control fails with Session creation failed — see debug log (sometimes Remote credentials fetch failed — see debug log) — but only for sessions that had remote control enabled before ~July 11. Brand-new sessions enable remote control fine with the same account, same app, same machine, seconds apart. Additionally, the error says "see debug log" but no debug log with the HTTP/error detail is written anywhere under ~/Library/Logs/Claude/.

Environment

• Claude desktop app 1.22209.0 (also reproduced on the prior version before tonight's auto-update)
• macOS Darwin 25.5.0 (Apple Silicon)
• Consumer claude.ai account (single org)

Timeline / repro

1. Remote control worked normally for every session through July 11 ~12pm (sessions appeared on the iOS app).
2. July 11 8:05pm: [remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090) — bridge never re-established.
3. Since then, toggling remote control on any session created before that date fails within ~2s:

``
[info] Enabling remote control for session local_<id>
[info] [remote-control] bridge_state: failed — Session creation failed — see debug log
[error] Failed to toggle remote control for local_<id>: Session creation failed — see debug log
`
Repeated attempts alternate between Session creation failed and Remote credentials fetch failed`.

1. A session created today enables fine, immediately before/after the failures:

``
22:08:02 Enabling remote control for session local_<new-id>
22:08:03 bridge_state: ready
22:08:03 Remote control enabled: https://claude.ai/code/session_01...
22:08:04 bridge_state: connected
``

Ruled out locally

• Auth/account: POST /v1/environments/bridge succeeds (environment reused/registered fine), and a new session enables remote control with the same tokens.
• Transcript size: the working session's project history is larger than the failing ones.
• App version: persists across the update to 1.22209.0 and app restarts.
• Filesystem permissions on the session cwd: directories readable.

The only distinguishing factor found: failing sessions all had remote control enabled before the July 11 bridge drop, suggesting a stale server-side remote session record blocks re-creation.

Secondary bug

The error text says "see debug log", but nothing beyond the one-line bridge_state: failed message is logged at the current level, and no separate debug log file exists — the underlying HTTP status/response is undiscoverable by the user.

Expected

• Re-enabling remote control on an older session should succeed (or the stale server-side record should be replaced/reconciled).
• The referenced debug detail should actually be written somewhere.