Remote Control (--spawn=same-dir) sessions never appear in the --resume picker

Summary

Sessions created on-demand by claude remote-control (server mode, default --spawn=same-dir) are written to disk with "entrypoint": "sdk-cli" in their transcript. Sessions started interactively — plain claude in a terminal, or via the VS Code / code-server extension — get "entrypoint": "claude-vscode". The claude --resume interactive picker appears to filter out sdk-cli sessions entirely: they don't show up in the default view, with "show all projects" toggled, or via search by exact conversation content.

This breaks the core use case Remote Control is built for: start a conversation from the mobile app (or claude.ai/code) in a project directory, then continue it later from a normal terminal/IDE session in that same directory, on the same machine. The session exists, fully intact, on disk — there's just no way to discover or resume it from the local picker.

Steps to reproduce

1. On a VPS, in a project directory, run claude remote-control --name "Test" --permission-mode bypassPermissions as a persistent process (we ran it under systemd, Restart=always).
2. From the Claude mobile app (or claude.ai/code), connect to that directory and start a new session; send a message.
3. On the VPS, in the same directory, run claude --resume.
4. Observe: the session from step 2 is absent — not in the default view, not with Ctrl+A (show all projects), not via the search box (tested by searching exact words from the conversation, e.g. a distinctive noun that only appears in that one session).

Reproduced this identically across 3 different project directories.

Root cause, as far as we could trace it

Comparing ~/.claude/projects/<hash>/<session-id>.jsonl files in the same directory:

• A session started interactively (plain claude, or via the VS Code/code-server extension) has "entrypoint":"claude-vscode" on its early attachment/system lines, and shows up normally in --resume.
• A session spawned on-demand by claude remote-control (--spawn=same-dir, the default) is launched internally roughly as:

``
claude --print --sdk-url https://api.anthropic.com/v1/code/sessions/cse_XXXXXXXX \
--session-id cse_XXXXXXXX --input-format stream-json --output-format stream-json \
--replay-user-messages --resume=https://api.anthropic.com/v1/code/sessions/cse_XXXXXXXX \
--permission-mode bypassPermissions
`
Its transcript has "entrypoint":"sdk-cli" instead, and it's absent from --resume`, even via exact-text search.

What confirms this is specific to the spawn mechanism, not to Remote Control in general

Starting a plain interactive claude session (not through claude remote-control) in a directory causes Remote Control to auto-attach to it on its own — no /remote-control needed, it shows /rc connecting… then /rc in the status bar automatically. That session keeps entrypoint: claude-vscode and does show up correctly in --resume, from both the phone and the original terminal — same session, reachable and resumable from either side, exactly as expected.

So the underlying mechanism for "same session, visible everywhere" clearly works — it's specifically the --spawn=same-dir/worktree on-demand session creation path in claude remote-control that produces sessions excluded from local resume.

We considered working around this by keeping a persistent interactive claude session alive in each directory (via a tmux + systemd wrapper) instead of using claude remote-control as a standalone spawner, relying on the auto-attach behavior above. This reproduces the fix — but Claude Code's own safety classifier blocks the setup step (a systemd unit that keeps an unattended, bypassPermissions, auto-restarting interactive session running), flagging it as "Create Unsafe Agents." That's a reasonable guardrail on its own, but it means there's currently no supported way to get an always-on, phone-reachable session that's also resumable locally.

Impact

Anyone running Claude Code on a personal VPS and using Remote Control server mode to reach a project from a phone — the documented use case for claude remote-control — has conversations started from the phone stuck there. The only way to bring one back locally is to grep the raw .claude/projects/<hash>/*.jsonl files by content to find the right session ID, then run claude --resume <session-id> directly — not a workflow a non-technical user (or honestly most users) can be expected to discover or do.

Ask

Either:

• (a) Have claude remote-control's on-demand spawned sessions (--spawn=same-dir / worktree) show up in the local --resume picker (perhaps under a distinct label, if the sdk-cli entrypoint distinction needs to stay for other reasons), or
• (b) Provide/document an officially supported way to run a persistent, remotely-controllable session that isn't flagged by the "unsafe agent" classifier, so it stays resumable locally too.

Environment

• Claude Code version: 2.1.267 (build 2026-09-09T17:26:03Z, a9e1808c8204fef901336d54bac7d4ab442955cb); also observed on 2.1.268–2.1.272
• OS: Ubuntu 24.04.4 LTS, VPS (Hostinger)
• Remote Control running as a persistent systemd service (Restart=always), default --spawn=same-dir, --permission-mode bypassPermissions