Error sending request for url (https://chatgpt.com/backend-api/codex/responses) after macbook sleeps

I'm seeing this as well with 0.31.0 and it just happened spontaneously without any kind of observed network interruption.

Related: #1243
For me this happens every single time.

This happens in the new codex vscode extension. Any resolutions yet ?

It's possible that some versions of codex-cli for Windows had issues related to using "python3" vs "python" in the PATH, which could cause similar execution errors, especially on systems where only "python.exe" is present.

Have the exact problem but my device is termux android

same

Set dns 8.8.8.8. If you’re still facing issues, please ensure that port 443 is open on your system.
(https://github.com/openai/codex/issues/3409#issuecomment-3384162692)

I have the same bug but curl -v https://chatgpt.com is ok

I have the same bug but curl -v https://chatgpt.com is ok

Exactly the same issue.

I just installed Python 3.13. the OS is Ubuntu 25.04, and the error occurs, how to avoid the error? I'm sure curl -v https://chatgpt.com has no error

same. I suspected it was an issue with VSCode. After trying Cursor's Codex extension, my problem was successfully resolved.

same. I suspected it was an issue with VSCode. After trying Cursor's Codex extension, my problem was successfully resolved.一样。我怀疑是 VSCode 的问题。试用 Cursor 的 Codex 扩展后，问题就解决了。

但是我在 Cursor 的 Codex 扩展中还是有这个报错，其运行在WSL环境时，但是在终端中却没有影响

Something worth checking. For me I am behind a corporate network and they have SSL decryption. One of our certificate expired and I forgot to update them in my WSL instance. I added the company new root CA files to the /usr/local/share/ca-certificates/ folder and run update-ca-certificates as root user.

Once that was done, the error was gone.

You can try the following commands to see if that's your issue:

openssl s_client -showcerts -connect chatgpt.com:443
If you see certificates different from the ChatGPT ones, then proceed to next command:

curl -vvv https://chatgpt.com/backend-api/codex/responses
There you will see if it succeeds or not. If you see some certificate errors, then update your CA certificates.

Try again the same command until you added the correct certificate. Ask your administrator to provide them.

You can check it's working correctly by running the codex cli :
cd your-project
codex auth

If no errors then you should be good in VS Code as well.

anyone resolve this?

问题一般是 VSCode 从 GUI 启动时没有继承代理/环境变量。从能用 codex 的终端输入code . 启动vscode(先在终端中先运行一下codex，然后退出codex，最后再启动vscode)，如果新打开的vscode里能用codex插件，则就是这个问题！想要根治这个问题有两大方法：①在vscode里配置系统代理；②把代理/Key写入到“系统级环境”，使得GUI启动vscode也可以走代理。

Experiencing this as well on linux ubuntu 24.04.

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

I resolved the issue by switching from my Wi-Fi network to a mobile hotspot and connecting my Mac to it this mean that the original network connection may have been restricted or temporarily blocked by openai servers for some reason adn after changing to the mobile hotspot, the error no longer occurred

I'm using codex with a Azure Cognitive Services gpt-5.3-codex API. I see this error all the time. I think it's just Azure throttling my requests. The cli should handle this better. Using the same API with opencode.ai cli, for example, just causes the cli to pause and retry after 10-30 seconds. In the codex cli, it just dies. This is _really_ annoying when codex is working on a long running job.

@dmulder, make sure you report this to the Azure folks. The more feedback they get, the more likely it is that they'll invest in improvements for Codex users. We already have good backoff logic in the client for specific errors emitted by OpenAI endpoints. Azure errors are somewhat different (and not documented). We've invited the Azure team to add similar logic in the Codex OSS code base to improve error handling, but they haven't done so to date. The more they hear from their customers, the more likely it is that they'll make this investment.

@dmulder, make sure you report this to the Azure folks. The more feedback they get, the more likely it is that they'll invest in improvements for Codex users. We already have good backoff logic in the client for specific errors emitted by OpenAI endpoints. Azure errors are somewhat different (and not documented). We've invited the Azure team to add similar logic in the Codex OSS code base to improve error handling, but they haven't done so to date. The more they hear from their customers, the more likely it is that they'll make this investment.

Couldn't the codex app handle this better by just adding a backoff when you get an unknown Azure error, maybe giving up after a couple of retries? Just because you don't recognize the exact error doesn't mean the app should just die.

We already back off and retry for errors that are known to be ephemeral. In general, a 429 error (which is what this likely is) is not ephemeral. It is generally categorized as a non-retriable error. I don't think that backing off for 10 to 30 sec will address this in most cases, but it's hard to say because I don't have access to Azure's code, and they don't publicly document the error behavior. This is really something that the Azure team is best situated to address.

This happens to me all the time, on a Macbook and I can also resolve this by switching from wifi to my phone's 5G hotspot like another person posted. I've tried playing around with every possible router setting to no avail. I'll need to try switching to an old router I've got lying around and see if that changes anything - if I get the same issue with a different router, I'm chalking it up to an ISP or modem issue

终端/terminal 执行：
certutil -generateSSTFromWU roots.sst
certutil -addstore -f root roots.sst
我这里是SSL证书导致的问题，更新了证书就可以了。

I get constant auto compact
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

When running GPT-5.4 on Codex Version 26.325.31654 (1272)

I switched to GPT-5.3-Codex and then it works fine...

same here - constant. what's also surprising that it seems like the context codex uses quickly fills up (much quicker than before). and its unrelated (for me) from network, closing lids or whatever

I get constant auto compact Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact) When running GPT-5.4 on Codex Version 26.325.31654 (1272) I switched to GPT-5.3-Codex and then it works fine...

Still same problem here today with running newest codex version. I have to switch to GPT-5.3-Codex for context compact then switch back to GPT-5.4 .

having today

+1 to this

codex 26.422.30944 model change the 5.3-codex.
That's work. don't uesd 5.5 not work now!
stream disconnected before completion: websocket closed by server before response.completed

Has anyone found a solution for this?
Codex is working on my mac ip but as soon as i try to use it on aws server connected via vscode remote it just keeps on reconnecting before throwing the following error:
_stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)_

