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
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses) #10985
@jazz235123, @Higor-Matos, @aqlkzf, thanks for confirming. For bugs like this, it's really important to upload your logs and post the thread ID. Logs are often the key to diagnosing issues like this.
This is my output log: codex-tui.log
I set the proxy like this:
export ALL_PROXY="socks5://127.0.0.1:1080"
export HTTP_PROXY=$ALL_PROXY
export HTTPS_PROXY=$ALL_PROXY
export http_proxy=$ALL_PROXY
export https_proxy=$ALL_PROXY
For me it seems like playwright MCP server is not starting correctly. In the App it therefore results in 5x reconnect, same thread id on cli shows starting mcp server 1/2 playwright not coming up:
for me seemed to be context7 however after going a bit back and forth, disabling, enabling again and rechecking the args I
also set timeout to 40s as recommended, but didn't properly write the setting via codex app.
after disabling it, playwright seemed to remain the issue in the same thread - which it was probably not:
However if you also disable playwright as well, restart everything, problem remains. now it's just "working" in cli and in app "reconnecting":
Alpine Linux v3.22.2 VM on macOS Sequoia 15.6.1 (24G90)
repeatedly receiving "stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)" - issue persists after exiting and resuming session as well as logging out and back in to codex.
Issue not present on any of the sessions within native macOS (outside of Alpine VM).
@randzzD89 While I initially suspected MCP servers not correctly initializing, I now think that it has some weird network reliability issues with routing the traffic correcty in general.
When using my local WiFi-AP that has some routing behind it, it get's stuck waaay more often than when being directly connected to my phone hotspot.
However I don't see any packet loss issues or unusable bandwith with my setup. Codex (as well as Signal Desktop) are the only Apps complaining by not working or taking way too long
Relevant redacted log facts from local logs_2.sqlite:
Current affected thread around 2026-06-26T16:53:22Z uses wire_api=responses, transport="responses_websocket", api.path="responses", and logs a successful websocket connection to wss://chatgpt.com/backend-api/<redacted>.
Same local log DB contains many exact matches for backend-api/codex/responses / stream disconnect behavior. Recent example around 2026-06-26T16:54:08Z-16:54:09Z: Request failed method=POST url=https://chatgpt.com/backend-api/codex/responses error=error sending request for url (...), model gpt-5.5, wire_api=responses, transport="responses_http"; later row at 2026-06-26T16:54:13Z shows status=200 OK for the same endpoint.
Local log DB currently has 638 rows matching stream disconnected before completion or backend-api/codex/responses.
Local network notes:
Google Remote Desktop to the same PC remains stable while Codex streams disconnect.
Wi‑Fi/gateway and internet ping tests showed 0% packet loss; repeated HTTPS probes to chatgpt.com succeeded quickly.
Tried quitting/reopening Codex, refresh, and sign out/in multiple times with no lasting fix.
Also tested by bypassing my local router and connecting directly through the modem. The Codex stream/reconnect issue still recurred, while general remote connectivity to the same PC remained stable. This makes it look Codex-specific rather than a general local connection outage.
Update on 2026-06-26:
The issue is still happening in Windows Codex App during/around the OpenAI status incident Codex Usage Limits Depleting Faster Than Expected, which is currently marked Investigating / degraded performance for Codex.
From the user side, the reconnect loop appears to cause repeated resume/retry cycles. That may be relevant to the usage-limit incident if failed streams are causing Codex to rehydrate context or retry work repeatedly.
The observed pattern is: Codex stream disconnects/reconnects, but Remote Desktop and normal internet connectivity to the same machine remain usable.
I’m not pasting raw full logs publicly because they contain prompts/local paths, but the above is copied from the redacted/filtered diagnostic rows.
Activity
jazz235123 commentedon Feb 8, 2026
same for me
Higor-Matos commentedon Feb 8, 2026
Up...
same for me
aqlkzf commentedon Feb 8, 2026
same for me
etraut-openai commentedon Feb 8, 2026
@jazz235123, @Higor-Matos, @aqlkzf, thanks for confirming. For bugs like this, it's really important to upload your logs and post the thread ID. Logs are often the key to diagnosing issues like this.
jazz235123 commentedon Feb 9, 2026
This is my output log:
codex-tui.log
I set the proxy like this:
export ALL_PROXY="socks5://127.0.0.1:1080"
export HTTP_PROXY=$ALL_PROXY
export HTTPS_PROXY=$ALL_PROXY
export http_proxy=$ALL_PROXY
export https_proxy=$ALL_PROXY
pzauner commentedon Feb 18, 2026
Uploaded Feedback: 019c7144-5938-7140-ac8e-8823da3bddbb
(using /feedback in codex)
pzauner commentedon Feb 18, 2026
For me it seems like playwright MCP server is not starting correctly. In the App it therefore results in 5x reconnect, same thread id on cli shows starting mcp server 1/2 playwright not coming up:
pzauner commentedon Feb 18, 2026
for me seemed to be context7 however after going a bit back and forth, disabling, enabling again and rechecking the args I
also set timeout to 40s as recommended, but didn't properly write the setting via codex app.
after disabling it, playwright seemed to remain the issue in the same thread - which it was probably not:
However if you also disable playwright as well, restart everything, problem remains. now it's just "working" in cli and in app "reconnecting":
pzauner commentedon Feb 18, 2026
disabled everything, tried with completely new thread, after like 10 tool calls it got stuck again.
019c7189-1088-7cd3-a063-24a5213aadb3
completely unusable product unfortuneatly rn. Codex 5.3 is a great model - IFF you can use it.
randzzD89 commentedon Mar 11, 2026
thread ID 019cb97d-0342-71b3-afc6-a15a2acdd65e
Alpine Linux v3.22.2 VM on macOS Sequoia 15.6.1 (24G90)
repeatedly receiving "stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)" - issue persists after exiting and resuming session as well as logging out and back in to codex.
Issue not present on any of the sessions within native macOS (outside of Alpine VM).
pzauner commentedon Mar 11, 2026
@randzzD89 While I initially suspected MCP servers not correctly initializing, I now think that it has some weird network reliability issues with routing the traffic correcty in general.
When using my local WiFi-AP that has some routing behind it, it get's stuck waaay more often than when being directly connected to my phone hotspot.
However I don't see any packet loss issues or unusable bandwith with my setup. Codex (as well as Signal Desktop) are the only Apps complaining by not working or taking way too long
Yyyyyyyyyyfff commentedon Mar 18, 2026
the same problem.
Reconnecting... 1/5
Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
feedback:019cff7d-537e-7c81-88bc-73a871bec89d
NicolayBang commentedon Jun 26, 2026
I’m seeing this on Windows Codex App as well. Adding diagnostics per @etraut-openai’s request.
Thread IDs:
019f03c6-20cb-7273-8ce6-b7dca4c5aecb— active thread where the reconnect/stream-disconnect behavior is happening019f0201-a4ca-7530-8843-1dbc0e34bc84— local log DB contains recent exactbackend-api/codex/responsesrequest failures for this thread tooEnvironment:
OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g00.142.210.0.26200, x64gpt-5.5, reasoning effortxhighcodex doctor --jsonsummary:overallStatus: okhttps://chatgpt.com/backend-api/ reachable (HTTP 403)HTTP 101 Switching ProtocolsresponsestrueRelevant redacted log facts from local
logs_2.sqlite:2026-06-26T16:53:22Zuseswire_api=responses,transport="responses_websocket",api.path="responses", and logs a successful websocket connection towss://chatgpt.com/backend-api/<redacted>.backend-api/codex/responses/ stream disconnect behavior. Recent example around2026-06-26T16:54:08Z-16:54:09Z:Request failed method=POST url=https://chatgpt.com/backend-api/codex/responses error=error sending request for url (...), modelgpt-5.5,wire_api=responses,transport="responses_http"; later row at2026-06-26T16:54:13Zshowsstatus=200 OKfor the same endpoint.638rows matchingstream disconnected before completionorbackend-api/codex/responses.Local network notes:
0%packet loss; repeated HTTPS probes tochatgpt.comsucceeded quickly.Update on 2026-06-26:
Codex Usage Limits Depleting Faster Than Expected, which is currently markedInvestigating/ degraded performance for Codex.I’m not pasting raw full logs publicly because they contain prompts/local paths, but the above is copied from the redacted/filtered diagnostic rows.