[macOS Desktop] Codex stuck in “Reconnecting... waiting for network” while Browser Codex works; durable WebSocket closes with code 1006 #51399

Activity

1. Adonstein

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Oct 6, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Oct 6, 2026
3. github-actions commented on Oct 6, 2026

   

   github-actionsbot

   on Oct 6, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • macOS: Tasks assigned by dot cannot be opened; self-created tasks and regular conversations work normally #50813
   • [Windows][dot] Activity tasks cannot load: durable WebSocket 1006 / remote_unavailable while delegated execution works #50561

   Powered by Codex Action
4. Adonstein commented on Oct 6, 2026

   

   Adonstein

   on Oct 6, 2026

   Author

   More actions

   Thanks for the duplicate suggestions. I reviewed #50813 and #50561.

   They appear related at the transport level because all three reports involve the durable WebSocket closing with code 1006 before initialization.

   However, I don't believe my report is an exact duplicate yet:

   • macOS: Tasks assigned by dot cannot be opened; self-created tasks and regular conversations work normally #50813 is specific to macOS dot-assigned tasks that cannot be opened, while self-created cloud tasks and normal conversations reportedly still work.
   • [Windows][dot] Activity tasks cannot load: durable WebSocket 1006 / remote_unavailable while delegated execution works #50561 is a Windows issue involving dot Activity/task loading, while delegated execution itself remains available.
   • In [macOS Desktop] Codex stuck in “Reconnecting... waiting for network” while Browser Codex works; durable WebSocket closes with code 1006 #51399, the failure affects ordinary newly-created Codex Desktop conversations on macOS. No existing dot/delegated task is required to reproduce it.
   • A brand-new conversation with the minimal prompt "Reply with only OK" consistently enters:
     "Reconnecting... waiting for network"
     followed by:
     "Connection failed: error sending request"
   • Browser Codex works normally on the same Mac, account, network, and VPN.
   • The HTTPS Codex endpoint is reachable, but the Desktop durable WebSocket repeatedly closes with code 1006 before initialization.
   • The issue still reproduces after changing VPN nodes, testing System Proxy and TUN modes, resetting desktop state, updating, and fully reinstalling the desktop app.

   So the low-level durable WebSocket failure may share a root cause with those reports, but the affected product surface and reproduction are different.

   I'm happy for maintainers to consolidate this issue if they confirm the same root cause, but I will leave #51399 open for now.
5. nowhere1975 commented on Oct 13, 2026

   

   nowhere1975

   on Oct 13, 2026

   More actions

   Additional data point: a newer desktop build is still affected, and the durable transport has never once become ready

   Confirming the same symptom on a build newer than the one in the original report. I also have a nuance that may help narrow the root cause: in my case the HTTPS conversation transport keeps working while only the durable/cloud WebSocket is dead, which may explain why the "Reconnecting…" banner never clears.

   Environment

   macOS	27.0.1 (Apple Silicon)
   Codex Desktop	26.1007.30912 (build 20156)
   Build in original report	26.930.61225
   Proxy	HTTP/HTTPS 127.0.0.1:7890, SOCKS5 127.0.0.1:7890 (Clash/Mihomo)
   Auth	ChatGPT account

   hostId=durable has never reached ready — 9,003 attempts, 0 successes

   Aggregated across all 110 desktop log files (~/Library/Logs/com.openai.codex/), spanning 2026-09-30 → 2026-10-13:

   Date	Transport start success … durable	cause=connection_ready
   09-30	142	0
   10-01	485	0
   10-03	340	0
   10-04	228	0
   10-05	256	0
   10-06	1608	0
   10-07	1418	0
   10-08	809	0
   10-09	823	0
   10-10	589	0
   10-11	753	0
   10-12	462	0
   10-13	1090	0

   Totals over those files:

   Transport start success (durable)     9003
   cause=connection_failed_before_ready  9003
   cause=connection_ready                   0   ← never, not once
   closeCode=1006                        9000
   cause=transport_connect_failed          17
   

   So this does not look like a regression introduced by 26.930 → 26.1007; the transport has never come up in any log I have.

   Nuance: only the durable/cloud transport is broken — the HTTPS chat path is healthy

   In a single recent log file covering roughly 5 minutes of active use:

   response_routed                       1841
   Reasoning summary item completed       690
   
   app_server_connection.state_changed:
     cause=connection_failed_before_ready  442
     cause=transport_closed                442
     cause=connection_ready                  0
   

   The model responds normally and messages route fine, yet the UI stays on:

   Reconnecting... waiting for network
   

   With hostId=durable retrying codex-cloud-backend.chatgpt.com every 20 s indefinitely (reconnectAttempt=2067 was observed in one window). This suggests the desktop UI derives its connection state solely from the durable WebSocket, even when the HTTPS path is serving requests successfully.

   Log excerpt (typical cycle)

   19:38:46.653 [AppServerConnection] Transport start success connectionId=2068 hostId=durable transport=websocket
   19:39:01.655 [AppServerConnection] app_server_connection.state_changed cause=transport_closed closeCode=1006
   19:39:01.655 [AppServerConnection] app_server_connection.reconnect_scheduled baseDelayMs=20000 reconnectAttempt=2067
   19:39:01.656 [AppServerConnection] app_server_connection.state_changed cause=connection_failed_before_ready
   19:39:21.657 [AppServerConnection] app_server_connection.reconnect_started reconnectAttempt=2067 trigger=timer
   19:39:21.667 [AppServerConnection] Transport start success connectionId=2069 hostId=durable transport=websocket
   

   The lifetime is a consistent ~15 s before 1006, which looks like a fixed timeout rather than a random drop.

   Already ruled out on my side

   • Not the network path. The failure spans multiple independent network changes (two different ISPs/links, including a carrier 5G→LTE fallback event). During that worst period the HTTPS endpoint stayed 20/20 reachable at a consistent 0.82 s while the durable socket kept failing exactly as before.
   • Not DNS or routing. codex-cloud-backend.chatgpt.com resolves and matches DOMAIN-SUFFIX,chatgpt.com in the proxy rule set, so it is correctly sent to the proxy group rather than falling through to DIRECT. A plain request through the same proxy completes a normal TLS handshake (~0.6 s).
   • Not the proxy node. Switching egress nodes does not change the outcome (the OP reports the same for TUN vs system proxy and for full reinstalls).

   What might help maintainers

   If cause=connection_ready can never fire in this configuration, it would be useful to know what the durable transport requires beyond a working HTTPS path — e.g. a specific port/protocol, a feature flag on the account, or an additional hostname that must be reachable. The distinction between "HTTPS chat works" and "durable never ready" seems to be the key observable here.

   Happy to provide full logs, capture a packet trace, or run a diagnostic build.
