›_ Codex Issues
Codex Issues / #23470

remote-control can get stuck after macOS sleep with 409 Conflict until enrollment is manually reset

Open 💬 4 comments Opened May 19, 2026 by clclo121
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

After my Mac wakes from sleep, Codex remote control can stop working even though the machine is awake and connected to the network.

The failure mode I observed is that the remote-control websocket keeps retrying and returns 409 Conflict. When that happens, mobile remote control cannot reconnect. In practice, the connection only recovers after deleting the headless remote-control enrollment and starting codex remote-control again.

From local inspection, the stale state appears to be tied to the headless enrollment entry where app_server_client_name = ''. The issue seems different from normal network loss because the machine is online, Codex is running, and the reconnect attempts continue, but the server still rejects the session as if an old app server were still active.

Relevant local observations:

  • codex remote-control exists and starts normally
  • after wake, reconnect attempts can fail with HTTP error: 409 Conflict
  • manual recovery works by removing the headless remote-control enrollment and re-enrolling
  • the problem affects remote control usability from mobile after sleep/wake

Environment:

  • Codex Desktop: 26.513.31313
  • CLI in app bundle: codex-cli 0.131.0-alpha.9
  • standalone CLI: codex-cli 0.130.0
  • macOS: 15.1.1
  • architecture: arm64

What steps can reproduce the bug?

  1. Start Codex remote control on macOS.
  2. Confirm remote control is working from mobile.
  3. Put the Mac to sleep.
  4. Wake the Mac and wait for network connectivity to return.
  5. Try to reconnect from mobile or allow the remote-control process to reconnect automatically.
  6. Observe repeated reconnect failures with 409 Conflict.

Manual recovery that worked locally:

  1. Stop the headless remote-control process.
  2. Remove the headless remote-control enrollment from local state.
  3. Start codex remote-control again.
  4. A new enrollment is created and the websocket connects successfully.

What is the expected behavior?

After macOS wakes from sleep, remote control should either:

  • reconnect automatically using the existing enrollment, or
  • detect the stale enrollment and transparently create a fresh one.

It should not remain stuck in a persistent 409 Conflict state that requires manual local cleanup.

Additional information

Local investigation suggests the reconnect path may be reusing stale remote-control enrollment state after sleep/wake.

Observed local state patterns:

  • there can be a separate headless enrollment with empty app_server_client_name
  • reconnect failures appear on wss://chatgpt.com/backend-api/wham/remote/control/server
  • manual re-enrollment immediately restores connectivity

This report is intentionally scoped to the sleep/wake reconnect failure, not to broader remote-control stability issues.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23339
  • #23112
  • #23403

Powered by Codex Action

clclo121 · 3 months ago

duplicate

agustinustheo · 3 months ago

I think this issue is a duplicate of this one.

huglyfe · 3 months ago

Additional data point: headless Linux (Raspberry Pi) — same silent dropout, both foreground and daemon paths

I'm running codex-cli 0.133.0 (standalone install) on a Raspberry Pi 5 (Linux 6.18.29+rpt-rpi-2712 aarch64) as a persistent headless remote-control host under user-level systemd. ChatGPT Pro subscription.

What happens:

  • After starting remote control, the host appears in the ChatGPT mobile app and works normally.
  • After a variable period (minutes to tens of minutes), the host silently disappears from the mobile app.
  • The process remains running, the TCP connection to the relay stays established, and codex doctor reports all-green the entire time.
  • Restarting the service temporarily recovers visibility, but it drops again.

Tested both remote-control paths — same result:

| Path | Command | Outcome |
|------|---------|---------|
| Foreground (systemd-supervised) | codex remote-control --json | Reports "status":"connected" once, never updates. Silently goes stale. |
| Daemon (codex-managed) | codex remote-control start | Starts app-server --remote-control + daemon pid-update-loop. Also silently goes stale. |

Key difference from the macOS report: This host has no sleep/wake cycle, stable network (Tailscale + Ethernet), and 2+ days uptime. The remote-control session still becomes stale server-side without the CLI detecting or reporting the disconnect.

Diagnostics while "connected" but invisible in mobile app:

codex doctor v0.133.0 · linux-aarch64
14 ok · 0 warn · 0 fail → ok
websocket: connected (HTTP 101) · auth: chatgpt
app-server: running (persistent mode)
$ ss -tnp | grep codex
ESTAB  0  0  192.168.1.233:50464  172.64.155.209:443  users:(("codex",pid=175495,fd=10))
$ cat ~/.codex/app-server-daemon/settings.json
{"remoteControlEnabled": true}

No errors in any Codex log. No 409 Conflict visible client-side — the stale state appears to be entirely server/relay-side.

Systemd unit (daemon path):

[Unit]
Description=Codex Remote Control
After=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=~/.local/bin/codex remote-control start
ExecStop=~/.local/bin/codex remote-control stop
Environment=PATH=~/.local/bin:/usr/local/bin:/usr/bin:/bin

[Install]
WantedBy=default.target

This suggests the relay silently drops enrollment after some idle period and the client has no keepalive or re-enrollment mechanism to recover.