stream disconnected before completion: Transport error: network error: error decoding response body

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #8465
• #8476
• #8467

Powered by Codex Action

Did you use the /feedback command to upload your logs and session details? I don't see it in our database.

Are you using the OpenAI endpoint, or by chance are you using an Azure-hosted model?

Run of the mill Pro sub, no paid API no Azure. I'll upload the logs, I thought it was either or, and thought both would be duplicative (and you could see everything from the thread ID). I uploaded the feedback. I'll start there and create thread from template next time.

I'm now able to access your logs, but I don't see any sign of a transport error or any other "reconnecting" attempts.

How confident are you that the current version still passes this particular error with the logs attach tool? They output inline as they occur and I have them logged, but they don't appear in the JSONL transcript or the TUI log from what I see.. do you see the latency from input message to first tokens received client side? See attached for session ID's and first error lines, ALL of these represent at LEAST a ~12m delay from input until the first reasoning tokens appear. Then there are subsequent errors that represent additional delays. It's a huge blocker for me at the moment.

<img width="2481" height="1519" alt="Image" src="https://github.com/user-attachments/assets/e941814c-b19a-4f58-a4bc-028f4706d30f" />

How confident are you that the current version still passes this particular error with the logs attach tool

Pretty confident. I review many of these logs every day. :)

I suspect what happened is that you restarted codex or started a new session after the error occurred, and that cleared your log. If this is something you can readily reproduce with a new session, please use /feedback right away after the problem occurs.

019bf7ad-9cdc-7e30-a9e1-517068e0a6c4
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 1/100 (stream disconnected before completion: Transport error: network error: error decoding response body)"}

019bf8b3-50e9-7890-b761-1dfe6abe0b89
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 1/100 (stream disconnected before completion: Transport error: network error: error decoding response body)"}

019bf6e8-c6ae-7931-8aec-30dedd66124b
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 1/100 (stream disconnected before completion: Transport error: network error: error decoding response body)"}

019be6ed-b8bb-7732-aab6-3e36c966e6ec
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 1/5 (stream disconnected before completion: Transport error: network error: error decoding response body)"}

019bd7a4-e774-7f33-854a-1cd411381af3
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 1/5 (stream disconnected before completion: Transport error: network error: error decoding response body)"}

This happens with exec so feedback is always a resume action after the fact

Ah, I missed the fact that this was an exec (non-interactive) session.

Here are the things that I'd look for if I had your logs in front of me:

1. Does it look like an auth issue? If you're using the API key auth method, are you sure that it's a valid API key?
2. Are you using the standard OpenAI responses endpoint, or have you overridden it (e.g. with the OPENAI_BASE_URL env variable or with a custom model provider config)?

Do you have any non-default config options defined in your config.toml file?

To be clear this works using the same config on smaller inputs. It works using the same input on the mini model. It (sometimes) works if its left to just run to completion as-is. The issue is, it takes forever and something is clearly wrong. I left a run going last night, it's been running for 6+ hours on a single exec and it's on reconnect 16/100. Stopping it would be very sad as it's a critical stage. As you can see it's a huge barrier right now. What would you recommend I do for the current exec one in-progress, if I resume it separately while it's still running from inside python, is that going to break something, given your desire for /feedback intra-run, or was that only for non-exec? The config.toml is almost bare other than the retry overrides needed to get this to work (listed with initial issue info at the top), it's a seperate CODEX_HOME that uses a stripped toml for exec (another issue is the hacky work around required to remove skills injection into context). It's very bare though.

I am using a custom model_provider id, a duplicate of the original settings, so I can override stream_idle_timeout_ms and stream_max_retries without being blocked by built‑in provider defaults. This was done in response to the issue though, and it allows the run to actually complete rather than exit on repeated failures. It's a mirror of what's in auth.json and works without issues (remember this works on mini model and other inputs).

Alright, like all good blockers, this forced me to re-think/refactor the code for this section, and I got it working.

TLDR: issue is real, it's 100% from massive JSON output. Prompting for smaller output fixes it..

Change the prompt to gen small output, works fine. This is the RCA I had codex come up with to paste here:

Codex Generated RCA Update — Relative timings + minimal vs huge output

Relative timings (same model gpt-5.2-codex, reasoning xhigh):

Large structured JSON output

• WebSockets transport
• Start → first token: 10m 22s
• Start → first stream error: 15m 03s
• Start → second stream error: 30m 03s
• SSE transport (websockets disabled)
• Start → first token: 13m 37s
• Start → first stream error: 15m 01s
• Start → second stream error: 30m 03s

Minimal structured JSON output

• Start → first token: 3s
• Start → completion: 5s
• No stream errors

———

### What breaks it (example)

Large, schema‑constrained JSON output:
The prompt asks for a full detection “truth map” plus multiple synthetic payload packs with many rows per table.
This requires emitting a very large, deeply nested JSON response (dozens of constraint entries + multiple packs + many rows + values arrays).
That consistently triggers long stalls and stream decode errors.

———

### What fixes it (example)

Minimal JSON using the same schema:
Prompt requests the smallest valid JSON that satisfies the schema (1 truth_map entry + 1 pack + 1 row).
This completes in seconds with no errors.

———

### Conclusion

The strongest signal is that output size/complexity is the trigger.
The same model + schema + runtime completes quickly for tiny JSON outputs, but stalls and breaks streams for very large structured JSON.
This points to a streaming/serialization issue, not a model failure or local process crash.

Thanks for the analysis.

Yeah, it sounds like your usage is pretty far out of the normal distribution.

Do you have a sense for how large these outputs are (rough number of characters)? Are we talking about tens or hundreds of K?

same issue on the codex app today: ID #019c270b-1c2c-7dc1-9b94-2bf19bd90ac2

my feedback id 019c5703-6b90-72c0-a727-8c052156fe25