CodeX Stuck on “Reconnecting 5/5”? Stop Blaming the Model—Here’s How to Skip WebSocket and Go Straight to HTTP

You ask CodeX to change one line of code. Instead of editing, it spends 30 seconds showing “Reconnecting 1/5 … 5/5”, then “Thinking…” for a while longer. You stare at the terminal: is it deep in reasoning, or just stalling?

It’s neither. The model hasn’t even started. The network layer is busy retrying a path that won’t work—five times, back to back—before it finally falls back to a working connection. Your internet speed isn’t the problem. The culprit is your proxy, your VPN node, or your corporate firewall that doesn’t handle WebSocket handshakes cleanly.

CodeX prefers WebSocket by default. That’s great for real‑time streaming and long‑running tasks, but if any hop along the way drops the connection, you pay the price: five retries, then a fallback to plain HTTP. Only then does the model actually start processing your prompt.

The fix is brutally simple: tell CodeX to stop trying WebSocket first, and use HTTP / Responses directly. Skip the retry dance and save 10–30 seconds per request.

What’s Actually Happening Under the Hood?

Most people blame server overload when they see the reconnection loop. But if you switch to a mobile hotspot and everything speeds up, you’ve just proved it’s not the model—it’s your network path.

In plain terms, CodeX talks to the server in one of two ways:

• ✦

  WebSocket – keeps a persistent connection, great for multi‑turn conversations, tool calls, and streaming. But it’s picky: proxies that don’t forward wss:// properly, firewalls that drop long‑lived connections, or flaky nodes can all break the handshake.

• ✦

  HTTP / Responses – the old‑school request‑response model. It’s less real‑time but works almost everywhere, as long as your network can reach the endpoint. No special handshake, no persistent tunnel.

CodeX’s default strategy is: try WebSocket first, and if it fails after 5 retries, fall back to HTTP. Those 5 retries are what you see as “Reconnecting 1/5 … 5/5”. Each retry has a timeout, so you lose seconds even before the model wakes up.

Once you know that, the solution writes itself: disable the WebSocket priority and go straight to HTTP. You won’t lose functionality—tool calls and multi‑turn conversations still work perfectly—you just remove an unnecessary failure loop.

Step‑by‑Step: Add an HTTP Provider and Turn Off WebSocket Preference

Modifying the config is straightforward, but a few small mistakes can make the change ineffective. Follow these steps carefully.

1. Locate Your Config File

CodeX stores its settings in config.toml. The path depends on your OS:

• ✦

  Windows – C:\Users\YourUsername\.codex\config.toml
  Quick access: type %USERPROFILE%\.codex in File Explorer, then open config.toml.

• ✦

  macOS / Linux – ~/.codex/config.toml

If you’re unsure, just ask CodeX directly (it’s surprisingly helpful):

“Please locate my CodeX config.toml file path and only output the path, do not modify anything.”

It will return the exact location.

2. Back It Up—Seriously

Before touching anything, copy config.toml to config.toml.bak in the same folder. Or paste the contents into a text file and save it. This is your safety net—if you break the config and CodeX won’t start, restore the backup and you’re back in business.

3. Add the HTTP / Responses Provider

Open config.toml with your favourite text editor. Do not overwrite existing settings. Just add a new provider section and change the top‑level reference.

Here’s the snippet to add:

model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

What each line means:

• ✦

  model_provider = "openai_http" – tells CodeX to use this provider by default. Place this at the top (or in the global section) of the file.

• ✦

  [model_providers.openai_http] – defines a new provider named openai_http. The name in square brackets must match the value you put in model_provider. If they differ, the config is ignored.

• ✦

  wire_api = "responses" – uses the newer Responses API rather than the legacy completions endpoint. This is the recommended setting.

• ✦

  requires_openai_auth = true – keeps your OpenAI / ChatGPT login credentials. Leave it as true unless you use a different authentication method.

• ✦

  supports_websockets = false – the magic line. It tells CodeX that this provider does not support WebSocket, so it won’t even try. The client goes straight to HTTP.

