Stream disconnected before completion: Transport error

Related to #2921 ?

Related to #2921 ?

Yep, same problem. But no effective solution was found. Some
people suggested restarting codex , but this moethod is too troublesome.
Wait for this issue to be fixed.

same issue for two days, cannot complete even one task

same issue +1

+1

Version 0.39 sames to have solved this problem. At least I haven't encountered this problem today. Try updating to the latest version.

I'm still having the same issue on codex-cli 0.39.0

+1. Tried different VPNs and not solving the problem

+1 I've run into the same issue these past few days
But my access speed to ChatGPT is actually very fast

+1

I had this issue today. Was looking at my DNS logs while seeing the reconnect messages and noticed my host making calls to openrouter.ai

I had OPENAI_API_KEY env var set as part of Qwen CLI testing and this was causing the failure (and routing to openrouter for some reason?). I am using OAUTH auth to use Codex, not the API key.

Unsetting the env var re-enabled Codex CLI for me.

same

same!

+1

+1

Version: 0.4.14
Still see a lot of this in Codex's work steam, though is not going to 5/5 very often any more. It's feels odd that it wouldn't be able to decode the response from their own servers well enough to at least tell you what actually is wrong. Either this error is too generic, or it's possible for the endpoint to respond in an unparseable format.. Which would be odd because they control both sides.

+1

+1

+1

+1

+10

+1 same problem in 0.4.14

Gett this as well.

Gett this as well.

+1

+1

+1

I cannot use it the whole night

same issue +1, totally unusable

+1

+1

+1

+1

+1000

+1

+1 even new version 0.44.0

why this is still present even on the version 0.46.0? seriously it's so embarrassing. 30% of the time when I want to code I receive this.

I have given up useing codex and i now use copilot. Copilot supports codex model.

0.46.0, still often got this error:
 stream error: stream disconnected before completion: Transport error: error decoding response body; retrying 1/5 in 214ms…

⚠️ stream error: stream disconnected before completion: Transport error: error decoding response body; retrying 2/5 in 388ms…

⚠️ stream error: stream disconnected before completion: Transport error: error decoding response body; retrying 3/5 in 865ms…

⚠️ stream error: stream disconnected before completion: Transport error: error decoding response body; retrying 4/5 in 1.725s…

⚠️ stream error: stream disconnected before completion: Transport error: error decoding response body; retrying 5/5 in 3.004s…

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

I’m having the same problem as you — it’s really frustrating.I’m thinking of giving up on it; maybe Claude Code is a better choice.

Hey folks, sorry for the silence here. We are now actively working on getting to the bottom of what is causing these issues and we'll keep you posted with our findings over the coming days. I have gone through other duplicate filed issues and we will use this as the master one to track progress going forward.

I apologize for slow progress here. I tend to believe there are multiple underlying causes behind the same error message. Folks that still see this error can you please include the following information in the report:

1. Do you have VPN installed/enabled?
2. Is the error intermittent? Does it persists after it starts? Does it go away if you restart codex or run /new?
3. How full is the context?
4. Do you use image inputs? Do you expect codex to pick up image files are part of the turn?
5. How long is the delay between sending the message and seeing the error?

Really appreciate any information you can provide.

@pakrym-oai I used a third-party LLM in Codex, and after adding a 3-second scheduled ping event in the stream event, this issue no longer occurs. I suspect that the Codex stream has an idle timeout limit.

Claude Code also has a 10-second stream event idle timeout issue; they will retry once with stream=false.

I apologize for slow progress here. I tend to believe there are multiple underlying causes behind the same error message. Folks that still see this error can you please include the following information in the report: 1. Do you have VPN installed/enabled? Yes, VPN installed and running. 2. Is the error intermittent? Does it persists after it starts? Does it go away if you restart codex or run /new? The error occurs everyday. Restarting codex usually doesn't help. I have to wait a few hours and sometimes the problem goes away for a few hours and then reappears. 3. How full is the context? It doesn't matter. It can happen right after I start codex. 4. Do you use image inputs? Do you expect codex to pick up image files are part of the turn? Sometimes. 5. How long is the delay between sending the message and seeing the error? Sometime the error shows up a few seconds I send my request in codex. Usually the error will most likely occur when doing refactoring or something requiring a lots of code changes. A simple bug fix usually will not trigger the error.

