[BUG] Desktop (SSH remote) restart spawns a fresh CLI with the same session id instead of resuming; one session id shared by concurrent sessions across all cwds

Summary

In Claude Desktop with an SSH remote environment, restarting a session does not resume it. The app kills the CLI and spawns a fresh one with no resume flag, and the new process gets the same session id, so it appends a new empty conversation (SessionStart:startup, parentUuid: null) to the existing transcript. The UI shows an empty chat and the model has no prior context. The transcript itself is intact.

A second, likely related problem: the Desktop app hands the same deterministic session id to almost every session on the host, across every working directory, concurrently.

Environment

• Claude Desktop 2.37337.1 (Windows) → SSH remote environment on Linux
• Remote CLI: ccd-cli/2.1.295, CLAUDE_CODE_ENTRYPOINT=claude-desktop
• Remote Control on, permission mode bypassPermissions

Evidence (from the remote host)

1. ~/.claude/remote/run/<id>/remote-server.log: the previous CLI exited with code 143, asked to end by this daemon (client); a new ccd-cli process starts ~65 s later. The string resume does not appear anywhere in the log.
2. New process argv (/proc/<pid>/cmdline): --output-format stream-json --input-format stream-json --effort=medium --model=… --permission-mode=bypassPermissions --replay-user-messages --plugin-dir=…. No --resume, --continue, --session-id or --fork-session.
3. Transcript ~/.claude/projects/<cwd>/<id>.jsonl: directly after the interrupted assistant tool_use row, the new process writes an attachment row with hookName: "SessionStart:startup" and parentUuid: null, and continues from it. That file now holds 5 independent roots (5 separate conversations since 2026-09-10) under one session id.
4. ~/.claude/sessions/*.json: three Desktop-launched CLIs running at the same time (two in one cwd, one in another) all report the same sessionId with different hostSessionId values. A fourth Desktop session on the same host got a different id, so it is not universal.
5. The same <id>.jsonl exists in 64 ~/.claude/projects/* directories: every project and worktree used from this Desktop environment since August. The id is version-5 shaped (xxxxxxxx-xxxx-5xxx-…), i.e. derived, not random.
6. ~/.claude.json projects[cwd].lastSessionId is an unrelated v4 id, so claude --continue in that cwd does not reach the Desktop transcript either.

Steps to reproduce

1. Desktop → SSH environment → open a session and chat for a while.
2. Start a long-running tool call.
3. Restart the session/CLI from the Desktop app while it runs.
4. The chat is empty and the model has no context. Check /proc/<new pid>/cmdline (no resume flag) and the transcript (SessionStart:startup, parentUuid: null, same file).

Expected

• Restart resumes the existing chain (emits SessionStart:resume) and the UI shows the history.
• Each Desktop session gets its own session id and transcript.

Actual

• Restart = kill + fresh spawn with the same id; a new empty conversation is appended to the shared file.
• One session id shared by concurrent sessions in different cwds, so transcripts from unrelated conversations interleave in one file and the files grow without bound (17 MB and 27 MB here).

Workaround

claude --resume <id> from a terminal in the same cwd restores the conversation (after relinking the orphan root, since the newest leaf is now the empty conversation).

Related

#72305 (closed as duplicate: Desktop creates an orphan empty-context session instead of resuming), #98120 (parentUuid: null root appended to an existing transcript), #83541 (worktree/project-dir keying on resume), #96628, #85798.