[BUG] Forked sessions never become Remote Control eligible, so they never appear in the mobile Code tab

Environment

• Claude desktop app 1.52386.6 on macOS 26.6.2 (Darwin 25.6, Apple Silicon), Claude Code CLI 2.1.266
• Claude mobile app, same account, Code tab

What happens

A session created by forking an existing session is never registered with the Remote Control bridge, so it never appears in the Code tab of the mobile app — no matter how recently it ran, whether it is pinned, or whether its host machine is online. There is no error and no UI hint anywhere; the session is simply absent from the list.

Every visible signal points the other way, which makes this expensive to diagnose: in my case a session that had run seconds earlier, on an online laptop, pinned, with filters cleared, was missing, while a session whose device was offline was listed.

Why

remoteControlAutoEligible is only ever assigned on a session's first turn:

finishInitialEnqueue(e,t,n,r){ … r && (e.remoteControlAutoEligible = !0);
  this.maybeAutoEnableRemoteControl(e, n, r ? "first_turn" : "cold_resume") }

and the auto-enable policy gates on that flag:

remoteControlPolicyCovers(e){ return !!e.remoteControlAutoEligible && !e.scheduledTaskId }

A fork adopts an existing transcript, so it takes the resume path (cold_resume) and the flag is never set — for the whole life of the session. Nothing in the policy references forkedFromSessionId, so the exclusion of forks looks incidental rather than intended, especially as neighbouring resume-like paths were given explicit re-arming:

clearSession:  s.remoteControlAutoEligible ??= !0                  // re-armed after /clear
prewarm claim: e.remoteControlAutoEligible = !0                    // then …(…, "first_turn")

Data

Across all 25 sessions created on this machine since 2026-09-01 (~/Library/Application Support/Claude/claude-code-sessions/<org>/<user>/local_*.json):

| kind | count | remoteControlAutoEligible | bridgeSessionIds | visible on mobile |
|---|---|---|---|---|
| ordinary | 18 | true | present | yes |
| scheduled task | 2 | true | absent | no — expected, !e.scheduledTaskId |
| forked (forkedFromSessionId set) | 5 | absent | absent | never |

No unexplained records: every case matches the code path above.

Steps to reproduce

1. Start an ordinary session, send a message, confirm it appears in the mobile Code tab.
2. Fork that session.
3. Use the fork so it has recent activity; optionally pin it.
4. Open the mobile Code tab with all filters cleared — the parent is listed, the fork never is.

Expected

A fork is an ordinary local session, on the same machine, under the same account. It should be offered to the Remote Control bridge on the same terms as any other session.

Suggested fix

Re-arm eligibility on the fork path exactly as /clear and prewarm-claim already do (remoteControlAutoEligible ??= true), rather than binding it to isFirstTurn only. Failing that, mark such sessions in the desktop UI as not remotely reachable, instead of silently omitting them from the mobile list.

Workaround

Enabling Remote Control manually in the session works — the policy also honours remoteControlUserRequested. The session must have an active query first, otherwise it returns "Remote Control requires an active session. Send a message first."

🤖 Generated with Claude Code