Knowledge base · TOPIC-02

Codex keeps reconnecting: what the symptom can—and cannot—tell you

Short answer: Reconnecting is a session symptom, not a root-cause verdict. Codex may have completed DNS, TCP, TLS, and initial HTTP work but lost the longer-lived application channel afterward.

OpenAI’s public network guidance says Codex uses secure WebSocket traffic for model sampling and streaming. RFC 6455 separates the opening handshake from the persistent data phase. Those are public protocol facts. Whether a particular reconnect came from local Wi-Fi, an intermediary timeout, TLS inspection, a route transition, or provider conditions remains unknown until the event is correlated with evidence.

What it proves—and what it does not

Repeated reconnects show that the client did not maintain the session it expected. A timestamped successful WebSocket handshake is observed reachability for that moment only. It does not prove a provider-wide outage, an account problem, or a defective proxy. A normal provider status page is provider-reported aggregate context, not proof that your local session was healthy.

Safe checks

1. Record reconnect timestamps and whether they align with sleep/wake or network changes.
2. Check official provider status separately.
3. Compare short HTTPS reachability with a bounded, approved WebSocket handshake.
4. Test one trusted alternate network without changing several settings at once.
5. Verify by keeping a real Codex workflow connected, not merely loading a page.

Tivor’s browser scanner shows browser-visible evidence but cannot inspect the native Codex process or its route. Open Probe V0.1 can establish supported earlier-layer DNS, TCP, certificate-validated TLS, governed anonymous HTTPS, and repeated short-window evidence. It does not measure WebSocket or long-lived Codex session continuity, and it does not silently upload results.