4 repliesWorkflow33m ago
stream disconnected before completion: Transport error: network error: error decoding response body
Codex drops the stream partway through a long turn and retries, sometimes in a loop. Reported on flaky links, corporate proxies, and reliably after a laptop sleeps.
Active issue
1 confirmation · 2 environments
- Applies through
- 0.144.0 – 0.146.0; long-standing rather than a recent regression
- Last confirmed
- 3d ago
Who confirmed ▸
- jwhitlock · 3d ago
- Applies to
- Codex 0.144.0 – 0.146.0; long-standing rather than a recent regression
- Environments
- Corporate proxies, VPNs, laptops that sleep mid-task · macOS, Windows, Linux
- Severity
- High
Filed by pkoskinen · Jul 21, 2026
No verified fix yet
Nobody has recorded a working fix for this issue. If you found one, it belongs here — and if you tried something that failed, that is worth recording too.
Members' reports are attributed. Anonymous ones are counted separately.
Does it still happen?
What each release of Codex has been reported to do with this issue.
- 0.144.0Not yet tested— running Codex 0.144.0? Tell us below.
- 0.145.0Still affected — 1 report
- 0.146.0Still affected — 1 report
Why this happens
Long turns terminate with one of a family of closely related messages:
stream error: stream disconnected before completion: stream closed before response.complete; retrying...
stream disconnected before completion: Transport error: network error: error decoding response bodyThe retry sometimes succeeds and sometimes loops. Two conditions make it near-deterministic: resuming after the machine has slept, and running behind a proxy that terminates idle connections. On a proxy, it can also surface as stream error: exceeded retry limit, last status: 401 Unauthorized, which is misleading — the credentials are fine, the re-auth on reconnect is what fails.
Likely causeThe response is a long-lived stream. Anything that silently drops an idle connection — a sleeping NIC, a proxy idle timeout, a captive-portal re-auth — closes it before `response.complete`, and the client surfaces the decode failure rather than the disconnect. The 401 variant is the token refresh failing on a connection that was already dead.
Confirmed environments2
| Agent | Version | Model | OS | Framework | Outcome |
|---|---|---|---|---|---|
| Codex | 0.146.0 | GPT-5.5 | macOS 15.5 | — | Reproduced |
| Codex | 0.145.0 | GPT-5.5 | Ubuntu 24.04 | — | Reproduced |
Approaches that failed1
Re-authenticating on the 401
The 401 in the retry-limit message is a symptom of the dead connection, not an auth problem. Logging out and back in changes nothing; fixing the idle timeout does.
bruno.m · 2w ago
Other approaches that worked2
Raise the proxy idle timeout
Our squid config was closing idle connections at 60s. A long reasoning turn is silent for longer than that. Raised to 600s and the loop stopped.
sadiq.dev · 1w ago
Keep the machine awake for the length of the taskpartial
`caffeinate -i codex ...` on macOS. Eliminated the sleep-related half of our reports outright. Does nothing for the proxy case.
pkoskinen · 2w ago
Discussion · 1 comment
Strong evidence gets promoted into the record above.
Sign in to join the discussion, vote, and verify fixes.
Related pages
8 repliesField note1h ago
7 repliesField note2h ago
2 repliesIssue3h ago
3 repliesField note4h ago
If you are behind a corporate proxy, check the idle timeout before anything else. A long reasoning turn sends nothing for minutes at a stretch, which any default-configured proxy reads as a dead connection. Ours was 60 seconds.