[BUG] Desktop app: forked sessions never enable Remote Control, so they never appear on mobile/web

Component: Claude Code Desktop app — Remote Control / session forking
Version: 2.1.209 (native install), Windows 11
Plan: Max

Summary

When a Code session is created via the Desktop app's fork action, it is never registered with the Remote Control bridge. Fresh (non-forked) sessions bridge automatically ~6–8 s after start; forked sessions never do. The result is that a forked session has no server-side record at all — no session_01… id, no claude.ai/code/… URL — and therefore can never appear in the mobile app's Code list or on the web, regardless of whether the process is running, closed, or archived.

Expected behavior

A forked session should be treated like any other interactive session: if Remote Control is enabled (or following the org default), it should bridge to the server and become visible/controllable from mobile and web.

Actual behavior

Forked sessions are silently never bridged. They are visible only in the local Desktop history list.

Evidence / reproduction

On a machine with Remote Control at its default (enabled):

1. Start a fresh Code session → within ~6–8 s the logs show:

``
Starting local session local_<uuid>
Enabling remote control for session local_<uuid>
Remote control enabled: https://claude.ai/code/session_01<...>
`
and the session's local_<uuid>.json record gains a bridgeSessionIds` key. It appears on mobile.

1. Fork that session from the Desktop UI → the logs show:

``
LocalSessions.forkSession: parentSessionId=<...>
[CCD] Warming session local_<uuid>
startShellPty ...
`
with **no** Starting local session line and **no** Enabling remote control line. The forked local_<uuid>.json record **omits the bridgeSessionIds` key entirely** (absent, not empty). It never appears on mobile/web.

Cross-tab over ~100 local session records on one machine:

| | has bridgeSessionIds | key absent |
|---|---:|---:|
| not a fork | 97 | 1–3 |
| fork (forkedFromSessionId present) | 0 | 4 |

The absence is a birth condition — one forked record sat unbridged for ~48 hours before it was archived; it was never bridged at any point.

Session record store: %APPDATA%\Roaming\Claude\claude-code-sessions\<orgId>\<userId>\local_<uuid>.json
Logs: %APPDATA%\Roaming\Claude\logs\main.log (+ rotated main1.log, main2.log)

Impact

Users who work in a fork-heavy pattern (branching a long-running session into sub-tasks) find those sub-tasks completely absent from mobile and web, with no error or indication of why. Because a fork produces no session_01… URL, there is not even a URL to open manually to recover visibility.

Notes

The Desktop docs do not document a fork feature, and no changelog entry connects forking to Remote Control, so it's unclear whether this is intended. If intended (e.g. forks deliberately excluded from the server), documenting it and surfacing it in the UI would prevent the silent-data-invisibility surprise. If unintended, the fork code path appears to be missing the remote-control enablement call that the fresh-start path performs.