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

Open 💬 3 comments Opened Mar 19, 2026 by youngjin39

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

  1. claude remote-control --spawn same-dir generates a bridge URL (?bridge=env_xxx) and session URLs (/session_xxx)
  2. If the claude process exits (crash, update, OOM, etc.), all session URLs become invalid
  3. Restarting generates completely new bridge + session IDs
  4. No way to resume a previous conversation via remote control — always starts fresh
  5. 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

  1. Persist session state to disk (conversation ID, bridge mapping)
  2. On restart, re-register existing sessions with the bridge service
  3. Clients reconnecting to old session URLs get routed to the restored session
  4. 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 ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