openai / openai/codex

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

Open
#39,324 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug connectivity remote windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

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)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the VPN case with the documented curl checks against chatgpt.com/backend-api/codex and api.openai.com, then review the related issue #17860. Inspect the Codex logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs. Done means Codex Cloud either connects through the VPN or surfaces a clear actionable error instead of looping indefinitely.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
networking
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.