remote-control: resume/surface prior session for a directory on restart

[bdevore17]

Summary

When claude remote-control --spawn=same-dir runs as a persistent server (e.g. supervised in a tmux loop on a remote dev box) and the server process restarts — box reboot, supervisor relaunch, etc. — it always pre-creates a new session and points ~/.claude/projects/<dir>/bridge-pointer.json at it. The previous session's transcript persists on disk (~/.claude/projects/<dir>/<id>.jsonl) but is no longer surfaced as the active session in claude.ai/code, so users perceive their in-flight work as "gone."

The work is recoverable (claude --resume <id> in that directory, or the session picker), but not automatically, and the default/active session after a restart is always a fresh one.

Repro

1. Run claude remote-control --name X --spawn=same-dir --permission-mode auto as a long-lived server in a directory, supervised so it relaunches if it exits.
2. Connect from claude.ai/code, do substantial work in the auto-created session (transcript grows under ~/.claude/projects/<dir>/).
3. Restart the host / the RC server process.
4. The RC server comes back with a freshly pre-created session ("New sessions will be created in the current directory"). The prior session is on disk but not the active/surfaced one.

Request

A way for claude remote-control to resume or re-surface the most recent on-disk session for its directory on start. For example:

• a --resume-last / --continue flag for remote-control, or
• making the claude.ai/code session list rehydrate from on-disk transcripts for the server's cwd so prior sessions are selectable after a server restart.

Notes

remote-control --help currently exposes no resume/continue option (only --name, --remote-control-session-name-prefix, --permission-mode, --spawn, --capacity, --[no-]create-session-in-dir, --debug-file, --verbose).

Environment

• Claude Code v2.1.177
• Headless Linux dev box (Coder workspace), RC supervised in a tmux loop
• claude remote-control --spawn=same-dir --permission-mode auto

[dzshzx]

Confirming this on Linux (WSL2), and adding a concrete recovery detail.

Same symptom: a remote-control session ends up invisible in both /resume and the claude agents view once its process exits. On disk the transcript shows the bridge markers — repeated {"type":"bridge-session", ... "bridgeSessionId":"cse_..."} records and a last-prompt head — which is why the local resume picker doesn't surface it (it's treated as a bridged/cloud session, not a plain local one).

The work is fully recoverable: claude --resume <full-session-id> in the directory rehydrates it into a normal local session (verified — it resumes and responds). The gap is purely discoverability: neither the /resume picker nor claude agents lists these bridged sessions, so without grepping ~/.claude/projects/<dir>/*.jsonl for the id, users can't find them.

+1 on rehydrating the session list from on-disk transcripts for the server's cwd.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.