Remote Control: long-idle desktop-app sessions go stale — mobile shows "Connected" but submitted prompts silently vanish after ~60s

Environment

• Claude Code version: 2.1.204
• Platform: Windows 10 Home 10.0.19045, Claude Code desktop app (local sessions)
• Client: Claude Android app (com.anthropic.claude), also reproduced via claude.ai on mobile browser
• Setup: ~20 local sessions on one desktop, most launched automatically by scheduled tasks each morning; user monitors/steers them remotely from a phone

Symptoms

Two related failures in Remote Control links to desktop-app sessions, observed 2026-07-13 (and previously on 2026-06-27–28, same setup):

1. Idle sessions drop to "Disconnected" and never re-establish on their own.
Sessions that finish a turn and then sit idle for several hours (in this case ~8h) show "Disconnected" in the mobile session list. The underlying session is fine — its state is intact, and an inter-session message (session-management MCP send_message from another local session) wakes it instantly and it processes normally. Sessions with recent activity keep their links; the correlation with long idle is strong but not perfectly deterministic (one session held its link through 9h idle).

2. Worse: sessions showing "Connected" silently reject prompts sent from mobile.
After the stale sessions were woken locally (fresh activity, list shows Connected), prompts submitted to them from the mobile app appear in the chat, hang for ~60 seconds, then disappear from the transcript — the optimistic UI rolls the message back. No error shown. The prompt never reaches the session (verified by reading the target session's transcript from another session: the user message never arrived).

Meanwhile a freshly created session works perfectly from the same phone, same network, at the same time — full round-trip, no losses. So the phone→cloud→desktop path is healthy; the per-session inbound channel for the older sessions is what's broken, even while the UI reports "Connected".

Expected

• Idle local sessions keep (or transparently re-establish) their Remote Control link.
• If a session's inbound channel is dead, the UI should say so rather than showing "Connected" and silently dropping submitted prompts.
• A submitted prompt should either deliver, queue for retry, or fail loudly — not vanish after a minute.

Notes / adjacent issues

• Anthropic status page showed all-operational at the time (only unrelated resolved incident that day).
• Looks related to the stale-mobile-connection family: #34119 (stale connection after compaction, no way to reconnect from mobile) and #28758 (mobile can't connect to a running session). This report differs in that the list UI claims "Connected" while inbound delivery silently fails, and that long-idle appears to be the trigger.

Workarounds found

• Waking a stale session via another session's send_message (local path) restores outbound visibility (its replies/status show on mobile) but does not repair mobile→session inbound delivery.
• Relaying user input through a freshly created session (which asks the target session to act, via the session-management MCP) works reliably.
• Restarting the desktop app presumably remints all links, but is a poor option when the user is remote — if the app doesn't come back, every session is stranded until physical access.