Windows desktop app intermittently fails streamed responses behind Clash Verge Rev proxy (TLS EOF / response body decode error)
What version of the Codex App are you using (From “About Codex” dialog)?
26.415.4716.0
What subscription do you have?
plus
What platform is your computer?
_No response_
What issue are you seeing?
On Windows desktop, Codex intermittently fails during streamed replies when running behind Clash Verge Rev.
This is not a total connectivity failure. The app can still partially continue working and produce output, but the same session, or a newly opened window/session, may show repeated reconnects or fail before the streamed response completes.
I observed multiple failure modes during the same general setup:
stream disconnected before completion: IO error: peer closed connection without sending TLS close_notifystream disconnected before completion: tls handshake eofstream disconnected before completion: Transport error: network error: error decoding response body
In some cases, one window/session can still work while another newly opened window/session shows reconnects or stream completion failures.
What steps can reproduce the bug?
Steps to reproduce
- Run the Codex Windows desktop app.
- Use Clash Verge Rev as the local proxy.
- Verify the active local proxy port is
127.0.0.1:7897(mixed-port). - Launch Codex with explicit proxy environment variables:
HTTP_PROXY=http://127.0.0.1:7897HTTPS_PROXY=http://127.0.0.1:7897ALL_PROXY=socks5://127.0.0.1:7897
- Start a normal chat, especially one that triggers web searches or a longer streamed response.
- Open a new window/session and repeat.
- Observe intermittent reconnects and stream completion failures.
What is the expected behavior?
Expected behavior
Codex should stream the full response normally without repeated reconnects or stream completion failures.
Actual behavior
The desktop app intermittently reconnects or fails before the stream completes.
Examples shown in the UI include:
Reconnecting... 2/5
stream disconnected before completion: IO error: peer closed connection without sending TLS close_notify
Reconnecting... 3/5
stream disconnected before completion: tls handshake eof
stream disconnected before completion: Transport error: network error: error decoding response body
### Additional information
_No response_
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This is likely an issue with your proxy, not with Codex. Please work with your IT department to diagnose.
Sharing one proxy-side data point in case it helps other Windows users who hit the same symptom with rule-based routing.
In my setup:
stream disconnected before completiontls handshake eofhttps://chatgpt.com/backend-api/codex/responsesThe fix was not just adding Codex/OpenAI domain rules. The important bit was selector consistency.
The OpenAI-specific proxy group was pinned to a stale fixed proxy, while the primary/default selector was using a different working proxy. That made global mode work, but rule mode forced Codex traffic through the stale OpenAI route.
Changing the OpenAI proxy group to follow the same currently working primary/default selector fixed the reconnect loop.
Relevant rules:
After the fix, the proxy logs showed Codex traffic being routed consistently, for example:
Takeaway: for rule-based proxy setups, it may not be enough to add the right Codex/OpenAI domain rules. The OpenAI-specific route also needs to use the same currently working path as the primary selector, otherwise global mode can work while rule mode breaks Codex's long-lived HTTPS/WebSocket streams.
This is a proxy-side mitigation rather than a claim that Codex itself is at fault, but the symptom looks exactly like a Codex stream failure from the app side, so it may be useful troubleshooting context.