Request failed with error: Transport

[edpmatrix]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID intructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log intructions

Describe the bug

By sending the prompt from the console, after much thinking, I frequently have the following answer:

I'm sorry, I couldn't complete that request.

Request failed with error: Transport(reqwest::Error { kind: Decode, source: hyper::Error(Body, Error { kind: Io(Custom { kind: UnexpectedEof, error: "peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof" }) }) })

It seems that the event is related in some way to excessive traffic on the network, but it is very annoying because it prevents you from completing any activity. At the beginning, Warp seemed to work correctly and satisfactorily, but with the passing of the days this degradation becomes more and more frequent, making any job impossible. this is my debug id: {"conversation_id":"752a06ee-d8be-4fb5-8e1f-d59c9d40d0ad"}

To reproduce

Sending a promt...

Expected behavior

No response

Screenshots, videos, and logs

No response

Operating system (OS)

Linux

Operating system and version

OpenSuse leap 15.6

Shell Version

bash versione 4.4.23(1)-release (x86_64-suse-linux-gnu)

Current Warp version

v0.2025.08.27.08.11.stable_03

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[dcambria]

{"conversation_id":"58888a36-53ec-4cd4-bd74-0fb744f1e8fc"}
v0.2025.09.01.20.54.stable_04
same here

[haizhouyuan]

same with me

[Joselillo2004]

I know this is a tricky area and not urgent — just sharing observations.

After some extended testing on my side, I noticed the same error pattern under a few different conditions:

• Observed with Claude Opus 4.5 (Thinking enabled)
• Also observed with GPT-5.2 (extra-high reasoning)
• Environment: Cloudflare WARP enabled

The error message is consistently:
“peer closed connection without sending TLS close_notify”
(UnexpectedEof)

What seems to trigger it in my setup:

• Longer, multi-step prompts
• Large structured outputs (scripts + markdown)
• Workflows that rely on continuing a conversation after partial responses

Different models appear to fail at different rates, but the error signature is the same.
I haven’t done exhaustive testing yet, so this is based only on repeated observations.

I may be misinterpreting this, but it felt more related to long-lived or stateful
connections than to any specific model or prompt content.

Sharing this in case it aligns with something you’re already tracking.
Thanks for the work you’re doing!

[leeloo1]

when this will be fixed? happen too often to me; especially if I created a good plan and just wanna execute it. I selected auto (response) mode.

[warp-factories]

We need a bit more information before we can continue triaging this issue.

If you're still hitting this, could you try reproducing it on the latest version of Warp and share logs along with a screenshot or short video if possible?

If there's no activity after 3 business days, we'll close this out to help keep the tracker tidy.

---

This is part of an automated backlog review and may be inaccurate. If you believe this assessment is wrong, please let us know.

[leeloo1]

i dont know: i recently had it with {"conversation_id":"6c4740b3-20a5-47b7-a84e-4d61d2941eaa"}

v0.2026.04.08.08.36.stable_05

Request failed with error: Transport(reqwest::Error { kind: Decode, source: hyper::Error(Body, Error { kind: Io(Custom { kind: UnexpectedEof, error: "peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof" }) }) })

Attempting to resume conversation...
I'm sorry, I couldn't complete that request.

Request failed with error: Transport(reqwest::Error { kind: Decode, source: hyper::Error(Body, Error { kind: Io(Custom { kind: UnexpectedEof, error: "peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof" }) }) })

[whoshallsucceed]

Same here three consecutive times. Usually, it happens once and retrying is fine but not today.

{"conversation_id":"c2714390-7e1d-45dd-8dfa-5c102916833d"}

[meehol]

Still reproducing on current stable, with new detail about the recovery path and a model-specific pattern.

Environment

• Warp stable v0.2026.09.30.08.29.stable_01 (up to date per the updater log)
• macOS, zsh

Error

Request failed: Transport(reqwest::Error { kind: Decode, source: hyper::Error(Body, Error { kind: Io(Custom { kind: UnexpectedEof, error: "peer closed connection without sending TLS close_notify" }) }) })

What the log shows (2026-10-03 UTC)

1. 03:27:37 MultiAgent request failed; recovering: recovery=resume attempt=1/3 failed_request=original
2. 03:30:23 same error, attempt 1/3 again on a new request
3. 03:31:27 attempt=2/3 failed_request=resume
4. 03:32:31 attempt=3/3 failed_request=resume
5. 03:33:35 MultiAgent request failed; not recovering: recovery=none reason=budget_exhausted attempt=3/3

Every attempt ends with the same UnexpectedEof. The log also reports is_online=true and is_recoverable=true the whole time, so Warp knows the network is up but the retry never succeeds. After the budget is exhausted the conversation sits in status=Error, and later messages log Tried to update output for message which no longer has a client representation. The user sees no reply to new prompts.

The same sequence repeated at 03:59 on a fresh prompt.

Pattern worth checking
The reporter saw responses work normally with a Warp-hosted model (Auto/Genius) and fail silently with an Anthropic BYOK model in the same session and on the same network. The log does not record which model each request used, so this is the reporter's observation, not something proven by the log. Anthropic's status page showed all systems operational throughout.

Requests

• Log the selected model/provider and whether the request used a user API key next to the transport error, so BYOK vs hosted failures can be told apart.
• Show a clear error in the conversation when the retry budget is exhausted, instead of leaving later messages with no visible response.
• Offer a manual "retry this request" that starts a fresh stream instead of only resuming the broken one.
• Consider whether the response stream is being closed without close_notify on the BYOK path (proxy or timeout on long streams), which rustls treats as an error.

[meehol]

pozdro 600 ziomki. everything is dandy, lets go! https://www.youtube.com/watch?v=ZWijx_AgPiA