Remote Control session stops working silently — needs application-level liveness check

Problem

Remote Control can enter a state where the transport-level connection (WebSocket/HTTP) appears healthy, but messages sent from the mobile client are not being delivered or processed. Symptoms:

• Status line shows "Remote Control reconnecting" instead of "active"
• Mobile UI shows "Thinking" indefinitely after sending a message
• Messages are silently dropped — they never arrive
• The heartbeat (heartbeat_interval_ms: 20000) reports no issues because the network connection is fine
• Only fix: manually restarting /remote-control

This was observed on Claude Code v2.1.81. The session had been active for several hours with concurrent terminal usage.

Root Cause

The current health monitoring only checks transport-level connectivity (heartbeat over WebSocket/HTTP). It does not verify that the application-level message delivery path is functional. When the delivery pipeline gets stuck (for whatever reason), the heartbeat still succeeds, so no recovery is triggered.

Proposed Solution

Implement an application-level challenge-response on the chat protocol:

1. Server periodically sends a lightweight challenge message through the same code path that user messages travel
2. Client must respond within a configurable timeout (e.g. 10-15 seconds)
3. If no response → the message delivery pipeline is stuck → automatically trigger a bridge reconnect/reset

This would complement the existing transport heartbeat by verifying end-to-end message delivery, not just network connectivity.

Environment

• Claude Code v2.1.81
• Linux (Ubuntu, AWS EC2)
• Remote Control accessed from mobile (Android)

🤖 Generated with Claude Code