Feature request: Session persistence & reconnection for Remote Control server mode

Status Fixed / completed

Maintainer reply None cached

Activity 7 comments · opened Mar 19, 2026 · closed Aug 17, 2026

Summary

When using claude remote-control in server mode, there is no way to persist or reconnect to sessions after the process restarts. This is a significant limitation for users running Claude Code on always-on servers (e.g., Mac Mini via tmux).

Current Behavior

claude remote-control --spawn same-dir generates a bridge URL (?bridge=env_xxx) and session URLs (/session_xxx)
If the claude process exits (crash, update, OOM, etc.), all session URLs become invalid
Restarting generates completely new bridge + session IDs
No way to resume a previous conversation via remote control — always starts fresh
Navigating away from a session in the mobile app (swipe/back) also loses the connection with no way to return (ref: #28402, #34531)

Expected Behavior

Session persistence: Spawned sessions should survive process restarts. The session state (conversation history, working directory) should be recoverable.
Stable reconnection URL: A mechanism to reconnect to a previously active session, e.g.:
claude remote-control --resume to re-register existing sessions
Stable session IDs that map to on-disk conversation state
Or at minimum, --resume + --remote-control combo that preserves the remote URL

Use Case

Running Claude Code on a headless Mac Mini server accessed from multiple devices (desktop, phone, Windows PC) via Tailscale VPN. The server runs 24/7 in tmux, but any process restart (updates, crashes, system reboot) forces all clients to reconnect to a brand new session with no history.

Environment

Claude Code v2.1.79
macOS (Darwin 25.3.0, Mac Mini M4)
Running in tmux, accessed via Remote Control from multiple devices

Suggested Approach

Persist session state to disk (conversation ID, bridge mapping)
On restart, re-register existing sessions with the bridge service
Clients reconnecting to old session URLs get routed to the restored session
Alternatively, allow --session-id flag to pin a stable identifier

This would make Remote Control viable for always-on server deployments.

View original on GitHub ↗

4 Comments

maticko · 4 months ago

without this feature, remote-sessions are basically useless as connection gets dropped or process errors way too often and without a user friendly way to resume the session it just makes it unusable

gritse · 3 months ago

+1, hitting this exact pain point. Running claude remote-control --name container --remote-control-session-name-prefix container as an OpenRC service on a headless Alpine VM (supervised by supervise-daemon so it auto-restarts on crash). Every supervisor respawn — and every host reboot — produces a brand new session ID; the in-flight conversation on claude.ai/code is unrecoverable, and the old session lingers as "connected" until it eventually times out.

The --session-id / --resume approach in the suggested fixes would solve this cleanly. A stable identifier per machine (or even an opt-in flag like --stable-session-id <uuid>) is the missing piece for any always-on server deployment.

Related: #34255 (auto-reconnect doesn't work mid-session), #34531 (state desync after disconnect), #29748 (closed as dup of #28402 but specifically about reboot survival).

Snailflyer · 3 months ago

This issue seems to come down to session identity being tied too tightly to the bridge/session URL rather than to the durable work surface.

For an official Remote Control fix, the stable thing probably needs to be something like a host/session identity that can be re-registered after process restart, with the old URL either reconnecting or clearly saying which local session can be resumed. Otherwise a headless Mac Mini / tmux setup still has the terminal process and disk state, but the mobile control surface loses the handle to it.

I have been working on a narrower open-source route where tmux is the durable handle instead of the remote-control URL: https://github.com/Snailflyer/faryo

Faryo keeps Claude Code/Codex/shell inside a named tmux session on the user’s machine, and the phone/desktop browser workbench reconnects to that live session layer for output review, short input, approve/interrupt, and handoff.

It is not a fix for Claude Remote Control’s bridge/session ID persistence, and it does not make a Claude Desktop session cloud-portable. The current strongest path is Linux + tmux + Claude Code/Codex CLI + Chrome/Android Chrome PWA. But it is designed around the same operational boundary this issue highlights: the local process/session should remain the source of truth, and the mobile surface should be reconnectable rather than becoming the identity of the work itself.

int19h · 1 month ago

Does anyone at Anthropic actually use claude remote-control in server mode? I can't believe this isn't fixed yet.

For those who run into this and need to recover your sessions, there is a way: ssh into the same box where you've been running claude remote-control and go to the same directory and then do --remote-control --teleport on the session ID (you can see it in the URL if you do Copy Link). Then immediately exit; you will get the --resume command that will resume that session, and this time --remote-control should actually surface it in all connected Claude client apps.

Meanwhile, Codex just works.

Showing cached comments. Read the full discussion on GitHub ↗