Common pitfall: You write model_provider = "openai_http" but the provider section is [model_providers.chatgpt_http]. They don’t match, so CodeX falls back to the default (which still tries WebSocket). Double‑check the spelling and case.

4. Restart CodeX

Save the file, close the current CodeX terminal, and open a fresh one. Launch CodeX again.

Now send a quick test:

“Reply with one sentence: CodeX connection test successful.”

Watch the output. If you don’t see the “Reconnecting 1/5 …” sequence and the reply comes straight away, your config is working.

If it still shows the retries, don’t panic—go to the troubleshooting section below.

Don’t Want to Edit the File Yourself? Let CodeX Do It

If you’re uncomfortable editing config.toml by hand, you can give CodeX a prompt and let it modify its own configuration. Copy this exact message:

Please check and modify my CodeX config to reduce the “Reconnecting 5/5” issue.

Requirements:

1. Locate my ~/.codex/config.toml file.
2. Back it up as config.toml.bak first.
3. Do not delete any existing settings.
4. Add a new provider named openai_http.
5. Set wire_api = "responses".
6. Set supports_websockets = false.
7. Keep requires_openai_auth = true if I’m using OpenAI/ChatGPT auth.
8. Tell me what changes you made.
9. Finally, ask me to restart CodeX and test.

CodeX will read the file, back it up, add the new provider, and update the top‑level reference. You only need to restart.

Still Seeing “Reconnecting 5/5”? Follow This Debug Checklist

The trick isn’t magic—it works for many, but not everyone. If you still see the reconnection loop after applying the change, go through these items in order.

① Verify the Configuration Actually Took Effect

Re‑open config.toml and check:

