AI request fails with TLS unexpected EOF (peer closed connection without TLS close_notify)

[edwifiguy]

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

Describe the bug

When sending a request to the Warp AI agent, the request fails mid-flight with a TLS transport error. The connection is dropped by the peer without sending a TLS close_notify, causing an unexpected EOF. The error is surfaced to the user as:

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" }) }) })

To reproduce

1. Open Warp and start an AI agent conversation
2. Send a prompt to the AI
3. Observe the error message instead of a response

Expected behavior

The AI agent completes the request and returns a response without a transport/TLS error.

Screenshots, videos, and logs

Debug ID: cd5fb799-035a-4662-82d7-61504badc115

Operating system (OS)

Linux

Operating system and version

Ubuntu 25.10

Shell Version

bash 5.2.37(1)-release

Current Warp version

v0.2026.03.18.08.24.stable_03

Regression

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

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.

Additional context

Running on Linux (Ubuntu 25.10). The TLS error suggests the server-side connection is being terminated abruptly without a clean TLS shutdown handshake, which may point to a backend infrastructure or load-balancer issue dropping long-running or large responses.

[leesa-ui-w]

Thank you for bringing this to our attention. This issue is tracked under #7247    Please comment, 👍 upvote and subscribe there for updates. Closing as a duplicate.

[edwifiguy]

Update — Error persists with confirmed stable local connectivity

I've done extensive local network investigation and can confirm this error still occurs even when WiFi is fully stable:

• Signal: -34 dBm (excellent)
• Connectivity: full (no oscillation)
• Packet loss: 0% to 8.8.8.8
• NetworkManager: No disconnects or state transitions at time of error
• Regulatory domain: Corrected and verified

I previously had local WiFi instability that was also triggering this error, which I've since resolved (wrong regulatory domain causing connectivity oscillation). However, the TLS close_notify error continues to occur sporadically even with a perfectly stable connection.

This reinforces that there is a server-side component — the peer (Warp backend or load balancer) is terminating the TLS connection without a clean shutdown handshake during active AI agent requests.

Environment:

• Ubuntu 25.10
• Warp v0.2026.03.18.08.24.stable_03
• bash 5.2.37(1)-release

Co-Authored-By: Oz oz-agent@warp.dev

[edwifiguy]

Update 2 — Root cause identified: VPN routing caused 25-30% packet loss on Warp's path

Deeper investigation revealed that PIA VPN was routing all Warp traffic through a WireGuard tunnel (wgpia0), which:

1. Introduced 25-30% packet loss at the first VPN upstream hop (158.173.24.124)
2. Reduced MTU from 1500 to 1414 (MSS 1362), adding fragmentation risk
3. Caused a 1.72% TCP retransmit rate (should be <0.1%) and 2000+ connection resets

This packet loss on the VPN path was causing long-lived TLS streaming connections (used by Warp AI agent) to be severed mid-transfer, triggering the close_notify error.

Fix applied:

• Added direct host routes for Warp IPs (34.117.41.85, 54.175.92.109) bypassing VPN
• Created persistent NetworkManager dispatcher script
• Tuned TCP keepalive (300s vs 2h), enabled MTU probing, disabled slow start after idle

Result after bypass:

Direct route (bypassing VPN): 0% packet loss across all hops
VPN route (before fix): 25-30% packet loss at hop 2

The TLS error had three contributing factors:

1. PIA VPN path packet loss (fixed — bypassed)
2. Wrong WiFi regulatory domain (fixed — FR→GB)
3. Warp server-side TLS termination (still present — tracked as known issue)

Will monitor over 48 hours to confirm resolution.

Co-Authored-By: Oz oz-agent@warp.dev