Summary (Snippet): Are you seeing "Codex reconnecting 5 times on a new session" when using the Codex client? This is usually not a model or account problem, but an incompatibility between your local proxy and the WebSocket protocol. This article provides a clean HTTP/SSE fallback fix — just edit the
config.tomlfile to completely resolve the repeated reconnects on your first request.
📚 Table of Contents
- 1. Quick Fix (TL;DR)
- 2. Symptoms: Is This Your Situation?
- 3. Does This Fix Apply to You?
- 4. Root Cause: Why Does It Keep Reconnecting?
- 5. Step-by-Step Fix
- 6. Complete config.toml Example
- 7. Understanding the Key Options
- 8. How to Verify the Configuration
- 9. FAQ
1. Quick Fix (TL;DR)
If the first request in Codex Desktop — or a brand-new conversation — hits about 5 reconnecting messages but the answer eventually comes through, it's most likely not an unavailable model, but WebSocket jitter when the initial stream passes through your local network proxy.
The ultimate fix: add a new OpenAI Provider in Codex's config.toml that forces the HTTP/SSE protocol and make it the default. This cleanly bypasses the unstable WebSocket hop in your proxy chain.
Core snippet (just add it to your config):
model_provider = "openai_http"
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = false
requires_openai_auth = trueNote: after switching to
openai_http, the history list on the right may only show conversations under the new Provider. This is normal — your account or model has not been replaced.
2. Symptoms: Is This Your Situation?
When you search "Codex reconnecting 5 times on a new session", it usually comes with these typical signs:
| Symptom | Details |
|---|---|
| Heavy reconnecting on first request | The first message each time you open the app usually shows about 5 reconnect prompts before output starts. |
| Easily reproduced with a new chat | Even with the app open, starting a New Chat tends to trigger jitter on the first request. |
| Subsequent conversations are fine | Once the first message goes through, follow-up conversations are smooth (ruling out account/model bans). |
| More obvious with a proxy on | Direct connection works, but it always reproduces with a local proxy (e.g. 127.0.0.1:10808). |
3. Does This Fix Apply to You?
Before editing, check these scenarios to confirm whether this fix fits:
✅ Perfect fit:
- Your Codex Desktop account can log in normally.
- You eventually get model answers — it's just the first request or new-session request that frequently errors with
reconnecting. - You have a network proxy / VPN tool running.
❌ Not a fit (look elsewhere):
- Codex cannot log in at all — blank screen or network errors.
- All model requests fail 100% no matter how long you wait.
- The proxy node itself is dead and can't reach
chatgpt.com. - Blocked by a corporate firewall or antivirus global interception.
4. Root Cause: Why Does It Keep Reconnecting?
Codex's default OpenAI Provider prefers a WebSocket transport. WebSocket is efficient, but it's very sensitive to proxy chains.
When a request passes through your local proxy, any instability in the steps below triggers an automatic reconnect:
- WebSocket Upgrade: some proxy software doesn't handle the HTTP→WebSocket upgrade well.
- Long-lived connection: the first long connection may be unexpectedly cut by the proxy client or an underlying network middlebox.
- TLS Tunneling: the proxy's HTTPS tunnel handshake may have latency or jitter.
- Auto-retry: as soon as Codex detects a disconnect it retries immediately (usually ~5 times before it degrades or gets through).
The way out: don't try to change Codex's retry count. Instead, make it give up WebSocket entirely and use the proxy-friendly HTTP/SSE (Server-Sent Events) streaming response.
5. Step-by-Step Fix
Step 1: Fully close Codex Desktop
Quit and completely close Codex Desktop first, so the config isn't overwritten or locked while you edit it.
Step 2: Locate and back up the config file
The config.toml file is usually at: C:\Users\YourUsername\.codex\config.toml
To be safe, back it up in PowerShell first:
Copy-Item "$env:USERPROFILE\.codex\config.toml" "$env:USERPROFILE\.codex\config.toml.bak"
Step 3: Edit config.toml
Open the file with Notepad or VS Code.
1. Change the default Provider Near the top, find model_provider and change it to:
model_provider = "openai_http"
(Note: if the field already exists, just change its value — don't add a second line)
2. Append the HTTP Provider definition
Scroll to the end of the file and paste this:
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = false
requires_openai_auth = true
Step 4: Save and restart
Save the file, restart Codex Desktop, start a new session and send a message — the magic happens.
6. Complete config.toml Example
If your config is mostly blank, or you're not sure where to paste, use this complete, ready-to-run example. (Keep any existing sandbox/plugin settings unchanged.)
# Set the global default Provider to our new HTTP mode
model_provider = "openai_http"
model = "gpt-5.5"
model_reasoning_effort = "high"
[windows]
sandbox = "elevated"
# =========== Below is the new HTTP-only Provider ===========
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = false
requires_openai_auth = true7. Understanding the Key Options
Understanding the principles lets you handle variant problems easily:
| Config option | What it does |
|---|---|
model_provider = "openai_http" | Points the default provider at our custom block. |
[model_providers.openai_http] | Declares a new Provider — it doesn't touch the native openai config, so you can roll back anytime. |
wire_api = "responses" | Keeps the native, advanced Responses API. |
supports_websockets = false | The core trick: disables WebSocket handshake entirely, forcing a stable HTTP/SSE fallback. |
requires_openai_auth = true | Inherits the Codex/OpenAI web login state (SSO) — no API key needed. |
8. How to Verify the Configuration
Not sure if you got it right? Use the CLI to debug quickly:
Open a terminal and run:
codex debug models
If it returns a normal model list without a syntax error, your config.toml changes are correct.
Final test: go back to the app, New Chat and send "Hello". If it responds instantly with no more annoying reconnecting, the local proxy handshake issue has been successfully avoided!
9. FAQ
Q1: My Codex Desktop reconnects 5 times on the first request of a new session. What's the core cause? A: If later conversations work fine, the most common cause is that your local proxy software doesn't handle WebSocket's protocol Upgrade or long-connection keep-alive reliably.
Q2: Will disabling WebSocket and using HTTP/SSE hurt code quality or model intelligence? A: Absolutely not. This only changes the "highway" used to transfer data between client and server. The cargo in the truck — the model's capabilities and context — is unchanged.
Q3: Does this method require binding a credit card in the OpenAI backend to generate an API key? A: No. requires_openai_auth = true means it continues to use your client's built-in login authorization.
Q4: Why not just modify the original default openai provider? A: Creating a new openai_http gives you a non-destructive edit. Future Codex client updates may overwrite the default config; an isolated one is easier to maintain, and if something goes wrong you can simply delete it to restore everything.
Q5: After editing, Codex won't open / crashes. What should I do? A: This usually means a typo in config.toml punctuation (like a missing quote or bracket). Delete the added code, or restore the .bak backup from Step 2 to recover.
Q6: I followed the steps but still reconnect frequently. What now? A: If you still disconnect in HTTP mode, check these:
- Is your proxy node itself high-latency or dropping packets?
- Try switching your proxy client's core (e.g. from Xray to Sing-box).
- Check whether the system global proxy conflicts with the app's actual request path.
- Make sure the Codex client is updated to the latest version.