• ✦ model_provider = "openai_http" matches the provider name exactly.
• ✦ supports_websockets = false is present and not commented out (no # at the start).
• ✦ The file was saved properly—some editors add a hidden .tmp version, so ensure the real file is updated.

Also, if you have multiple model_provider lines (e.g., one in a project‑specific config), CodeX may use the more specific one. The global config is usually sufficient, but verify which file is actually loaded.

② Upgrade CodeX to the Latest Version

Older releases might have bugs in the fallback logic or incomplete support for supports_websockets. If you installed via npm:

npm install -g @openai/codex@latest

For other package managers, use their upgrade commands. After upgrading, restart and test again.

③ Check Your Proxy and Network

This is the most common hidden culprit. Even with supports_websockets = false, some internal CodeX flows may still attempt a WebSocket connection for specific tool calls (though less likely). If your proxy is flaky with WebSocket handshakes, you might still experience delays.

Quick tests:

• ✦ Switch from PAC mode to global proxy mode.
• ✦ Change your VPN node—some regions have poor WebSocket routing.
• ✦ If you use Clash, Surge, or similar, look for rules that intercept wss:// traffic and adjust them.
• ✦ Temporarily disable your firewall or security software to see if it makes a difference.
• ✦ Try a mobile hotspot. If the issue disappears, it’s 100% your network path.

Many proxy tools handle HTTPS fine but struggle with WebSocket upgrades—especially when you have multiple proxy layers. In those environments, even with the config change, some background operations might still trigger WebSocket attempts, leading to intermittent hangs.

④ Start a Fresh CodeX Session

Sometimes an existing terminal session caches the old provider or loads a stale context. Close the terminal, open a new one, cd into your project, and launch CodeX again. Test with a brand‑new prompt—not one from your shell history.

⑤ Corporate Network or Firewall?

Corporate networks often block or throttle long‑lived connections. If you’re at work, try the same config at home. If it works at home, you’ve found the boundary. In that case, the config change may only help partially; the real fix might involve using a different proxy tool that supports WebSocket forwarding, or connecting through a tunnel.

Why Do Some People Never See This Issue?

You’ll read online comments: “I didn’t change anything and it’s fast” vs. “I tried everything and it’s still slow”. The difference is purely network routing.

If your ISP or VPN node handles WebSocket handshakes cleanly, the initial connection succeeds on the first try, and you never see the retry loop. If your path passes through a node that drops the upgrade request, you hit the retry sequence.

So this isn’t a CodeX bug—it’s a default behaviour that works well in some environments and poorly in others.

The config change reorders the priority, not disables WebSocket entirely. It says: “Don’t bother trying WebSocket with this provider—just use HTTP.” For environments where WebSocket works fine, you can keep the default. For the rest, this tweak saves time.

What’s the Trade‑Off?

There’s no free lunch. Switching from WebSocket to HTTP introduces a small overhead:

• ✦ Cost: Each request may re‑establish the connection, adding a few dozen milliseconds per turn, especially in multi‑step conversations.
• ✦ Benefit: You skip the 5‑retry loop, saving 10–30 seconds per request.

If you make 50 CodeX calls a day, that’s 500–1500 seconds—roughly 8 to 25 minutes—saved daily. For heavy users, the math is compelling.

And you keep every feature: tool calls, file edits, multi‑turn reasoning—all work identically. Only the transport layer changes.

If You Still Have Long “Thinking…” Times After This Fix

Once you’ve ruled out the WebSocket retry loop, a lingering “Thinking…” may be caused by something else:

• ✦ You’re working on a massive codebase—context size slows inference.
• ✦ Multiple tools are being called, and each has its own latency.
• ✦ The model itself is under heavy load (yes, sometimes it really is the model).

Check CodeX logs (if available) to see where the time goes. The --verbose flag can help. The config fix only addresses connection‑stage hangs; it doesn’t make the model run faster.

Quick Reference / Action Checklist

A condensed version of the entire process:

1. Recognise the symptom – “Reconnecting 5/5” is a network retry, not model reasoning.
2. Find your config – %USERPROFILE%\.codex\config.toml (Windows) or ~/.codex/config.toml (macOS/Linux).
3. Back it up – copy to config.toml.bak.
4. Add the HTTP provider – insert the snippet above, set supports_websockets = false, and point model_provider to it.
5. Restart CodeX – test with a simple prompt.
6. If it doesn’t work – check spelling, upgrade CodeX, switch network nodes, start a fresh session.
7. If still stuck – investigate your proxy or corporate firewall.

One‑Page Summary Table

FAQ

Q1: Will this break any CodeX features?
No. Tool calls, multi‑turn conversations, file operations—all remain fully functional. Only the underlying transport changes.

Q2: I broke the config and CodeX won’t start—what now?
Restore your config.toml.bak to config.toml. Then re‑apply the changes carefully, checking the format.

Q3: Do I need to do this per project?
No. config.toml is global. One change affects all projects.

Q4: Why didn’t the change work even though I added the provider?
You probably forgot to set model_provider = "openai_http" at the top, or the name in [model_providers.…] doesn’t match. Correct the mismatch and restart.

Q5: What’s the difference between wire_api = "responses" and wire_api = "completions"?
responses is the newer API with better support for interactive flows. Use it unless you have a specific reason not to.

Q6: Is HTTP slower than WebSocket in all cases?
In perfect network conditions with a fast WebSocket handshake, WebSocket is marginally faster. But if your network causes retries, HTTP is much faster because it skips the failures. For most users, the difference is negligible.

Q7: I’m using CodeX Enterprise—does this apply?
The config path may differ. Ask CodeX to locate your config.toml—it works for enterprise as well. The underlying logic is the same.

Q8: Do I have to reconfigure after every CodeX update?
No, your config file persists. Upgrades usually keep your settings, but it’s good practice to check after major version bumps.

Cover image: Unsplash

This tweak won’t fix every delay, but it cuts out one of the most frustrating and unnecessary waits. If your network is friendly to WebSocket, you won’t notice the change. If it isn’t, you’ll wonder why you didn’t do this sooner.

Give it a shot—let CodeX get to work first, and debate reasoning depth later.