Remote Control: resuming a conversation replays a dead session binding, and /remote-control can only retry the doomed reconnect

Claude Code CLI version: 2.1.233
Platform: Linux (Ubuntu 24.04, arm64)

Summary

Remote Control is bound to the conversation, not the process. Resuming a conversation with --continue / --resume replays the Remote Control session id recorded in that transcript. If the process that owned it is gone — a crash, an OOM kill, a host reboot, a service restart — the reconnect fails and the session runs with no Remote Control.

/remote-control cannot recover it, because in a resumed session it only ever retries that same reconnect. The footer stays /rc failed indefinitely:

● Remote Control disconnected — Couldn't reconnect to your Remote Control session.
  Retry, or start a fresh session without --resume. — run /remote-control to reconnect

Steps to reproduce

1. Start a session with Remote Control: claude --remote-control — confirm /rc active.
2. Kill the process without a clean exit (kill -9, an OOM kill, or reboot the host).
3. Resume the same conversation: claude --continue --remote-control.
4. The session comes up with /rc failed and the message above.
5. Run /remote-control any number of times — it retries the reconnect and fails identically.

Workaround (undocumented, and it works)

The TUI already offers the fix, but only if you know to go looking:

/remote-control  →  Disconnect this session  →  /remote-control  →  1. Enable Remote Control

Disconnecting drops the dead binding; the second invocation registers a fresh Remote Control session. The conversation is preserved. This is the combination users actually want, and it is currently reachable only by hand.

Why this matters beyond one session

Any unattended launcher — a systemd unit, a boot service — must resume, or the user loses their conversation on every restart. But resuming is exactly what produces a dead binding, so those sessions come up started but unreachable, and the user discovers it later from their phone. In our case a systemd service launches t-claude --auto --remote-control for four accounts; after a host reboot every one of them was running fine locally and unreachable remotely, with no error anywhere except the footer.

The two failure modes also read almost identically in the UI, which makes triage hard:

| message | cause | recovery |
|---|---|---|
| Session creation failed | server-side (we captured 503 {"type":"overloaded_error"} during an incident — see #87211) | wait; nothing client-side helps |
| Couldn't reconnect to your Remote Control session | this bug: stale binding on a resumed conversation | disconnect, then re-enable |

Restarting the session "fixes" the second by accident (a fresh session registers cleanly) but destroys the conversation, which is the thing the user cared about.

Suggested fix

When a reconnect fails because the recorded session no longer exists, register a new Remote Control session automatically rather than looping on reconnect — or surface it as a one-keypress option in the failure notification, instead of requiring the user to discover Disconnect → re-enable. A flag such as --remote-control=new would also make this scriptable for unattended launchers.

Related

• #34531 — /rc cannot restore within same session (closed, behaviour still present in 2.1.233)
• #60790 — disconnected when resuming a session whose CLI owner is gone (closed, Desktop-focused; this report is the CLI path)
• #87211 — the other failure mode, Session creation failed / 503, which is server-side and unrelated