Table of Contents
The Symptom
If you use Codex regularly, you’ve likely seen this frustrating loop:
Reconnecting... 1/5
Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5Then a long pause — and suddenly Codex responds normally, as if nothing happened.
It looks like the model is overloaded, your account is broken, or the service is down. Often, the real cause is far simpler: a WebSocket networking problem.
Note: The exact configuration keys below reflect community-reported fixes. Codex’s config schema changes over time, so verify against the official Codex documentation before applying them.
Root Cause: WebSocket vs. HTTPS
By default, Codex prefers to talk to the server over WebSocket (WSS) — a protocol for real-time, two-way communication. When it works, it’s fast and interactive.
The problem: many proxies don’t forward WebSocket traffic correctly, even when they handle ordinary HTTPS fine.
Here’s the sequence behind the scenes:
| Step | What happens |
|---|---|
| 1 | Codex attempts a WebSocket connection |
| 2 | The proxy blocks or drops it → connection fails |
| 3 | Codex retries (up to 5 times) |
| 4 | All attempts fail |
| 5 | Codex falls back to standard HTTPS — which works |
That fallback is why everything “magically” starts working after the delay. The model isn’t slow and your account isn’t broken — WebSocket traffic simply never reached the server.
The Three Fixes — At a Glance
| Fix | Best for | Trade-off |
|---|---|---|
| #1 Disable WebSockets | Just want it to work now | Chats may regroup under a new provider |
| #2 Configure proxy | Cleanest long-term setup | Requires knowing your proxy port |
| #3 Enable TUN mode | Advanced users | Affects your entire system |
Fix #1: Disable WebSockets (Fastest)
Force Codex to use HTTPS from the start, skipping WebSocket attempts entirely.
Open your config file:
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
- macOS / Linux:
~/.codex/config.toml - Windows:
C:\Users\<username>\.codex\config.toml
Add this at the top:
model_provider = "openai_http"Then add this section:
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = falseSave and restart Codex.
Result:
- No repeated reconnect attempts
- Faster startup
- Predictable behavior behind proxies
Side effect: Codex groups conversations by provider, so older chats may appear under a different group. They aren’t deleted — reverting the setting brings them back.
Fix #2: Configure Your Proxy (Best Long-Term)
If you want to keep WebSocket support, make sure Codex knows how to reach your proxy.
Create an .env file:
- macOS / Linux:
~/.codex/.env - Windows:
C:\Users\<username>\.codex\.env
Add your proxy settings:
HTTP_PROXY="http://127.0.0.1:PORT"
HTTPS_PROXY="http://127.0.0.1:PORT"
NO_PROXY="localhost,127.0.0.1,::1"Replace PORT with your proxy’s actual port:
| Proxy tool | Typical port | Example |
|---|---|---|
| Clash | 7890 | http://127.0.0.1:7890 |
| v2rayN | 10808 | http://127.0.0.1:10808 |
The idea: if WebSocket traffic reaches the proxy correctly, Codex never has to fail and fall back.
Fix #3: Enable TUN Mode (Advanced)
Most modern proxy tools offer TUN mode, which creates a virtual network interface and captures traffic at the OS level — instead of per-application. This makes WebSockets, HTTPS, and other protocols “just work” automatically.
The catch: TUN mode affects everything, not just Codex:
- Internal corporate networks
- Local development services
- VPN configurations
- Database connections
- Other desktop applications
Treat this as a last resort, not your first move.
Which Should You Choose?
Need it fixed right now? -> Fix #1 (disable WebSockets)
Want a clean, proper setup? -> Fix #2 (configure proxy)
Comfortable with system networking? -> Fix #3 (TUN mode)Final Thoughts
When Codex cycles through “Reconnecting 5/5,” it’s tempting to blame the model or the service. Usually, it’s just Codex trying — and failing — to open a WebSocket before falling back to HTTPS.
Once you understand that, the fix is simple: disable WebSockets, fix your proxy, or enable TUN mode. Either way, you’ll spend less time watching reconnect messages and more time actually getting work done.
