Repository navigation
Windows: responses_websocket connect to chatgpt.com/backend-api/codex/responses times out while responses_http succeeds #16367
Description
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_websocketand 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=""
Activity
github-actions commentedon Mar 31, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Mar 31, 2026
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 commentedon Mar 31, 2026
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 commentedon Apr 8, 2026
ref.
#16768
huajiexiewenfeng commentedon Jul 13, 2026
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 toresponses_http.In my environment, the concrete root cause was a virtual-network route collision:
dns.fake-ip-range: 198.18.0.1/16.198.18.0.0/16range.chatgpt.comresolved 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-rangeto 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 /flushdnsUseful diagnostics before changing anything:
If
chatgpt.comresolves 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.