[BUG] Desktop app: resuming an idle session never re-registers remote control — session permanently invisible in the iOS app

Bug Report

Environment:

• Claude Desktop app 1.17377.1 (macOS 26.5, Apple Silicon), embedded Claude Code 2.1.197
• iPhone: Claude iOS app, same account
• Remote control auto-enables for new sessions (confirmed in logs below)

Summary

A Claude Code session created in the desktop app registers remote control once, at creation — it appears in the iOS app immediately. After the desktop app's idle timeout stops the warm session, the session disappears from iOS (expected). But when the user later returns to that session and sends a new message, the desktop app warms the session back up and responds without ever re-registering remote control — so the session works locally but never reappears in the iOS app, no matter how many messages are sent into it.

The result: any session older than one idle timeout is permanently invisible from mobile, even though it is alive and actively used on desktop. The only recovery is creating a brand-new session.

Steps to reproduce

1. In the desktop app (Code tab), create a new session and send a message → session appears in the iOS app right away.
2. Leave it idle (~15 min) until the app disconnects the warm session.
3. Session disappears from the iOS app — expected so far.
4. Return to the session on desktop and send another message. The app responds normally.
5. Bug: the session never reappears in the iOS app. Repeating step 4 any number of times doesn't help.

Log evidence (~/Library/Logs/Claude/main.log)

At session creation, remote control is explicitly enabled:

2026-06-30 18:14:46 [info] Enabling remote control for session local_bb13a848-…
2026-06-30 18:14:47 [info] [remote-control] bridge_state: ready
2026-06-30 18:14:47 [info] Remote control enabled: https://claude.ai/code/session_0155…
2026-06-30 18:14:48 [info] [remote-control] bridge_state: connected

Idle timeout later disconnects the warm session:

2026-06-30 18:30:06 [info] [WarmLifecycle:session] Idle timeout reached, disconnecting local_bb13a848-…

Next day, the user types into that same session. The app warms it up and answers — but note there is no "Enabling remote control" line, neither here nor at any later point:

2026-07-01 17:45:21 [info] [WarmLifecycle:preview] Warming up session local_bb13a848-…
2026-07-01 17:45:32 [info] LocalSessions.startShellPty: sessionId=local_bb13a848-…
2026-07-01 17:45:32 [info] [CCD] LocalSessions.replaceRemoteMcpServers: sessionId=local_bb13a848-…, serverCount=1
2026-07-01 17:45:42 [info] [WarmLifecycle:session] Starting idle timeout for local_bb13a848-…: 900s

Grepping the whole log confirms: Enabling remote control fires exactly once per session, at creation — never on any subsequent warm-up/resume of the same session.

Expected behavior

Re-activating a session (warm-up on a new user message) should re-run the same remote-control registration that session creation runs, so the session becomes reachable from the iOS app again. Alternatively (or additionally), an explicit per-session "enable remote control" affordance in the desktop UI would give users a manual recovery path.

Related

• #60699 — feature request for an in-session /remote-control toggle (CLI-side flavor of the same gap: registration is start-time-only)
• #64841 — iPhone app shows "No sessions found" for desktop sessions
• #57361 — session bridge auto-disposed after app restart (closed; same "bridge dies and is never re-established" pattern)