Remote control presence decays on backend while client websocket stays fully connected (device shows stale on phone/web despite healthy local connection)

What version of the Codex App are you using?
codex-cli 0.136.0 (latest as of 2026-06-02)

What subscription do you have?
Pro ($100/month)

What platform is your computer?
Linux — Ubuntu 22.04, x86_64 (behind NAT gateway)

---

What issue are you seeing?

After a period of idle (observed: ~40–60 minutes), the machine shows as stale/offline in the Codex phone app and web UI, even though:

• The managed daemon (codex app-server --remote-control) is running and healthy
• codex remote-control start --json returns {"status":"connected","timedOut":false}
• ss -ti shows the outbound websocket to the backend with traffic in the last few seconds (live ping/pong, not a dead NAT flow)

Every local signal says the connection is healthy. Only the phone/web UI reveals the actual backend state: the device is offline. The only recovery is restarting the daemon (remote-control stop + start), which forces re-registration and immediately brings the device back online.

This is a backend presence / registration decay issue — not a local connectivity issue. The websocket itself stays alive; something on the backend side stops reporting the device as available.

---

What steps can reproduce the bug?

1. Start the managed daemon: codex remote-control start --json → confirms status: connected
2. Confirm the device appears online in the Codex phone/web UI
3. Leave the machine idle (no active remote session) for ~40–60 minutes
4. Check the phone/web UI → device shows as stale / offline
5. Confirm the daemon is still running: codex remote-control start --json → still returns status: connected
6. Confirm the websocket is live: ss -ti on the outbound :443 connection shows recent lastsnd/lastrcv timestamps (seconds, not minutes)
7. Run codex remote-control stop && codex remote-control start --json → device immediately reappears as online in the phone/web UI

The discrepancy between steps 5–6 (client sees connected) and step 4 (backend shows offline) is reproducible consistently after ~40–60 min of idle.

---

What is the expected behavior?

A device whose websocket to the backend is actively exchanging keepalive traffic should remain visible as online in the phone/web UI indefinitely, without requiring periodic daemon restarts.

---

Additional information

Related issues: #24179, #23403, #24194 — this appears to be the same underlying mechanism reported across multiple configurations. The common thread is that remote-control start --json reporting connected is not a reliable indicator of backend-side device presence.

A workaround of periodically restarting the daemon (e.g. every 10 minutes) does keep the device visible, but at the cost of briefly disrupting any connected local sessions — not acceptable as a long-term solution.