Transport timeouts

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

• #8362

Powered by Codex Action

Not closing as duplicate.

While the symptoms are similar to #8362, this issue specifically documents:

1. Impact on Pro subscribers ($200/month tier)
2. Service unavailability duration (Dec 11-20, 9+ days)
3. Request for acknowledgment and compensation for paying customers

The #8362 issue doesn't address the business impact on paying Pro users.
This should remain open for visibility on how this affects premium subscribers.

If you see this again, please use the /feedback command to upload your logs and session, and post the thread ID here.

Thanks for the response. I'll use /feedback next time it occurs and post the thread ID here.

I'm only a plus user but have been experiencing the same problems as @albertodimas for a couple of days now.

I just captured the issue using /feedback
Thread ID: 019b412f-6f91-7293-a6be-1c4a8ee262ff

@kronholmeliah, the error you're seeing ("error decoding response body") is not the same as @albertodimas ("Transport error: timeout"). We are tracking the "error decoding response body" issue in #8302.

Closing - the transport timeout issues have been resolved. The CLI is working properly again. Thanks to the OpenAI team for addressing this.

I'm also plus user but have been experiencing the same problems as @albertodimas for a couple of days now.
v0.77.0
Thread ID 019b4549-0c5f-73f3-b274-79a027bca180

Plus user experiencing same issue and it seems to degrade.

019b4a6b-a231-7353-8a2b-3285530a8663

Plus user, experiencing the same issue for the last week, only now it got worse, making Codex mostly unusable.

Thread ID: 019b4bd9-c446-74d1-bb79-1cb915e2dcf2

Plus user, experiencing the same issue today several times
ID: 019b4ce0-a3e2-76a3-b001-60fd3ea11a00

Thanks for reporting. We're receiving numerous reports of this problem, and the codex team is actively investigating. It appears to be correlated to the gpt-5.2 model, so if you need a temporary workaround, you can try switching back to the gpt-5.1 or gpt-5.1-codex model.

I have the same problem. I am a team subscriber. it costs tokens but codex has not edited code files. a session working for nearly 20minutes but it produces nothing

I’m a Plus user and I’m having the exact same problem.
It doesn’t matter which model I switch to (5.1-Codex-Max, 5.2-Codex, or whatever). The issue is always the same: it starts thinking, then I get “Reconnecting 1/5…”, and eventually it ends with:

“stream disconnected before completion: Transport error: timeout”

ID: 019b5a6b-1d03-7e93-8a0a-3e53ffb14c9f

@pdfquesada, are you sure that you have seen this with the 5.1 series models? The logs that you uploaded (thank you!) show that you're using 5.2-Codex. The reason I ask is that we haven't seen any reports of this from 5.1 series models.

same for me thread ID 019b75e7-1c78-7b71-8136-2a73d660c354

same issue ID: 019b99ec-3a8a-7c23-a734-70fe57ff590b

same problem:019b9c33-cd61-71f0-8ac9-be9367dcd8e6

on gpt 5.1: 019b9c8a-0ecf-7592-a539-ba763e8f6cc3

same here: 019b9cea-0aa0-73b0-b8a3-97de083d1d70

same here - 019bb1a7-08f1-7463-a35d-50f1f65252b1

same here: 019bb464-68ff-7b23-802b-a8bcd22826d8

reconnecting constantly with all models, including 5.2 and 5.1

Same here, but only with xhigh thinking on the beefier models

We think we have mitigated this issue. There are times when the "beefier models" (to quote @fmhall) take longer to generate the next batch of tokens during streaming, and this can sometimes exceed an HTTP timeout value.

I'm going to mark this bug as closed, but if you see this again in the next few days, please use /feedback to upload your logs and post your thread ID here.

Still happening with 0.87 (thread ID: 019be7b5-f905-78d2-8589-9d9edd1a9ebc); not sure which version this was supposed to be mitigated in. In addition to your measures to reduce the likelihood of this issue, I think it would be helpful if the CLI had some more graceful way of dealing with it when it does happen. Right now I'm kind of stuck and basically need to start a new chat after the failure, since I can't re-trigger the call to the backend - at least not without sending additional dummy messages.