On this page
If even a short prompt reconnects, narrow the problem to the connection path first
This article covers a simple prompt from the Codex App or CLI that causes the UI to show Reconnecting 1/5 through 5/5, followed by stream disconnected before completion. OpenAI official issue #23061 records the same error path, showing that it is not necessarily caused by the prompt, repository size, or context length.
A successful ordinary HTTPS request from Codex does not guarantee a stable streaming response. OpenAI network documentation says Codex also opens a secure WebSocket through wss://chatgpt.com/. Any link among application proxy access, Clash rules, node egress, and long-connection policy can interrupt the response.
Group the comparison results first
| Symptom | More likely break point | Continue checking |
|---|---|---|
| The OpenAI status page reports an incident at the same time | Server-side event | Retest after recovery |
| The App fails, while the CLI works on the same network | The two interfaces use different proxy paths | Compare versions and launch methods |
| A short response succeeds, but a long response reconnects midway | The WebSocket or proxy closes the long connection early | Check 443, TLS, and timeouts |
| Neither the App nor CLI appears on the Clash Connections page | The request does not enter the current proxy | Check the system proxy, TUN, or port |
- Codex App or CLIStarts sign-in, HTTPS, and streaming requests
- System proxy, environment variables, or TUNDetermines whether the request enters Clash
- Clash rules and nodeSelects the actual egress for chatgpt.com
- OpenAI WebSocketMaintains the model's streaming connection on port 443
When short requests succeed but responses repeatedly reconnect midway, the common break point is not the prompt itself but one of application proxy access, rule-based egress, or the WebSocket long connection.
Use the status page and another network to rule out a shared outage
First check status.openai.com for an active ChatGPT or Codex incident. If the status page shows a clear outage, record the error time and wait for recovery. Switching many nodes or rewriting rules at that point only destroys the original comparison conditions.
When the status page is normal, keep the same short prompt and account, then test on the current Clash node, another known working node, a mobile hotspot, or a network that bypasses the corporate gateway. If switching networks restores service immediately, continue investigating the local proxy or corporate network instead of deleting the Codex task.
Build three reproducible comparisons
Record the exact error
Save the Reconnecting count, failed URL, time, and Codex App and CLI versions. Do not expose task content or tokens.
Pin a minimal request
Send the same short prompt in a new task to keep long context, tool calls, and repository scans from affecting the network diagnosis.
Change egress only once
Switch first to one known working Clash node, then to a mobile hotspot. Each time, observe whether the same error appears.
Restore the original node
Return to the original policy group after the comparison so later results are not caused by an unrecorded egress.
Confirm on the Clash Connections page that Codex really enters the proxy
Open the Clash Verge Rev Connections page and clear old filters, then send one new prompt from Codex. Look for chatgpt.com and related OpenAI domains, and record the matched rule, policy group, and actual node. Browser traffic alone does not prove that the Codex App or CLI uses the same path.
Use Rule mode for normal operation. To determine whether a rule is missing, briefly switch to Global, pin the same node, and retest. If Global works while Rule fails, the request enters Clash and the issue lies in the rule or policy selection; stop changing Codex. Return to the original mode immediately after testing.
The Codex request appears and uses the expected node
The proxy entry works; continue checking WebSocket, TLS inspection, and long-connection timeouts.
The request appears but hits DIRECT
Compare briefly with Global, then add an explainable rule from connection records.
No new Codex connection appears
The process may not read the system proxy, or the CLI may not have inherited proxy variables from the current terminal.
Every domain continually times out
Switch the node or network first; do not treat an entire upstream failure as Codex-specific.
Test the App and CLI separately; do not treat them as the same process
Official Codex troubleshooting notes warn that the desktop App and CLI may contain different versions. Record both versions, then send the same short prompt over the same network and node. If the App succeeds and the CLI fails, or vice versa, the account and OpenAI service are not the only variables.
codex --version
/Applications/Codex.app/Contents/Resources/codex --versionHow to interpret versions and results
| Comparison | Interpretation | Next step |
|---|---|---|
| The App and CLI versions differ | Update the older side first, then retest | Keep the node and prompt unchanged |
| The CLI works, while the App keeps reconnecting | The App may not inherit terminal environment variables | Compare independently using TUN or the system proxy |
| The App works, while the CLI keeps reconnecting | The current shell proxy variables or launch environment are wrong | Check the variables and actual HTTP port |
| Both fail at the same stage | A shared node, rule, or WebSocket issue is more likely | Continue with network controls |
Allow the Codex WebSocket to remain connected on port 443
Official OpenAI network guidance requires the proxy, firewall, or security gateway to allow chatgpt.com to complete a standard Upgrade: websocket handshake on TCP 443. If webpages and sign-in work but responses always stop mid-generation, have the network administrator check WebSocket idle timeouts, maximum message size, and premature long-connection termination.
If the corporate network uses TLS inspection, confirm that it does not substitute the wrong certificate, alter the handshake, or allow only ordinary HTTPS. The most useful comparison is the same account and Codex version on a mobile hotspot. Escalate to network policy only when the hotspot is stable and the corporate network fails.
Minimum checks for the administrator
- Allow chatgpt.com TCP 443 and WebSocket Upgrade
- Long connections are not closed by an overly short idle timeout
- The TLS inspection trust chain is consistent for HTTPS, sign-in, and secure WebSocket
- Officially listed ChatGPT, OpenAI, and static-resource domains are not rewritten
- The mobile-hotspot comparison has ruled out the account, prompt, and local version
Test Clash's HTTP proxy entry only in the current terminal
OpenAI Codex issue #20844 is an open user report: the same proxy stack produced stream disconnected over SOCKS5 but recovered after switching to explicit HTTP_PROXY and HTTPS_PROXY. This is not a promised universal fix, but it can show whether the SOCKS and HTTP paths behave differently.
First confirm the HTTP or Mixed port in Clash Verge Rev settings. The 7897 below is only an example and must be replaced with the actual local port. Set the variables only in the current terminal; do not put them in shell configuration or the system environment yet.
export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
unset ALL_PROXY all_proxy
codex$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
codexThe CLI becomes stable immediately, and the Connections page shows chatgpt.com
Keep that terminal as a temporary working path and continue checking whether the App needs TUN interception.
HTTP works, but SOCKS5 still drops the stream
Prefer the verified HTTP or Mixed entry and follow the corresponding official issue for a later fix.
Both proxy types fail, but the mobile hotspot works
Inspect the Clash node, rules, and WebSocket forwarding; do not save the variables permanently in the system.
The new process still does not appear on the Connections page
The port may be wrong, or the command was not launched from the same terminal. Exit the process, verify the setting, and try again.
Remove the temporary variables, then complete four streaming checks
If the test does not help or you are ready to return to the system proxy, quit the Codex process launched for this test, then close the current terminal to remove the temporary variables. If you added them to shell configuration or the Windows user environment, delete those entries and open a new terminal. Do not leave old SOCKS, HTTP, and TUN paths active at the same time.
If the App is stable only under TUN, use that as a reversible temporary access path and preserve a baseline where the system proxy recovers after TUN is disabled. After updating Codex or Clash Verge Rev, rerun the same checklist before deciding whether to keep TUN.
Final validation checklist
- The App and CLI each complete one short prompt without entering a Reconnecting count
- A longer response generates continuously without stream disconnected before completion
- The Clash Connections page shows chatgpt.com matching the expected rule and pinned node
- After quitting Codex and disabling the temporary proxy, system networking returns to its original state