6. taotiger commented on Oct 15, 2026

   

   taotiger

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   A potentially useful recovery path for this exact macOS Desktop symptom (Reconnecting... waiting for network, durable WebSocket code 1006 / open_timeout): inspect ~/.codex/config.toml before reinstalling or resetting the app.

   One affected user reports their ChatGPT/Codex desktop sessions (both existing and new Codex conversations) started working again immediately after following a config-focused fix. The steps they followed were:

   1. Back up ~/.codex/config.toml, then look for a stale top-level override such as openai_base_url = "http://127.0.0.1:PORT/v1", potentially left by an Ollama/local bridge/router integration. If present and no longer intended, comment it out or remove it.
   2. Where system proxy routing is needed, consider adding under [features] the exact key respect_system_proxy = true (singular, not respect_system_proxies).
   3. Fully quit and relaunch the desktop app.

   Outcome: the user reports the previously unusable desktop Codex/Work execution recovered. Caveat: they did not isolate which of these changes was decisive, so this is a reported combined troubleshooting path, not a confirmed root cause of every durable 1006 case. Do not remove deliberate custom endpoints without a backup.

   Related technical discussion: #40435 documents a stale localhost openai_base_url causing misleading reconnect errors; #39237 discusses the exact respect_system_proxy key and a confirmed macOS desktop improvement.
7. taotiger commented on Oct 15, 2026

   

   taotiger

   on Oct 15, 2026 – with ChatGPT Codex Connector

   Last edited by taotiger

   More actions

   Sharing a user-confirmed successful workaround for macOS ChatGPT Work/Codex desktop getting stuck at Reconnecting 5/5 / waiting for network, with durable WebSocket 1006 and open_timeout. The user's old and brand-new Codex conversations were affected. Reinstalling the app, clearing caches, and restarting did not help.

   What the user did (both changes together):

   1. Back up ~/.codex/config.toml.
   2. Find and comment out/remove stale custom openai_base_url overrides (for example, a localhost endpoint left by an Ollama/local bridge/router setup) if they are no longer appropriate:

      # openai_base_url = "http://127.0.0.1:12345/v1"

   3. Add under the existing [features] section (do not create a second duplicate section), if supported by your installed client:

      [features]
      respect_system_proxy = true

   4. Save, fully quit, and relaunch the macOS desktop app.

   Outcome: The reporting user confirmed on 2026-10-15 that after doing both #2 and #3, their issue was resolved immediately.

   Limitations: Because both configuration changes were made before retesting, we cannot isolate which change was necessary. We also cannot confirm that the stale custom endpoint was the direct cause of the durable WebSocket close: the issue may depend on client configuration or network handling. This is a user-reported workaround, not an upstream-confirmed fix. Inspect and back up config rather than deleting projects or conversation history.

   Further clarification from the same user (2026-10-16): prior proxy environment changes

   Before making the two config.toml changes above, the user had also run these commands (port 7890 was their local proxy endpoint):

   launchctl setenv HTTP_PROXY "http://127.0.0.1:7890"
   launchctl setenv HTTPS_PROXY "http://127.0.0.1:7890"
   launchctl setenv http_proxy "http://127.0.0.1:7890"
   launchctl setenv https_proxy "http://127.0.0.1:7890"
   launchctl setenv NO_PROXY "localhost,127.0.0.1"

   Chronology: Setting these environment variables alone did not resolve the failure at the time. The user subsequently changed both openai_base_url and respect_system_proxy in config.toml, then the app worked. It is not established whether the earlier launchctl setenv values remained in effect for the relaunched app and contributed indirectly when respect_system_proxy was enabled. Therefore this case is not evidence that only the two TOML edits are sufficient. These proxy commands are diagnostic context, not a universal recommended fix (a proxy must actually be listening on that port; environmental proxy choices are setup-specific). Avoid assuming causation without an isolated retest.
8. rkgutha commented on Oct 15, 2026

   

   rkgutha

   on Oct 15, 2026

   Last edited by rkgutha

   More actions

   Potential workaround: Disconnect Ollama's ChatGPT Desktop integration

   I started experiencing the same Reconnecting 5/5 — waiting for network issue on October 14, 2026. Codex briefly worked again in the evening, but the issue returned the next morning.

   What worked for me:

   1. Opened Ollama → Apps → ChatGPT (Desktop).
   2. Disconnected the ChatGPT Desktop integration.
   3. Completely quit and restarted Codex.
   4. Codex started working normally again.

   observations:

   • I did not modify ~/.codex/config.toml.
   • I did not add respect_system_proxy = true.
   • I did not reinstall Codex or Ollama.
   • The reconnection error disappeared after disconnecting the Ollama integration and restarting Codex.

   Sharing in case this helps others experiencing the same issue.