Remote 0.2.47 can report online/pong while all execution tools return Not connected

Summary

Remote Desktop Commander 0.2.47 can enter a false-healthy state where the control plane looks healthy but the execution data plane is unusable.

Observed from a ChatGPT Remote MCP connector on Windows:

• list_devices: device is online
• auth_token: valid
• capabilities include app_version: 0.2.47 and transport_broadcast_v1: true
• last_seen continues to advance
• ping: returns pong
• execution tools such as read_file, get_config, start_process, and get_recent_tool_calls: return Not connected
• during the same incident, shutdown can intermittently return No devices available even while list_devices says online
• after the transport briefly recovered, shutdown reached the device and cleanly set it offline; this confirms a half-open / control-plane-data-plane divergence rather than an authorization or permission failure

Why ping is not a sufficient health probe

MCPDevice.handleNewToolCall() handles ping directly in the remote device process. It does not exercise DesktopCommanderIntegration.callClientTool() or the local stdio MCP connection. Therefore pong proves only that one remote-delivery path reached the device process; it does not prove that file/process tools are executable.

DesktopCommanderIntegration sets isReady = true after the initial stdio connection. callClientTool() catches and rethrows failures but does not invalidate isReady, reconnect the stdio transport, retry once, or terminate the remote agent so an external supervisor can restart it.

The Broadcast/Presence transport can also produce contradictory observations when presence/capability state and the legacy/device row diverge: one API can still list the row as online while dispatch resolves no usable target.

Requested behavior

1. Replace or supplement ping with a structured end-to-end readiness probe that traverses the local MCP data plane, for example mcpClient.listTools() with a short timeout.
2. Publish separate health fields such as:
   • remote channel reachable
   • presence tracked
   • local stdio MCP connected
   • local tools count
   • last successful forwarded tool timestamp
   • connection generation
3. On Connection closed, Not connected, or equivalent transport errors in callClientTool():
   • serialize recovery with a single-flight guard
   • close stale client/transport with bounded timeouts
   • re-run initialize()
   • retry only the same read-only probe/tool once when safe
   • otherwise mark execution readiness false and exit non-zero or expose an explicit restart signal
4. list_devices and dispatch should not report a device as execution-ready solely from row status, token validity, heartbeat, or remote pong.
5. Add a regression test for this exact matrix:
   • remote agent and heartbeat alive
   • local stdio child disconnected
   • ping succeeds
   • ordinary tool fails
   • watchdog/reconnect restores ordinary tool execution without manual intervention
6. Add a consistency test ensuring list_devices, shutdown, and ordinary dispatch resolve the same effective device generation during presence degradation.

Impact

A watchdog that trusts ping, TCP 443, process presence, token validity, or last_seen will classify the device as healthy forever. The user sees repeated Not connected errors and must manually restart the agent, defeating unattended recovery.