bros what is the solution to this lol?!

macos 26.3 this is a constant problem

Still happening

Having the same issue, is this bug in Codex, not sure its a network issue

Found a solution to the problem for Windows:
Open the "Control Panel".
Go to "Browser Properties".
Open the "Connections" tab.
Click "Network Settings".
Uncheck the box next to Use a proxy server for local connections:
"Use a proxy server for local connections"
Click OK.

Restart Codex and re-authorize

I just ran into this problem too, and just restarting my computer the it fixed.

I am seeing a very similar connectivity problem, but in my case the evidence points strongly to an IPv6 path issue affecting Codex streaming/WebSocket behavior.

The visible Codex error is:

“Stream disconnected before completion: websocket closed by server before response.completed”

During the failure, tcpdump showed Codex/ChatGPT traffic resolving and connecting over IPv6 to chatgpt.com. The relevant OpenAI/Cloudflare IPv6 addresses returned for chatgpt.com were:

2a06:98c1:310b::ac40:9bd1
2a06:98c1:3100::6812:202f

The TCP connection to port 443 was established, but the stream became unstable. In the packet capture, the client kept retransmitting the same TCP segment range repeatedly while the remote ACK did not advance as expected. This looked like an IPv6 path/PMTU/packet-loss problem rather than an authentication or application-level Codex issue.

After temporarily disabling IPv6 on the Debian machine, Codex immediately became much faster and the code generation stream became noticeably more stable. This strongly suggests that Codex was preferring IPv6, hitting a bad IPv6 path, and then surfacing the problem as a WebSocket stream failure.

Suggestion: Codex could detect this specific class of failure and automatically retry the affected request/stream over IPv4 when the current connection is using IPv6 and the stream fails with a WebSocket/connectivity error. This could be implemented similarly to a Happy Eyeballs-style fallback, or as a fallback specifically for:

• websocket closed before response.completed
• stream disconnected before completion
• request errors against https://chatgpt.com/backend-api/codex/responses
• repeated reconnect attempts while the active route is IPv6

A user-configurable option would also help, for example:

CODEX_PREFER_IPV4=1

or a config setting such as:

network_prefer_ipv4 = true

This would avoid requiring users to disable IPv6 system-wide just to make Codex stable, while still preserving IPv6 support for networks where it works correctly.

To test in Debian 13.5:
Close codex.
Type on terminal:
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1
Open Codex and use it.

It happened right after I upgraded Ubuntu from 22.04 to 24.04 via remotely accessing the server through Vscode. 5.5 was the model, and switched to 5.3-codex but it still didn't work.

This is triggering on Sol 5.6 on High, over and over again.

<img width="830" height="621" alt="Image" src="https://github.com/user-attachments/assets/75a08d2c-6fd4-4f25-9580-6ae03b474eee" />