Windows: responses_websocket connect to chatgpt.com/backend-api/codex/responses times out while responses_http succeeds

Resolved 💬 5 comments Opened Mar 31, 2026 by edswangren Closed Mar 31, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.117.0

What subscription do you have?

Enterprise

Which model were you using?

gpt-5.4

What platform is your computer?

Windows 11 x86_64

What terminal emulator and version are you using (if applicable)?

Windows Terminal

What issue are you seeing?

Codex intermittently selects responses_websocket, then stalls for ~15s per attempt and retries repeatedly before falling back to a working HTTP path.

From ~/.codex/log/codex-tui.log:

codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
event.name="codex.websocket_connect" duration_ms=15015 success="false" error.message="timeout"

Immediately after websocket failures, the same session can succeed with:

transport="responses_http"
POST https://chatgpt.com/backend-api/codex/responses

What steps can reproduce the bug?

Start a fresh Codex CLI session on Windows using ChatGPT auth.
Send a prompt.
On affected runs, Codex uses responses_websocket and retries after repeated ~15s connect timeouts. The UI will read "Retrying (N/5)..." until the 5 attempts are exhausted, then switches to HTTP, which works.

What is the expected behavior?

websocket requests don't so often timeout for no apparent reason.

Additional information

Relevant log (RUST_LOG=trace) fields on failing websocket attempts:

transport="responses_websocket"
websocket.warmup=false
endpoint="/responses"
auth_mode="Chatgpt"
auth.header_attached=true
auth.retry_after_unauthorized=false
auth_error=""
auth_error_code=""

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#15014
#14877

Powered by Codex Action

etraut-openai contributor · 4 months ago

This is intended behavior, not a bug.

This means there's a problem with your network configuration that's preventing proper connection via websockets. Are you using a VPN, firewall, or corporate proxy? Work with your IT department to allow Codex to use websockets.

edswangren · 4 months ago

This is intended behavior, not a bug. This means there's a problem with your network configuration that's preventing proper connection via websockets. Are you using a VPN, firewall, or corporate proxy? Work with your IT department to allow Codex to use websockets.

It doesn't happen every time. I should have said so prior, my mistake, but that's not a resolution. No proxy, no exotic network config, and transient (though common) errors. Doesn't seem like a static network config issue.

fxpoet · 4 months ago

ref.
https://github.com/openai/codex/issues/16768

huajiexiewenfeng · 1 month ago

I reproduced the same pattern on Windows 11: each new thread's first turn attempted responses_websocket, timed out at roughly 15 seconds per attempt, retried five times, and then succeeded immediately after falling back to responses_http.

In my environment, the concrete root cause was a virtual-network route collision:

Clash Verge Rev was using Fake-IP mode with dns.fake-ip-range: 198.18.0.1/16.
Sangfor aTrust VNIC also installed a route covering the same/overlapping 198.18.0.0/16 range.
chatgpt.com resolved to a Clash Fake-IP in that range, but new WebSocket connections could be routed through the wrong virtual adapter.

The fix was to change Clash's dns.fake-ip-range to an unused range that does not overlap any aTrust/VPN/VNIC route, then fully restart Clash and Codex. I also flushed the Windows DNS cache:

ipconfig /flushdns

Useful diagnostics before changing anything:

Resolve-DnsName chatgpt.com
route print

If chatgpt.com resolves into Clash's Fake-IP range, check whether more than one virtual adapter owns or routes that range. After removing the overlap, the initial WebSocket connection stopped going through the five retries.

This will not explain every WebSocket timeout, but it is worth checking on Windows systems running Clash together with Sangfor aTrust or another VPN client that creates a virtual NIC.