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

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.