You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Codex Error: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses) #13811
I started getting this at my office on Wednesday evening March 4, 2026 and regularly receiving them at my home since then Wednesday through Friday March 6, 2026.
This looks like a basic network connectivity issue. Are you using a VPN, proxy, firewall, or any other software that could affect networking? We find that's a common cause of connectivity issues like this.
I have the same - codex randomly stopped working today with error 'stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)'. Initially from Intellij, but then installed the codex CLI and the same happens. Not on a VPN. Have general connectivity for everything else so not buying the "basic network connectivity" excuse. Feels more like a bug your end tbh.
I have the same - codex randomly stopped working today with error 'stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)'. Initially from Intellij, but then installed the codex CLI and the same happens. Not on a VPN. Have general connectivity for everything else so not buying the "basic network connectivity" excuse. Feels more like a bug your end tbh.
I initially thought the same things, but then I dug into it with ChatGPT and was able to resolve my issues with my PC & Verizon internet router that I have in my residence.
It was a good idea getting chatgpt to help troubleshoot the problem. Unfortunately it's exhausted all options and is convinced this is a bug and I should report it. Where it will be ignored because it can't be reproduced. It's hard work isn't it? 😢
It was a good idea getting chatgpt to help troubleshoot the problem. Unfortunately it's exhausted all options and is convinced this is a bug and I should report it. Where it will be ignored because it can't be reproduced. It's hard work isn't it? 😢
Oh I should have updated. Eventually ChtGPT blamed some drivers in ubuntu 20. A fresh install of Ubuntu 24 fixed the problem and not had any bother since.
This looks like a basic network connectivity issue. Are you using a VPN, proxy, firewall, or any other software that could affect networking? We find that's a common cause of connectivity issues like this.
i have meet this issue multiple times this days: submit an spec before sleep, but see this error on the morning. can you please add an auto retry policy.
@bnllb, we do have an auto retry policy. It retries up to five times with back-off. If it fails five times in a row, we consider it unrecoverable and stop.
After Reviewer started: current changes, the stream stays at zero bytes of payload for 60-90 seconds, then enters the Reconnecting loop and eventually dies. No reasoning tokens, no output text — nothing is emitted.
Scope of reproduction
On this one repository, across a single session (2026-04-19 night → 2026-04-20 morning):
Attempts
Result
20
0 successful, 20 same-mode failures
The same account (groverpumc@gmail.com, ChatGPT OAuth) previously completed a full /codex:review cycle on a different, smaller repository (test_cc_code) earlier in the same evening, returning a 9-issue review→fix→verify loop in ~8 minutes. So the auth, binary, and network path work in general — the failure is bound to this particular repo or the repo's diff pattern.
What I tried (eliminated as causes)
Plugin reinstall (npm install -g @openai/codex): no change.
codex logout → rm ~/.codex/auth.json → codex login: no change.
model_reasoning_effort: tested xhigh and medium, both fail identically.
Review gate toggle (enable / disable): no effect on manual review failures.
OPENAI_API_KEY: not set (no conflict with ChatGPT OAuth).
MCP servers: ~/.codex/config.toml has no [mcp_servers.*] entries.
Diff size: fails on both a 48-line single-file diff and an 800-line multi-file diff.
Working-tree scope vs. branch scope: both fail the same way.
experimental_use_rmcp_client: not set (default).
Minimum reproduction
git init a repository.
Add one small file (e.g., a 48-line shell script).
git add <file> so the working tree has a staged diff.
Run /codex:review --background (or node codex-companion.mjs review --background).
Observe: thread is ready, reviewer starts, then zero-byte silence for ~60s → Reconnecting 1/5 → … → stream disconnected.
Request
If this is a known issue tracked under an existing ticket, please point me there and I'll add my logs as an additional datapoint. Otherwise, any diagnostic information you need (full session log, Codex session IDs, etc.) I can provide.
Was able to get codex working again for me, in my case the DNS resolution in WSL instance was broken, you can confirm it with running this in your WSL machine:
If this says name or service not known and the following ping returns normal answer:
ping 8.8.4.4
Then your issue is most likely in
/etc/resolv.conf
Quickfix: set google DNS as nameserver. This should make codex work again and from that moment on you can tell him to find out why it happened in the first place. resolv.conf should look something like this then:
curl uses the lowercase https_proxy, so a manual curl https://auth.openai.com/oauth/token worked fine (returned an expected 405, proving the network path was OK). But Codex reads the uppercase HTTPS_PROXY, so it sent the OAuth token exchange (and later the streaming responses requests) to port 7899, where no proxy was listening — hence error sending request for url.
Fix
Make all proxy variables consistent and point to the actual proxy port:
Update these in your shell profile (~/.zshrc / ~/.bashrc), then open a new terminal (or source the file) and launch Codex from that session.
Tip: Grep your profile to catch stale/duplicate proxy lines that override each other:
grep -rn -i "proxy" ~/.zshrc ~/.zprofile ~/.bashrc ~/.bash_profile
Note on the streaming error
The stream disconnected before completion error hits the SSE endpoint backend-api/codex/responses, which holds a long-lived streaming connection. If it persists even after the ports are consistent, the proxy itself is likely dropping long connections. Things that helped:
Switch the proxy client to TUN mode instead of an HTTP proxy — much more reliable for SSE/HTTP2 streams.
Try a different/more stable proxy node.
Make sure chatgpt.com / openai.com are routed through the proxy (not DIRECT) in your rules.
Want me to shorten it into a comment-sized version, or format it as a full issue with a title?
curl uses the lowercase https_proxy, so a manual curl https://auth.openai.com/oauth/token worked fine (returned an expected 405, proving the network path was OK). But Codex reads the uppercase HTTPS_PROXY, so it sent the OAuth token exchange (and later the streaming responses requests) to port 7899, where no proxy was listening — hence error sending request for url.
Fix
Make all proxy variables consistent and point to the actual proxy port:
I have solved this problem haha.(I use codex on VPN).check & change your own VPN node;add "export http_proxy=http://127.0.0.1:7897
export https_proxy=https://127.0.0.1:7897" to ~/.bashrc ,and then "source ~/.bashrc" in your terminal .
Activity
github-actions commentedon Mar 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
rockyicer commentedon Mar 6, 2026
same happen to me.
log out and log in again solve the issue for me.
puremachinery commentedon Mar 7, 2026
I tried logging out and back in and it did not resolve the issue.
Supercox72 commentedon Mar 7, 2026
Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)
I took the bait... desperate to get this working again and then I can't get logged back in!
Five separate times (& counting) without luck!
Supercox72 commentedon Mar 7, 2026
I've also noticed the following oddities:
Unable to upload files:

