Remote Control: concurrent client attach forks the session (Epoch mismatch 409), orphaning the previously-attached client

What's wrong

When the same live session is attached from two clients (e.g. Claude Desktop and the mobile app) and control effectively changes hands, Claude Code forks the session into a new id instead of reconciling. The newly-attached client continues on the new id; the previously-attached client is left on the old id, which becomes orphaned and archived.

User-visible: "the chat I was using on mobile died and got archived; Desktop carried on in a chat that no longer receives my mobile messages."

Forensic evidence

Host ~/.claude/remote/run/*/remote-server.log (UTC) at the moment of the fork:

16:03:46  ccd-cli (session 91a0fd0b-...) killed -- SIGTERM (exit 143)
16:03:54  respawn: --resume 91a0fd0b-... --fork-session --resume-session-at c14840f1-...
          -> a NEW session id is minted; the old id is orphaned

A --debug-file capture of the takeover shows the mechanism:

CCRClient: Epoch mismatch (409), shutting down
[bridge:repl] CCR v2: epoch superseded (409) -- closing for poll-loop recovery

Expected behavior

Multiple clients attaching to one live session should reconcile to a single driver with N viewers, not fork. If a fork is genuinely unavoidable, the previously-attached clients should be migrated to the surviving id rather than orphaned on a dead, archived one.

Steps to reproduce

1. Create a session on Desktop with Remote Control enabled.
2. Open the same session on the mobile app and interact from it while Desktop is still attached.
3. Observe the session fork: mobile ends up on an orphaned/archived id while Desktop continues on a new one.

Environment

• Claude Code: interactive CLI 2.1.173; Desktop-managed remote sessions (~/.claude/remote/ccd-cli/) 2.1.170
• Host: Hetzner KVM vServer, Linux (clock on UTC)
• Clients: Claude Desktop (macOS) via built-in SSH; Claude iOS app
• Plan: Max 5x