Remote Control does not auto-reconnect after a network interruption

Remote Control does not auto-reconnect after a network interruption

Claude Code version: 2.1.215 (latest, confirmed via npm view @anthropic-ai/claude-code version)

Environment

• Claude Code running inside a code-server (VS Code Web) Docker container on a Synology NAS (DS224+, DSM 7.4)
• Mobile client: Claude iOS/Android app, using the in-app "Remote Control" feature (started via /remote-control in the CLI, paired via the generated URL)
• Network: home broadband, NAS on LAN, phone alternating between home Wi-Fi and mobile data when away

Steps to reproduce

1. Start claude in a terminal on the NAS (via code-server), run /remote-control, and pair the phone app using the generated link.
2. Work normally through the phone app's Remote Control session for a while.
3. At some point during use, the Remote Control connection silently drops (no chunks / stream idle timeout observed on related API errors).
4. Wait — the session does not reconnect on its own, even after the underlying network recovers (confirmed independently: the NAS's outbound connectivity to api.anthropic.com recovers within seconds in normal operation).
5. The only way observed to restore the Remote Control session: return to the same LAN as the NAS and open the code-server web UI (http://<nas-ip>:8080) in a browser. Immediately after that, the phone app's Remote Control session reconnects to the same underlying session.

Expected behavior

Per the CHANGELOG ("Fixed Remote Control task status updates being lost when the connection recovered from a network interruption or credential refresh"), Remote Control is expected to recover automatically once network connectivity is restored, without any manual interaction with the host machine.

Actual behavior

• The claude CLI process on the host is never killed or restarted during this — verified via ps -o pid,etime,cmd showing 23h+ continuous uptime for the same PID across multiple reported disconnects.
• Despite the process staying alive and host network connectivity being confirmed healthy again, the Remote Control channel itself does not automatically resume.
• Recovery only happens after some other, unrelated connection/interaction reaches the host (in this case, opening the code-server web terminal on the same LAN) — suggesting the Remote Control reconnect logic is not proactively retried, and instead may only get triggered by some other activity touching the session.

Supporting diagnostics already gathered

• Outbound connectivity from the host to api.anthropic.com is stable >95% of the time, with rare (~4%) full connection stalls (curl timing out after 15s with no TCP handshake completed) — consistent with an occasional real network blip, not a persistent misconfiguration.
• No proxy, no unusual DNS, no resource starvation (idle CPU, 12GB+ free memory) on the host at time of testing.
• claude --version matches the latest published npm version, so this is not fixed by upgrading.

Ask

Could the Remote Control client/session include a proactive reconnect/retry loop (with backoff) that doesn't depend on unrelated activity reaching the host machine? Right now the only reliable recovery path requires physically returning to the same network as the host and interacting with it through a completely different channel (code-server web UI), which isn't practical for the intended "control my machine from anywhere" use case.