Remote Control server mode: push registration dies silently while socket stays connected (Windows)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Push registration drops silently while the relay socket continues to report healthy reconnects. The harness's PushNotification tool returns "Mobile push not sent (Remote Control inactive)" even though the server process tree is running and the console shows recent successful reconnects. Restarting the server process restores push delivery for a period, then the registration drops again within roughly an hour, with no corresponding error, crash, or distinguishing log line marking the drop. The relay socket and the push-registration state appear to be two different pieces of internal state that can diverge without any external signal.

What Should Happen?

With the server process alive and the relay socket reporting successful periodic reconnects, push notifications continue to reach the paired mobile device for as long as the server runs. If the underlying registration is going to fail, the failure is loggable and distinguishable from a healthy state, so an external supervisor (or the harness itself) can detect and correct it deterministically.

Error Messages/Logs

PushNotification tool return while the defect is active:
Mobile push not sent (Remote Control inactive)

Server console during the same window (periodic, N varies):
Reconnected after Ns

Steps to Reproduce

1. Start claude remote-control in server mode on Windows 11.
2. Confirm a mobile device is paired and a test push notification succeeds.
3. Leave the server process running unattended, with no interaction against the relay socket, for approximately one hour.
4. Trigger a scenario that would cause the harness to send a push notification (for example, a permission prompt or a completion notice) while away from the desk.
5. Observe the server's console/log: it continues to print periodic "Reconnected after Ns" lines and the process is alive, but the push send fails.

This is a best-effort reconstruction from observed behavior, not a controlled isolation test. The interval before the drop was not exactly one hour in every observed instance; see the evidence timeline in Additional Information.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.212

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

• OS: Windows 11 Pro, version 10.0.26200 (build 26200.8875) [verified this turn: cmd /c ver; systeminfo]
• Claude Code CLI: 2.1.212 [verified this turn: claude --version]
• A second installed CLI version (2.1.209) was also present under the user's Roaming app-data update path; the active PATH binary reports 2.1.212. Noting both in case the update channel matters to triage. [verified this turn: process/path inspection]
• Claude desktop app: 1.22209.0.0 (Microsoft Store package), observed running alongside the CLI during this session. This is the mobile-pairing/relay counterpart to Remote Control; its exact role in the push-registration failure below is not independently confirmed. [observed this turn, running-process inspection]
• Remote Control server mode invoked via claude remote-control, run as a long-lived background process. Both a direct foreground launch and a supervisor-relaunched instance were observed exhibiting the defect.
• Push notification delivery is routed through a paired mobile device via the harness's PushNotification tool.

Evidence timeline

Operator-session observations, 2026-07-17, local time, unless a disk artifact is cited directly:

• A prior server instance was born at 12:27 AM and ran with periodic "Reconnected after Ns" console lines through 17:50 the same day. [reported by operator]
• Push delivery was reported inactive from approximately 23:33 the previous night through the following morning, despite the server process remaining alive throughout. [reported by operator]
• A reconnect storm was observed in one instance: 18 reconnects in a single day, in clusters with gaps ranging from 1 to 44 seconds. [reported by operator]
• A fresh server start at 20:31 produced a clean first reconnect at 20:34. Push delivery was confirmed working from approximately 20:35 through 21:10, a delivery window of roughly 35 minutes. [reported by operator]
• Push delivery was reported inactive again by approximately 21:4x and remained inactive through the drafting of this report. [reported by operator]
• The Windows System event log was checked for the flap window using Get-WinEvent; no correlating network-adapter or power-state events were found. [reported by operator]. Independently re-checked this turn for the preceding 26 hours: the only Kernel-Power provider events fall between 12:46 AM and 12:53 AM, none in the 20:00-22:00 window where the reported evening drop occurred. [verified this turn: Get-WinEvent, System log]
• At 22:23:54 this session, an external supervisor script checked for a tracked, identity-verified claude remote-control process, found none alive, and started a fresh one. This is disk-verified evidence consistent with the drop-and-restart pattern described above: the server had gone untracked before this restart with no operator-visible error. [verified this turn: watchdog.log in the operator's local Remote Control supervisor directory]

Workaround note

An external watchdog process that health-checks the claude remote-control process (identity and log activity, on a fixed interval) and restarts it on silence or loss of a tracked process restores push delivery for a period after each restart. This is a mitigation, not a fix. It does not address the underlying silent drop, it requires the operator to build and run a separate supervisor script outside the harness, and it still leaves a gap between when registration actually drops and when the watchdog notices and restarts.

Impact

Remote Control's push channel is the mechanism a workflow-dependent operator relies on to know the harness needs attention while away from the desk. A silent, recurring loss of push registration, with the relay socket reporting healthy the entire time, gives the operator no reliable signal that notifications have stopped. Real alerts were missed during away-from-desk windows, which is the exact scenario the feature exists to cover.

Suggested next steps for maintainers

• Confirm whether the relay socket connection and the push-registration state are tracked as separate internal states, and if so, whether a socket reconnect is expected to re-arm push registration automatically.
• Add a loggable, distinguishable event when push registration is lost, separate from the existing socket "Reconnected after Ns" line, so the drop is visible without an external supervisor.
• Consider a periodic self-check inside claude remote-control that verifies push registration is live and re-registers if not, rather than requiring a full process restart.