Remote Control: Desktop SSH reconnect restarts the host daemon and kills all child sessions; Remote Control flag silently lost

What's wrong

When Claude Desktop (macOS, built-in SSH) reconnects to a self-hosted Linux host — e.g. after the laptop wakes from sleep — it restarts the server --serve daemon on the host. Every ccd-cli session process is a child of that daemon, so they are all killed during the handover, including a session that is actively serving the mobile app over Remote Control at that moment.

The session is immediately respawned with --resume <id>, but without re-registering Remote Control. Net effect for the user:

• the chat that was live on mobile goes disconnected/archived;
• back on Desktop, the Remote Control toggle is off, although nobody disabled it.

Crucially, Remote Control otherwise survives the laptop being closed: with the laptop fully offline (0 SSH connections, verified), the ccd-cli process keeps its own TLS connections to Anthropic and the mobile app keeps working. It is specifically the Desktop reconnect that destroys it.

Steps to reproduce

1. On Desktop, open a session on an SSH-connected host; enable Remote Control.
2. Close the laptop; drive the session from the mobile app (works — the relay is held server-side by the ccd-cli process).
3. Reopen the laptop and let Desktop reconnect.
4. Observe: the session on mobile is now disconnected/archived; the Desktop Remote Control toggle is off.

Forensic evidence (host logs, UTC)

sshd auth log + ~/.claude/remote/run/*/remote-server.log:

13:52:38  sshd: Accepted publickey (Desktop reconnects)
13:52:42  old daemon log ends; new daemon starts ("Claude remote server listening on .../rpc.sock")
          -> all 4 ccd-cli children of the old daemon are gone, incl. the one holding
             the live Remote Control relay for the active session
13:52:52  new ccd-cli spawned: --resume 9de6a872-... (no remote-control registration)
13:52:53  new process closes the pending turn ("No response requested")

Process facts confirming the architecture: server --serve runs with PPID 1 (reparented to systemd, no controlling TTY) and survives ordinary disconnects for 18h+; the ccd-cli sessions are its children (PPID = daemon, no TTY). The daemon restart is therefore what orphans them.

Expected behavior

A Desktop reconnect should not tear down live sessions. Either reuse the running daemon, or migrate existing session processes to the new one, or — at minimum — re-register the previous Remote Control state on the respawned session so it does not silently go offline.

Related

Symptom-level overlap with #34255 and #28571, but this report isolates a specific, reproducible cause: the host daemon restart triggered by a Desktop SSH reconnect. (Separately, a claude --remote-control session launched in a bare SSH shell also archives its remote session on exit — control_request subtype=end_session → Archive session ... status=200 — when the PTY dies; this is expected Unix process lifecycle but contradicts the Desktop popup's "Your session is preserved on the remote host", so the persistence model is worth documenting.)

Environment

• Claude Code: interactive CLI 2.1.173; Desktop-managed remote sessions (~/.claude/remote/ccd-cli/) 2.1.170
• Host: Hetzner KVM vServer, Linux (clock on UTC)
• Clients: Claude Desktop (macOS) via built-in SSH; Claude iOS app
• Plan: Max 5x; remoteControlAtStartup: true