Persistent headless `--remote-control` sessions on a server never appear in the mobile app — no safe way to reach long-running, in-progress work

Summary

I run a fleet of ~40 persistent, long-lived Claude Code sessions on a headless Linux server, each launched in tmux via claude --dangerously-skip-permissions --remote-control <name> --continue (supervised so they auto-resume). These are not throwaway sessions — they run multi-day work (build bake-offs, portfolio pipelines, orchestration) and hold important in-progress context.

None of these sessions appear in the iOS app's "Code" tab, and I have no reliable way to reach them from mobile. Because I can't see or drive them from my phone, I effectively lose access to in-progress work — and I'm afraid to restart anything to "fix" visibility because a restart interrupts whatever is mid-flight.

This is the same registration gap as #30691 (closed not planned), but the severity is higher for persistent server fleets: it's not a convenience issue, it's "I can't safely reach important running work from the device the feature is meant for."

Environment

• Claude Code: 2.1.206 (also observed across 2.1.202–2.1.206)
• OS: Ubuntu (headless server, accessed via SSH)
• Sessions: claude --remote-control <name> inside tmux, supervised with --continue auto-resume
• Client: Claude iOS app, logged into the same Max account
• hasUsedRemoteControl: true

Steps to reproduce

1. On a headless server over SSH, start a persistent session: tmux new -d -s work 'claude --remote-control my-session'
2. The TUI shows Remote Control active with a https://claude.ai/code/session_… URL.
3. Open the iOS app → Code tab. The session is not listed (force-quit, pull-to-refresh, and sign-out/in do not help).
4. mcp__ccd_session_mgmt__list_sessions (the fleet API) also does not return these sessions — its list is stale/empty of them.
5. Only after manually opening the session's URL does that one session appear — per session, no bulk registration.

Expected

Sessions started with --remote-control (especially named, persistent ones) should auto-register and appear in the mobile "Code" tab / FleetView without manually opening each session URL — so a server fleet is reachable from mobile.

Actual

Headless --remote-control sessions never auto-appear on mobile. With ~40 sessions there is no practical way to open 40 URLs, and the URL is only visible in each session's live TUI. Result: important, in-progress work is unreachable from the phone, and the only "fixes" (restarting sessions) risk interrupting that work.

Impact / why this matters

• Persistent server-based fleets are a real, growing use case (VPS + tmux + remote control is widely documented).
• The failure mode pushes users toward restarting sessions to force re-registration — which is exactly the action that endangers in-progress work.
• There is no in-app affordance to "add an existing server session by name," and no bulk-register.

Related

• #30691 (closed not planned) — same core symptom on the same setup
• #28402 — RC session not visible in list, can't reconnect after leaving
• #60780 — desktop RC works, mobile receives nothing
• #60437 — Agent View doesn't enumerate FleetView/daemon-fleet sessions

Possible resolutions

1. Auto-register --remote-control (and "enable for all sessions") sessions into the mobile fleet without requiring a manual URL open.
2. Provide a bulk/by-name "add existing session" path in the mobile Code tab.
3. Expose the session URL non-interactively (e.g. claude remote-control --print-url, or write it to a file) so fleet managers can surface all URLs at once.
4. At minimum, document the manual-URL workaround for headless fleets and reopen #30691.