[FEATURE] remote-control: a supported way to run it as a persistent service (survive reboot, crash, and auto-update)

The gap

claude remote-control is a foreground terminal command, but the thing it is for — reaching my machine from my phone — is inherently always-on. Any reboot, terminal quit, crash, or CLI auto-update takes the server down silently, and there is no supported way to bring it back.

I run two servers (--spawn worktree) on each of two Macs. Keeping four of them alive is a standing manual chore.

What I had to build

A launchd agent per directory. RunAtLoad + KeepAlive cover reboot and crash. The third case needed a wrapper, and that is what makes me think this belongs in the product.

The update case is the hard part — and it is #84817

The native installer keeps one version-numbered binary (~/.local/share/claude/versions/<v>) and prunes the old one. A server started from the pruned build keeps running and keeps reporting Ready, but every new session it spawns dies with ENOENT posix_spawn .../versions/<old>, because the server spawns children at its own resolved path.

Because the server never exits, restart-on-exit never fires — only a proactive restart helps. So my wrapper polls the ~/.local/bin/claude symlink and restarts the server when the target moves, deferring while the server still has child sessions so it does not kill work in flight.

Shipping a daemon mode would likely require fixing #84817 first, or the daemon inherits the same trap.

What I would like

• claude remote-control --install-service [--dir <path>] / --uninstall-service, writing a launchd agent (macOS), a systemd user unit (Linux), or the Windows equivalent
• the server re-execing itself through the stable launcher after an update, so no external supervisor is needed
• claude remote-control status to list installed/running servers
• failing all that, a documented blessed recipe would still help

Related: sessions do not survive a restart either

Restarting the server never revives existing sessions — each start mints a new environment id, so sessions bound to the old one are unreachable and look broken.

They can be recovered: claude remote-control -c or --session-id <id> reattaches with history intact (the local transcript filename is a deterministic v5 UUID derived from the session id, so the same .jsonl is reused). But:

• neither flag combines with --spawn, so a spawn server cannot bring its own sessions back;
• -c resolves through bridge-pointer.json in the project directory, which for a spawn-server directory holds that server's own in-dir session rather than the one you want.

A supervised restart that re-adopted its previous sessions would make this seamless.

Environment

macOS 26.6.2 (25G83), Claude Code 2.1.234, native installer.