Desktop app can spawn a duplicate live session on terminal restart (Remote Control); window lifecycle undocumented

Summary

When a terminal-hosted session with Remote Control is interrupted (terminal app restart, or claude update requiring a restart), the macOS desktop app's window lifecycle is undocumented and has one dangerous edge: the app can spawn a second live session process continuing the same transcript, which then acts concurrently with the resumed terminal session.

Environment

• Claude Code CLI (current release channel; observed across an in-place claude update on 2026-08-18)
• macOS desktop app with Remote Control connected
• Terminal: Ghostty
• Workflow: one long-lived Ghostty window per session, each with its app window as the RC view

Observed behavior

1. Normal case (annoying but workable): terminal restarts → the app window bound to that session labels itself "This session is archived. Unarchive it to continue." The old window never reattaches; after claude --resume + /rc in the terminal, the app issues a new window for the same session, and the old one stays archived. Users must adopt the new window each time; names don't carry over.
2. Dangerous case (intermittent): on one restart, the app instead spawned a new local session process (auto-named <hostname>-local-<adjective>-<noun>, laptop icon) that continued the same conversation transcript as a separate live agent. Both the resumed terminal session and the app-spawned session were live simultaneously (both visible to each other via cross-session discovery). The duplicate proceeded to act on in-flight work (it merged a reviewed branch and posted comments) before we detected it and manually stood it down. Same transcript, two agents, no warning in either surface.
3. The archived window's "Open in → Terminal" menu item does nothing on a system where Ghostty is the terminal (presumably it targets the default terminal handler; no feedback either way).
4. A related surprise: archiving the duplicate window from the app emitted "Remote Control disconnected — this session was ended or archived from another device or app (code 4090)" in the healthy terminal session, i.e. archiving one window affected the other session's RC binding.

Expected behavior

• A terminal restart should never result in two live agent processes on one transcript. If the app can't reattach, it should offer resume-in-place or clearly mark the transcript read-only until the CLI resumes it.
• The docs (remote-control.md / sessions.md / desktop.md) cover sleep/network-drop and Ctrl+C, but not the crash/upgrade path or window reconciliation — documenting the intended lifecycle would help.
• "Open in → Terminal" should support the user's terminal (or at least report failure).
• Session names set via /rename should carry to whatever window/process continues the conversation.

Repro sketch

1. Start claude in Ghostty, /rename it, connect Remote Control (app window appears).
2. Kill the terminal app (or run claude update and restart).
3. Observe the app window archive itself; sometimes observe a new auto-named local session appear and continue the conversation as a second live process.
4. claude --resume in a new terminal → both sessions are now live on one transcript.

Impact

For multi-session/agent-team workflows (several named sessions coordinating via cross-session messaging), a silently spawned duplicate is a correctness hazard: it inherits the full context and authority of the original and can take real actions (git merges, API calls) concurrently.