Tivor.简体中文Run Free Scan
Menu

Knowledge base · TOPIC-01

Codex “Waiting for network”: what it means and what to check

Short answer: “Waiting for network” says that Codex does not currently have the application path it needs. It does not, by itself, prove that your Internet connection is down or that OpenAI has an outage.

What we can observe

A browser page loading successfully is useful evidence, but it tests the browser’s request path. OpenAI’s network guidance says some Codex functions use a secure WebSocket connection in addition to ordinary HTTPS. A WebSocket begins with an HTTP Upgrade handshake and then remains open as a bidirectional channel. A firewall, proxy, TLS-inspection product, or unstable route can therefore allow short web requests while disrupting Codex’s longer-lived channel.

That protocol distinction is provider-reported by OpenAI and defined by the WebSocket standard. The reason for one specific “Waiting for network” event remains unknown until it is measured.

What the symptom does not prove

It does not establish:

  • a provider-wide OpenAI incident;
  • an account or subscription problem;
  • that a VPN, proxy, DNS resolver, or firewall is at fault;
  • that the browser and Codex used the same IP family or route.

An official status page is also not a complete answer. It reports aggregate provider conditions; OpenAI notes that individual availability can differ by tier, feature, and path.

Safe checks

  1. Record the time and exact symptom. Do not copy credentials, cookies, or private report data.
  2. Check the official OpenAI status page for the Codex component. Treat that as provider-reported, not proof of your local path.
  3. Confirm whether ordinary HTTPS works. A valid response—even an authorization challenge—can show that DNS, TCP, TLS, and HTTP reached a responder, but it does not prove authorization.
  4. If you have an approved diagnostic, compare a bounded secure-WebSocket handshake with the HTTPS result. Do not probe arbitrary endpoints.
  5. Try one trusted alternate network. Change one variable at a time, then repeat the same check.

Tivor’s perspective

The diagnostic model keeps resolution, connection, TLS, HTTPS, WebSocket, address family, route context, and provider-reported status separate. Open Probe V0.1 currently measures the governed OpenAI DNS, TCP, certificate-validated TLS, anonymous HTTPS, and repeated short-window reliability layers. It does not measure WebSocket or compare IPv4 and IPv6 paths. A missing check stays incomplete; a timeout is not silently promoted to “OpenAI unavailable.”

The browser scanner cannot inspect a native Codex process, its certificate store, its route, or every long-lived session. Open Probe Public Beta supplies only its supported local, read-only evidence. Provider-path execution is explicit opt-in; local-only mode remains the default, with no silent upload or network mutation.

What to try, then verify

Use a trusted alternate network or ask the network administrator whether secure WebSocket Upgrade traffic and TLS validation are permitted for the documented Codex destination. Then verify by returning to the original workflow and confirming that a real Codex session remains connected—not merely that a web page opens.