Desktop: no supported way to bring dormant sessions back into Remote Control after an app restart

Summary

After the desktop app restarts, every session stops. A stopped session cannot appear in Remote Control, so it is unreachable from the phone until it is opened by hand and /remote-control is typed into it. With around twenty long-lived sessions this is a manual ritual after every restart, and there appears to be no supported way to automate it.

Environment

• Claude Code Desktop on Windows 11, direct download build (not Microsoft Store)
• Desktop app 1.40609.0, session runtime 2.1.247, CLI 2.1.250
• Roughly twenty long-lived sessions, all in a single project directory
• remoteControlAtStartup: true in settings

Expected

Sessions that were live before a restart come back into Remote Control afterwards, or there is some supported command that puts them there.

Actual

Each session must be opened individually in the sidebar and /remote-control typed into it, every time. remoteControlAtStartup: true does not cover these sessions, apparently because it only applies to sessions created after the setting was enabled.

What I tried, and what the evidence showed

1. claude -p --resume <session-id> "<prompt>"
Works, and attaches to the genuine session rather than forking: the existing transcript grew from 6,798,202 to 6,825,358 bytes, the transcript count in the project directory stayed at 294, and the appended entries carried the same sessionId. The resumed session had full context and correctly identified itself and its last piece of work.

But it is a one-shot: the process runs a turn and exits, so no persistent process exists and Remote Control never sees it. Documented behaviour, so this is not a bug report, only context.

2. claude remote-control --session-id <session-id>

Error: Could not reach the server to look up session <uuid>.
Check your network or run `claude /login`, then try again.

The message points at auth or network, and both are red herrings: plain claude remote-control run in the same directory moments later connected successfully. The flag appears to expect the server side session identifier (the session_01... value that appears as bridgeSessionId in ~/.claude/sessions/<pid>.json), not the local session id that --resume takes and that names the transcript file.

That identifier only exists while a session is running. So a dormant session has no handle that --session-id will accept, and the flag cannot reach the sessions that most need it. If this is intended, the error message is misleading, since a network or login problem is neither the cause nor the fix.

3. Ctrl+Tab through the sidebar
This does start dormant sessions, as documented. Four presses produced four new entries in ~/.claude/sessions/. However every one came up with bridgeSessionId null, confirming that starting a session is not sufficient and /remote-control still has to be typed into each one.

Any one of these would solve it

1. Make remoteControlAtStartup apply to all sessions, not only those created after the setting was turned on.
2. Let claude remote-control --session-id accept the local session id (the one --resume takes), so a dormant session can be brought online by id.
3. A restore-on-launch option that reopens the sessions that were open when the app quit.
4. A command that registers Remote Control across all sidebar sessions in one go.

Smaller point

The error message in (2) sends you to check your network and your login when the real cause appears to be an identifier of the wrong kind. Naming the expected identifier would have saved a fair amount of time.