codex - 💡(How to fix) Fix remote-control can get stuck after macOS sleep with 409 Conflict until enrollment is manually reset [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#23470Fetched 2026-05-20 03:49:24
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×5commented ×1

Error Message

  • after wake, reconnect attempts can fail with HTTP error: 409 Conflict

Root Cause

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.

RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING