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//.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//*.jsonl` files by content to find the right session ID, then run `claude --resume ` 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`

Start by reproducing the issue with `claude remote-control --spawn=same-dir`, then inspect the `claude --resume` picker and the session transcripts under `~/.claude/projects//.jsonl`. Compare how `entrypoint` values such as `sdk-cli` and `claude-vscode` affect discovery. Done means spawned sessions appear in the local picker and can be resumed, including through search and show-all-projects.

Written by the indexing model from the issue text.