I downloaded & installed the Codex App from the Microsoft Store. I am having connectivity issues with it as well:

Sign-in could not be completed with Codex:

etraut-openai commentedon Mar 7, 2026
This looks like a basic network connectivity issue. Are you using a VPN, proxy, firewall, or any other software that could affect networking? We find that's a common cause of connectivity issues like this.
mikehalma commentedon Mar 9, 2026
I have the same - codex randomly stopped working today with error 'stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)'. Initially from Intellij, but then installed the codex CLI and the same happens. Not on a VPN. Have general connectivity for everything else so not buying the "basic network connectivity" excuse. Feels more like a bug your end tbh.
Supercox72 commentedon Mar 9, 2026
I was able to get it working with the help of ChatGPT...
Final Root Causes
Supercox72 commentedon Mar 9, 2026
I initially thought the same things, but then I dug into it with ChatGPT and was able to resolve my issues with my PC & Verizon internet router that I have in my residence.
mikehalma commentedon Mar 10, 2026
It was a good idea getting chatgpt to help troubleshoot the problem. Unfortunately it's exhausted all options and is convinced this is a bug and I should report it. Where it will be ignored because it can't be reproduced. It's hard work isn't it? 😢
knollmeyersam-dot commentedon Mar 13, 2026
happens all day long every day, multple devices, multiple locations. connection is 1gbs, so clearly an openai gateway issue
jb-san commentedon Mar 26, 2026
Seeing this on every session
mikehalma commentedon Mar 26, 2026
Oh I should have updated. Eventually ChtGPT blamed some drivers in ubuntu 20. A fresh install of Ubuntu 24 fixed the problem and not had any bother since.
bnllb commentedon Apr 19, 2026
i have meet this issue multiple times this days: submit an spec before sleep, but see this error on the morning. can you please add an auto retry policy.
etraut-openai commentedon Apr 19, 2026
@bnllb, we do have an auto retry policy. It retries up to five times with back-off. If it fails five times in a row, we consider it unrecoverable and stop.
Groverlee commentedon Apr 20, 2026
Environment
/home/groverlee/.claude/plugins/cache/openai-codex/codex/1.0.3/gpt-5.4(withmodel_reasoning_effort = "xhigh"in~/.codex/config.toml, but also reproduces onmedium)codex-companion.mjs review --backgroundfrom Claude Code plugin wrapperWhat happens
/codex:reviewand/codex:rescueconsistently fail on one specific repository with the following pattern:After
Reviewer started: current changes, the stream stays at zero bytes of payload for 60-90 seconds, then enters the Reconnecting loop and eventually dies. No reasoning tokens, no output text — nothing is emitted.Scope of reproduction
On this one repository, across a single session (2026-04-19 night → 2026-04-20 morning):
The same account (
groverpumc@gmail.com, ChatGPT OAuth) previously completed a full/codex:reviewcycle on a different, smaller repository (test_cc_code) earlier in the same evening, returning a 9-issue review→fix→verify loop in ~8 minutes. So the auth, binary, and network path work in general — the failure is bound to this particular repo or the repo's diff pattern.What I tried (eliminated as causes)
npm install -g @openai/codex): no change.codex logout→rm ~/.codex/auth.json→codex login: no change.model_reasoning_effort: testedxhighandmedium, both fail identically.OPENAI_API_KEY: not set (no conflict with ChatGPT OAuth).~/.codex/config.tomlhas no[mcp_servers.*]entries.experimental_use_rmcp_client: not set (default).Minimum reproduction
git inita repository.git add <file>so the working tree has a staged diff./codex:review --background(ornode codex-companion.mjs review --background).Request
If this is a known issue tracked under an existing ticket, please point me there and I'll add my logs as an additional datapoint. Otherwise, any diagnostic information you need (full session log, Codex session IDs, etc.) I can provide.
Related open issues that look similar: #13811, #13245, #8465, #14583.
snoopuppy582 commentedon May 24, 2026
same to me
chengligen commentedon May 27, 2026
same problem
c0dezli commentedon Jun 3, 2026
same problem and with the lastest update the
`
Add the following configuration in ~/.codex/config.toml:
model_provider = "openai_http"
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false
base_url = "https://chatgpt.com/backend-api/codex"`
approach stoped working too
cshhanec2 commentedon Jun 7, 2026
Если вы с россии, то вот гайд как исправить это и пользоваться Codex в режиме proxy (tun)
Haxel0rd commentedon Jul 16, 2026
Was able to get codex working again for me, in my case the DNS resolution in WSL instance was broken, you can confirm it with running this in your WSL machine:
If this says name or service not known and the following ping returns normal answer:
Then your issue is most likely in
Quickfix: set google DNS as nameserver. This should make codex work again and from that moment on you can tell him to find out why it happened in the first place. resolv.conf should look something like this then:
and curl to auth.openai.com should now work again.
== UPDATE ==
found the source of the problem, it seems to be an issue with stale HSN Firewall rules. I used the following commands, found under https://learn.microsoft.com/en-us/windows/wsl/troubleshooting under "Troubleshooting DNS in WSL" under point 4.:
(note this will remove firewall rules for port 53/udp, usually not a problem unless you have explicit custom setup there).
Then set DNS to local resolver and it my old setup before the quickfix (setting google dns), was working again as usual.
0xYubo commentedon Jul 20, 2026
Fix: token_exchange_failed on login and stream disconnected before completion during use
Environment: Codex CLI 0.136.0 on macOS, using a local HTTP proxy (Clash-style).
Symptoms
Inconsistent proxy environment variables. My shell had the lowercase and uppercase proxy variables pointing to different ports:
https_proxy = http://127.0.0.1:7897 # correct (my real proxy port)
HTTPS_PROXY = http://127.0.0.1:7899 # WRONG port — nothing listening there
curl uses the lowercase https_proxy, so a manual curl https://auth.openai.com/oauth/token worked fine (returned an expected 405, proving the network path was OK). But Codex reads the uppercase HTTPS_PROXY, so it sent the OAuth token exchange (and later the streaming responses requests) to port 7899, where no proxy was listening — hence error sending request for url.
Fix
Make all proxy variables consistent and point to the actual proxy port:
export http_proxy="http://127.0.0.1:7897"
export https_proxy="http://127.0.0.1:7897"
export HTTP_PROXY="http://127.0.0.1:7897"
export HTTPS_PROXY="http://127.0.0.1:7897"
export ALL_PROXY="socks5://127.0.0.1:7897"
Update these in your shell profile (~/.zshrc / ~/.bashrc), then open a new terminal (or source the file) and launch Codex from that session.
Tip: Grep your profile to catch stale/duplicate proxy lines that override each other:
grep -rn -i "proxy" ~/.zshrc ~/.zprofile ~/.bashrc ~/.bash_profile
Note on the streaming error
The stream disconnected before completion error hits the SSE endpoint backend-api/codex/responses, which holds a long-lived streaming connection. If it persists even after the ports are consistent, the proxy itself is likely dropping long connections. Things that helped:
Want me to shorten it into a comment-sized version, or format it as a full issue with a title?
token_exchange_failed
Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)
stream disconnected before completion: error sending request for url
(https://chatgpt.com/backend-api/codex/responses)
Root cause
Inconsistent proxy environment variables. My shell had the lowercase and uppercase proxy variables pointing to different ports:
https_proxy = http://127.0.0.1:7897 # correct (my real proxy port)
HTTPS_PROXY = http://127.0.0.1:7899 # WRONG port — nothing listening there
curl uses the lowercase https_proxy, so a manual curl https://auth.openai.com/oauth/token worked fine (returned an expected 405, proving the network path was OK). But Codex reads the uppercase HTTPS_PROXY, so it sent the OAuth token exchange (and later the streaming responses requests) to port 7899, where no proxy was listening — hence error sending request for url.
Fix
Make all proxy variables consistent and point to the actual proxy port:
export http_proxy="http://127.0.0.1:7897"
export https_proxy="http://127.0.0.1:7897"
export HTTP_PROXY="http://127.0.0.1:7897"
export HTTPS_PROXY="http://127.0.0.1:7897"
export ALL_PROXY="socks5://127.0.0.1:7897"
Update these in your shell profile (~/.zshrc / ~/.bashrc), then open a new terminal (or source the file) and launch Codex from that session.
Tip: Grep your profile to catch stale/duplicate proxy lines that override each other:
grep -rn -i "proxy" ~/.zshrc ~/.zprofile ~/.bashrc ~/.bash_profile
SkiesOfTheKuth commentedon Sep 9, 2026
Still having this issue.
smbell1979 commentedon Sep 10, 2026
This is making Astra 100% unusable for me.
I have yet to have any successful chats. Just constant stream disconnected errors.
LiuJunyuan020919 commentedon Sep 16, 2026
I have solved this problem haha.(I use codex on VPN).check & change your own VPN node;add "export http_proxy=http://127.0.0.1:7897
export https_proxy=https://127.0.0.1:7897" to ~/.bashrc ,and then "source ~/.bashrc" in your terminal .