[BUG] CLI: claude --remote-control ... --resume <uuid> hangs indefinitely (no error, no exit) when local conversation exists but the Remote Control session has expired

Environment

• Claude Code CLI v2.1.210
• Linux, headless (no Desktop app involved). Reproduced with a PTY present

(via script -qc), so this is independent of, and unrelated to, the
separate "no PTY at all" --print-fallback bug reported alongside this one.

• Auth: claude.ai subscription login (not API key)

Summary

When resuming a local conversation via claude --remote-control "<name>" --resume "<local-session-uuid>", and the Remote Control session previously associated with that conversation has expired server-side (while the local .jsonl conversation file still exists and is valid), the process hangs indefinitely. It does not error, does not fall back to a fresh Remote Control session, and does not exit. Only SIGKILL terminates it.

Steps to reproduce

1. Start claude --remote-control "<name>" with a real PTY (e.g. via script -qc '...'), have a short conversation so a ~/.claude/projects/<project>/<uuid>.jsonl file with real history exists.
2. Terminate that process (not a graceful exit) and let enough time pass that the Remote Control session tracked server-side by claude.ai is no longer valid.
3. Run claude --remote-control "<name>" --resume "<uuid>" again, non-interactively via a PTY shim (e.g. script -qc '...' logfile, stdin from /dev/null) — a real pseudo-terminal is present, just no human at the other end.
4. Observe: the process starts, replays the local conversation content into its (non-existent) terminal output, then stalls before reaching the "/remote-control is active" status line.

Observed behavior

• ps//proc/<pid>/status: process state S (sleeping), wchan = ep_poll, several open sockets — alive from the OS's point of view, but produces no further output.
• Waited >60 seconds with zero progress (no new log output, no state change).
• No error message of any kind.
• Only kill -9 ends the process; a graceful stop was not separately isolated (we went straight to SIGKILL after confirming no progress).

Contrast cases (both work correctly, confirming this is specific to the "expired but locally-known session" case)

• --resume with a UUID that never existed: fails fast and cleanly — No conversation found with session ID: <uuid>, exit code 1, well under 1s.
• --resume with a valid UUID whose Remote Control session is still fresh/unexpired: works correctly — full history restored, reaches "active" status with a new Remote Control URL in ≤6s.

Expected behavior

Per the Troubleshooting doc ("Couldn't reconnect to your Remote Control session"), the expected outcomes are: an explicit reconnect-failure message, the local session continuing without Remote Control, or automatic creation of a fresh Remote Control session once the server confirms the old one is gone. None of these occurred — instead, a silent, indefinite hang.

Impact

This makes --remote-control ... --resume <uuid> unsafe to use in unattended/automated contexts (e.g. a systemd service with Restart=always) for the very case it would most plausibly be used for — resuming after an unattended crash/restart where the previous Remote Control session has since expired. The process doesn't exit, so process supervisors never detect a failure; it just silently occupies a slot forever.

Related (found while searching for duplicates before filing)

• #39970 — Desktop-app-focused, closed as "not planned", touches on remote session resume/timeout but not this specific hang.
• #60790 — Desktop-app-focused, closed as duplicate, same broader "waits indefinitely instead of failing/reconnecting cleanly" pattern but a different code path (Desktop bridge, not CLI --remote-control --resume).

Neither covers the CLI-only case described here. Filed alongside a separate, independent bug: the implicit --print-fallback when no PTY is present at all — that one is unrelated to this hang (this hang reproduces even with a PTY present via script).