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

same for me

Up...
same for me

same for me

@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

Uploaded Feedback: 019c7144-5938-7140-ac8e-8823da3bddbb

(using /feedback in codex)

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:

<img width="588" height="92" alt="Image" src="https://github.com/user-attachments/assets/906f8d3e-9598-4b66-b941-654a616f32b6" />

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.

<img width="821" height="203" alt="Image" src="https://github.com/user-attachments/assets/d27d21eb-48cd-4ac5-8df0-5ac1410b45c1" />

after disabling it, playwright seemed to remain the issue in the same thread - which it was probably not:

<img width="470" height="104" alt="Image" src="https://github.com/user-attachments/assets/1de475cb-1654-43e2-bc22-6149401832a5" />

However if you also disable playwright as well, restart everything, problem remains. now it's just "working" in cli and in app "reconnecting":

<img width="453" height="120" alt="Image" src="https://github.com/user-attachments/assets/ee0a6d14-bea0-4d5c-854a-b1384180d004" />

<img width="659" height="476" alt="Image" src="https://github.com/user-attachments/assets/59d6e043-5510-42af-af1f-2c3d481401e0" />

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.

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).

@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

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

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 happening
• 019f0201-a4ca-7530-8843-1dbc0e34bc84 — local log DB contains recent exact backend-api/codex/responses request failures for this thread too

Environment:

• Codex App package: OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0
• Codex CLI / doctor version: 0.142.2
• OS: Windows 11 Home, 10.0.26200, x64
• Auth mode: ChatGPT
• Model in affected runs: gpt-5.5, reasoning effort xhigh
• Proxy env vars: none

codex doctor --json summary:

• overallStatus: ok
• provider reachability OK: https://chatgpt.com/backend-api/ reachable (HTTP 403)
• websocket reachability OK: HTTP 101 Switching Protocols
• wire API: responses
• supports websockets: true

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.