Codex Cloud stuck on "Reconnecting... waiting for network" over VPN — Cloudflare 403/challenge on chatgpt.com/backend-api

Open 💬 0 comments Opened Aug 19, 2026 by Zombi3h3art

What version of the Codex App are you using (From "About Codex" dialog)?

26.814.41957

What subscription do you have?

ChatGPT Pro — signed in via ChatGPT account, not API key

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Cloud (background/remote) tasks in the Codex desktop app never connect — the task pane shows a repeating "Reconnecting... waiting for network" loop indefinitely and never starts.

Root-caused this to a Cloudflare bot-mitigation block on chatgpt.com/backend-api/codex, not a local network problem:

$ curl -sI https://chatgpt.com/backend-api/codex
HTTP/1.1 403 Forbidden
Cf-Mitigated: challenge
Server: cloudflare

Meanwhile api.openai.com (used by codex exec / local CLI sessions) responds normally (401 without auth, as expected), and codex exec itself works fine end-to-end. So this is specific to the chatgpt.com/backend-api surface that Codex Cloud requires ChatGPT-account auth to use.

This reproduces consistently while connecting through a VPN (NordVPN), across every server/mode tried:

  • Standard NordVPN server (multiple locations/subnets) — same 403/Cf-Mitigated: challenge
  • Obfuscated server (OpenVPN) — same result
  • Onion Over VPN — same result

Verified this is not a local MITM/cert issue: openssl s_client shows a valid Google Trust Services certificate for chatgpt.com with correct hostname/dates, and curl's own TLS verification passes (ssl_verify_result: 0). The 403 is coming from Cloudflare's edge, before the request reaches OpenAI's backend at all.

Likely underlying cause (per #17860): Codex's Rust client uses rustls on Windows/Linux, which produces a non-browser TLS Client Hello fingerprint (JA3/JA4) that Cloudflare's bot detection flags — compounded by a VPN exit IP's own reputation. macOS builds reportedly use native OS TLS (fingerprints as browser-like) and are less affected.

What steps can reproduce the bug?

  1. Connect to any VPN (reproduced with NordVPN — standard servers, obfuscated servers, and Onion Over VPN all fail identically).
  2. Open the Codex desktop app, signed in with a ChatGPT account (not API key).
  3. Start or resume a Codex Cloud / background task.
  4. Observe the task pane stuck on "Reconnecting... waiting for network" indefinitely.
  5. Confirm independently: curl -sI https://chatgpt.com/backend-api/codex returns 403 with Cf-Mitigated: challenge while connected to the VPN; curl -sI https://api.openai.com/v1/models returns a normal response over the same connection.

What is the expected behavior?

Codex Cloud should either connect successfully through a VPN, or fail with a clear, actionable error (e.g. "connection blocked, try disabling VPN" or a retry/backoff with a real error surfaced) instead of silently looping "Reconnecting... waiting for network" forever with no diagnostic info in the UI.

Additionally: since local Codex sessions already tolerate VPN traffic fine via api.openai.com, it would be ideal if Codex Cloud's chatgpt.com/backend-api traffic were equally robust to non-browser TLS fingerprints / VPN exit IPs — e.g. by using an OS-native TLS backend on Windows the way macOS builds reportedly do (see #17860), or by giving the desktop client a browser-realistic TLS fingerprint for this specific endpoint.

Additional information

  • API-key sign-in (codex login --with-api-key) is not a workaround for this, since Codex Cloud specifically requires ChatGPT account sign-in (per OpenAI's own docs) — it cannot run under API-key auth at all.
  • Confirmed not a NordVPN Threat Protection interception artifact: the certificate served for chatgpt.com during testing was genuinely Google Trust Services' cert, not NordVPN's Threat Protection root CA (which is installed in the local trust store for its unrelated ad/malware-filtering feature, but was not intercepting this connection).
  • Happy to provide local Codex desktop app logs (%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\) on request — they show remote-connections staying at 0 connections and no successful handshake, consistent with the request never getting past Cloudflare's edge.

---
Related issues (possibly the same root cause, on other platforms):

  • #17860 (Linux/WSL2 rustls TLS fingerprint → Cloudflare 403)
  • #18688 (macOS chatgpt.com/backend-api/codex/responses 403)
  • #18681 (403 forbidden, no repro info)

View original on GitHub ↗