I'm on Pro plan and now I only can effectively use codex for less than an hour everyday. It's very frustrating. If the error persists, I have to switch to another product.

i have same problem i use pro

same here

@armotxa , @OutOfOdds can you include the following information please:

Do you have VPN installed/enabled?
Is the error intermittent? Does it persists after it starts? Does it go away if you restart codex or run /new?
How full is the context?
Do you use image inputs? Do you expect codex to pick up image files are part of the turn?
How long is the delay between sending the message and seeing the error?

same problem%(

@pakrym-oai @tibo-openai seems https://github.com/openai/codex/blob/fc1723f13185a06e29ee263c05b6e0750024daaf/codex-rs/core/src/default_client.rs#L135 need add // Disable reqwest's 30s default so long-lived response streams keep flowing.
.timeout(None::<Duration>) like as responses-api-proxy/src/lib.rs.

@caozhiyuan default reqwest timeout is None -

https://github.com/seanmonstar/reqwest/blob/master/src/async_impl/client.rs#L271-L272

<img width="841" height="432" alt="Image" src="https://github.com/user-attachments/assets/fdcb447a-a2dc-429a-9f74-1851029c0856" />

@pakrym-oai This issue occurs when there is a significant time interval between response API stream events, for example, when the response.reasoning event is returned long after response.in_progress. so i add a 3-second scheduled ping event in the stream event, this issue no longer occurs. I'm not very familiar with Rust, so I can't debug it.

遇到了相同的问题

@armotxa , @OutOfOdds can you include the following information please: Do you have VPN installed/enabled? Is the error intermittent? Does it persists after it starts? Does it go away if you restart codex or run /new? How full is the context? Do you use image inputs? Do you expect codex to pick up image files are part of the turn? How long is the delay between sending the message and seeing the error?

1. No
2. The error occurs every day and restarting Codex or fresh logins do not help.
3. this occurs regardless of the context size.
4. No.

as someone said, it seems to happen when doing something that requires a lots of code changes.

I am a PRO user.

⚠️ ⚠️ ⚠️
Can someone experiencing this issue use the /feedback command available in the latest version of codex (0.47.0) to share their logs? Alternatively can you please include request IDs in your report

@pakrym-oai

responses-handler-2025-10-18.log ps: date is GMT+8

codex-feedback-0199f47b-081d-7272-8481-be348354324f.log

@caozhiyuan can you reproduce the same issue not agains a custom responses server?

@pakrym-oai I am using GitHub Copilot GPT-5-Codex, forwarded through the API; it needs to be tested by others who have an OpenAI Pro account.

Latest version 0.47.0
The error occurred and used /feedback to report:

stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9904a210ccea2672-SEA

• Codex logs uploaded. Please open an issue using the following URL:

https://github.com/openai/codex/issues/new?template=2-bug-report.yml&steps=Uploaded%20thread:%200199f44c-948a-7bd1-a3eb-421b5838a8f8

Or mention your thread ID 0199f44c-948a-7bd1-a3eb-421b5838a8f8 in an existing issue.

@pakrym-oai @tibo-openai hey guys any news? it is very hard to use GPT-5-Codex with this issue...

After testing, it is a server-side issue. I used TypeScript to forward the LLM request; the Hono server's streamSSE events pause for about ten seconds, during which the server sends a FIN packet to the Codex HTTP client, unless ping messages are sent periodically. It is not a Codex client issue. The Codex client can only retry with stream=false, similar to the retry strategy used by Claude Code.
this is my test code
export const server = new Hono()
server.get("/demo/sse", (c) =>
streamSSE(c, async (stream) => {
await stream.writeSSE({ event: "message", data: "first" })
await new Promise((resolve) => setTimeout(resolve, 15000))
await stream.writeSSE({ event: "message", data: "second" })
}),
) , use rust Connecting to SSE endpoint: http://localhost:4141/demo/sse
Listening for SSE events. Press Ctrl+C to stop.
Received event type 'message' with data:
first
SSE stream error: Transport error: error decoding response body
SSE stream ended. . @pakrym-oai

This issue can be identified as a server-side problem by capturing packets with Wireshark.

Thank you for the information @caozhiyuan .

There are customers hitting this issue that are not using custom proxies/servers.

After testing, it is a server-side issue. I used TypeScript to forward the LLM request; the Hono server's streamSSE events pause for about ten seconds, during which the server sends a FIN packet to the Codex HTTP client, unless ping messages are sent periodically. It is not a Codex client issue. The Codex client can only retry with stream=false, similar to the retry strategy used by Claude Code. this is my test code export const server = new Hono() server.get("/demo/sse", (c) => streamSSE(c, async (stream) => { await stream.writeSSE({ event: "message", data: "first" }) await new Promise((resolve) => setTimeout(resolve, 15000)) await stream.writeSSE({ event: "message", data: "second" }) }), ) , use rust Connecting to SSE endpoint: http://localhost:4141/demo/sse Listening for SSE events. Press Ctrl+C to stop. Received event type 'message' with data: first SSE stream error: Transport error: error decoding response body SSE stream ended. . @pakrym-oai

ps: i use bun server , if set idleTimeout: 0 , also will not disconnect.

I have same problem on Codex v0.47. @caozhiyuan could you share workaround patch for Codex? I'm sure OpenAI team is working on fix but the situation is so bad that I cannot work meanwhile unless there is a functional workaround.

Request IDs: 99211441bb890cd3-CDG, 9922e76f3e1f3219-CDG

@sentinel-rouge can you please use /feedback and upload your logs after the issue happens?

I'm using 4G/5G connectivity and believe that is one of the causes of the issue. Mobile connections may have latency variations and jitter that could cause unstable connections if not carefully handled. I did my own fix/workaround with TCP and HTTP keep alive using default settings that work also on mobile connectivity. With the fix I no longer can reproduce the problem.

From 7224672a236178853f838efc1d4c44c179d6849d Mon Sep 17 00:00:00 2001
From: Sentinel Rouge <sentinel-rouge@users.noreply.github.com>
Date: Tue, 21 Oct 2025 21:01:30 +0200
Subject: [PATCH] Add HTTP2 and TCP keepalive with sensible defaults for mobile connections

---
 codex-rs/core/src/default_client.rs | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/codex-rs/core/src/default_client.rs b/codex-rs/core/src/default_client.rs
index 42690e04..d0be5a07 100644
--- a/codex-rs/core/src/default_client.rs
+++ b/codex-rs/core/src/default_client.rs
@@ -3,6 +3,7 @@ use reqwest::header::HeaderValue;
 use std::sync::LazyLock;
 use std::sync::Mutex;
 use std::sync::OnceLock;
+use std::time::Duration;

 /// Set this to add a suffix to the User-Agent string.
 ///
@@ -135,7 +136,13 @@ pub fn create_client() -> reqwest::Client {
     let mut builder = reqwest::Client::builder()
         // Set UA via dedicated helper to avoid header validation pitfalls
         .user_agent(ua)
-        .default_headers(headers);
+        .default_headers(headers)
+        .http2_keep_alive_while_idle(true)
+        .http2_keep_alive_interval(Duration::from_secs(30))
+        .http2_keep_alive_timeout(Duration::from_secs(90))
+        .tcp_keepalive(Some(Duration::from_secs(120)))
+        .tcp_keepalive_interval(Duration::from_secs(20))
+        .tcp_keepalive_retries(3);
     if is_sandboxed() {
         builder = builder.no_proxy();
     }
--

@pakrym-oai just a heads up. I was having this exact same problem because I was using my own forked version, with gpt5-codex, that always set store to true. I wanted to view the response logs on the website. This worked for a while, but now it's failing and the Responses API is simply returning a generic error. Perhaps one or two other people out there were as foolish as me.

@sentinel-rouge interesting. In theory the only value you need to increase is the .tcp_keepalive_interval that is the time between checks. We don't use HTTP2 and tcp_keepalive_retries == 3 by default. tcp_keepalive only delays how soon keepalive request start.

Can you try leaving only the tcp_keepalive_interval set 40 and seeing if that still helps?

Same error

I've been using my keepalive fix actively since yesterday and haven't encountered any issues nor seen the stream/transport error.

@sentinel-rouge interesting. In theory the only value you need to increase is the .tcp_keepalive_interval that is the time between checks. We don't use HTTP2 and tcp_keepalive_retries == 3 by default. tcp_keepalive only delays how soon keepalive request start. Can you try leaving only the tcp_keepalive_interval set 40 and seeing if that still helps?

I started using build with .tcp_keepalive_interval(Duration::from_secs(40)) option only. I'll report feedback tomorrow about it after I use it awhile.

Ok, the 40s TCP keepalive seem to work:

From d417faf7a4f621b8b2d8fab61992328600accb9d Mon Sep 17 00:00:00 2001
From: Sentinel Rouge <sentinel-rouge@users.noreply.github.com>
Date: Tue, 21 Oct 2025 21:01:30 +0200
Subject: [PATCH] Add 40 second TCP keepalive for mobile connections

---
 codex-rs/core/src/default_client.rs | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/codex-rs/core/src/default_client.rs b/codex-rs/core/src/default_client.rs
index 42690e04..92c18029 100644
--- a/codex-rs/core/src/default_client.rs
+++ b/codex-rs/core/src/default_client.rs
@@ -3,6 +3,7 @@ use reqwest::header::HeaderValue;
 use std::sync::LazyLock;
 use std::sync::Mutex;
 use std::sync::OnceLock;
+use std::time::Duration;

 /// Set this to add a suffix to the User-Agent string.
 ///
@@ -135,7 +136,8 @@ pub fn create_client() -> reqwest::Client {
     let mut builder = reqwest::Client::builder()
         // Set UA via dedicated helper to avoid header validation pitfalls
         .user_agent(ua)
-        .default_headers(headers);
+        .default_headers(headers)
+        .tcp_keepalive_interval(Duration::from_secs(40));
     if is_sandboxed() {
         builder = builder.no_proxy();
     }
--

same issue, thread ID 019a102b-5721-7bb1-8814-6a451b298fd4

@tillkolter looking at your logs it seems that the client reconnected and continued. Is this not the experience you had?

@pakrym-oai ,I'm so excieted to receive your reply. I have to use a VPN due to regional reasons, this problem does not appear as soon as codex is turned on. Usually it will appear more often after one or two rounds of converstaion,Restarting the codex will clear it up for a short while, but then it will recur . I'm a Java develper, and each class in my projects averages around 1,000 lines, with the model requiring methods to be reconginzed within 10 layers, Since I didn't record the actual number of tokens used, i can only provide the code size.

same issue

Since this bug report was created, we've fixed many bugs that resulted in a "Steam disconnected before completion: Transport error". It's possible that there are still some lingering issues, but we will need additional repro steps and details to diagnose those. If you see this error with a recent version of codex, please open a new issue.

im getting error in vscode. it says: stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID 19298611-0816-4bdd-86b9-1cf8efcbb3dd in your message.

still happening. stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id:
9a2dd9313bffe5b5-DFW

and one more approve. stream disconnected before completion: Transport error: Error while reading the server response: error decoding
response body, request id: 9a2ddcfeac1b55a1-BKK

'OpenAI Codex (v0.63.0) '

Keeps happening to me. ChatGPT was also behaving oddly for me just now.

■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id:
9a2ddd329d8828fd-LAX

■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id:
9a2ddb780b66f434-LAX

■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id:
9a2dd86499eb24e5-LAX

■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id:
9a2dd86499eb24e5-LAX

Same issue here! Started happening 20 minutes ago.
I did logout and login but still happening.

Same here, right now

same wtf

facing the same thing:
■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2de4fb0e90ff78-CGK

same:
stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2ddd30be80ddc4-HKG

stream disconnected before completion: Transport error: Error while reading
the server response: error decoding response body, request id: 9a2ddb45ef17e361-
NRT

stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2de5f198b9240f-FRA

Keeps happening to me. ChatGPT was also behaving oddly for me just now. ■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2ddd329d8828fd-LAX ■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2ddb780b66f434-LAX ■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2dd86499eb24e5-LAX ■ stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2dd86499eb24e5-LAX

I reported my session via codex and so you have my logs. thread id: 019aa7e0-edc5-7731-8c77-8a023995e720

OpenAI Codex (v0.61.0)

Yes, Codex is having difficulties, please remain calm ❤️

Please follow the incident for updates

Still happening

stream disconnected before completion: Transport error: Error while reading the server response: error decoding response body, request id: 9a2de72c6f595134-CMB