Remote control: mobile-to-desktop messages only delivered on a ~6-hour server-side cycle, never in real time

Summary

For a remote-controlled desktop session, messages composed in the Claude mobile app are accepted
and queued server-side immediately, but are NEVER pushed to the desktop in real time. They are
delivered in batches on an exact ~6-hour server-side cycle. Real-time delivery has never worked
on this install. User-visible effect: the desktop session waits for feedback indefinitely while
the phone shows the reply as sent, making remote control unusable for interactive feedback.

Evidence: two deliveries exactly 6h00m01s apart

• Message A: sent from iOS ~2026-07-18T17:25Z ("This is a message from my phone")

delivered 2026-07-19T04:38:48.937Z (latency 11h13m)

• Message B: sent from iOS 2026-07-19T07:15Z

delivered 2026-07-19T10:38:49.792Z (latency 3h24m)

• Delivery instants differ by 6h00m00.9s, implying a flush cycle anchored at :38:48Z + 6h.
• The intermediate cycle (2026-07-18T21:38Z) was likely missed because the laptop was asleep

(app log shows the device bridge reconnecting through the night), deferring message A to the
next cycle. This suggests the sweep requires the bridge to be connected at cycle time and
does not retry sooner.

• Desktop bridge_state was "connected" continuously during both send windows; no state change,

no errors, nothing logged at send time.

Environment

• macOS (Darwin 25.5.0), Claude desktop app 1.22209.0, bundled Claude Code CLI 2.1.209
• claude.ai subscription login; OAuth token cached with user:sessions:claude_code scope
• Cloud session: https://claude.ai/code/session_019sgkaewtwi4WRiyLQUnxwK
• Network verified clean: no proxy env vars, canonical ANTHROPIC_BASE_URL, system PAC returns

DIRECT for api.anthropic.com / claude.ai / bridge.claudeusercontent.com; the device websocket
(wss://bridge.claudeusercontent.com/devices/...) authenticates and rotates cleanly.

• Upsync (desktop to phone) works in real time throughout.

Hypothesis

The real-time push path from relay to the desktop bridge is broken for this account/device;
a periodic (~6h) server-side reconciliation sweep is the only delivery mechanism actually
functioning. The sweep proves queueing and injection both work end to end; only the push is dead.

Diagnosability

Nothing surfaces this on either end: the desktop has no log line for inbound delivery or its
absence (only bridge_state transitions), and the phone shows the message as sent with no
pending/undelivered indicator. A delivery-ack indicator on mobile would have made this
user-diagnosable.

Ask

Check the relay's real-time delivery path for the session/account above. Timestamps are precise
enough to correlate: sends at ~2026-07-18T17:25Z and 2026-07-19T07:15Z, deliveries at
04:38:48.937Z and 10:38:49.792Z. Predicted next cycle delivery: 16:38:50Z.

Possibly related: #60518 (one-way phone-to-CLI delivery failure).