[BUG] After a network change, the next request hangs 184 s on a dead connection before retrying (Linux) #98184

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Environment

• Claude Code: various versions, latest was 2.1.288 (all CLI, interactive) that has the bug
• OS: Ubuntu 24.04.5 LTS, laptop, running Claude Code directly on the host
• Terminal: GNOME Terminal (VTE 0.76), Ubuntu 24.04

What happens
After the laptop switches to a different Wi-Fi network, the next prompt gets no response for about
3 minutes. The network itself works: other programs and a freshly started Claude Code reach
api.anthropic.com right away. The debug log (claude --debug) shows that Claude Code sends the
request, waits 184 s for response headers, aborts, and then succeeds on the first retry within 3 s:

14:07:01.697Z [DEBUG] [API:timing] dispatching to firstParty model=claude-opus-5-5
14:07:01.698Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=24accbb4-0480-4c5d-9fe2-cd5b07884704 source=repl_main_thread
14:07:14.301Z [ERROR] 1P event logging: 286 events failed to export (code=ECONNABORTED, timeout of 10000ms exceeded)
14:07:31.697Z [WARN] Slow first byte: no stream chunk 30.0s after request sent (attempt 1)
14:10:05.699Z [ERROR] [first-byte] no response headers 184s after dispatch — aborting request
14:10:05.702Z [ERROR] API error (attempt 1/11): undefined Connection error.
14:10:05.702Z [WARN] [dispatch] connection error with anthropic-dispatch-id=v2d; retrying once with anthropic-dispatch-id=v2p
14:10:05.720Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=68ac2909-bbf8-408d-a292-983edadf5d04 source=repl_main_thread
14:10:08.814Z [DEBUG] [API:timing] first byte after 3103ms

The Wi-Fi switch happened between the previous response (14:06:47Z) and the second request (14:07:01Z).
The request presumably went out over a pooled connection that belonged to the old network and can
no longer deliver anything.

The client already notices the problem after 30 s ("Slow first byte" warning) but keeps waiting until 184 s.

During the 3 minutes, the interface shows only the normal spinner. When the wait ends, it shows
this message for about one second before the retry succeeds:

No response from the API after 3m · retrying once, waiting up to 10m
A proxy or gateway that buffers streaming responses can cause this · set CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS to change the first wait

No proxy or gateway is involved here, so the hint points in the wrong direction. With
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=30000, the same test waits 34 s instead of 184 s and then
succeeds on the retry, so the variable shortens the wait but does not avoid it.

Minor

• The error line reads "API error (attempt 1/11): undefined Connection error." The "undefined" looks
  like a missing value in the message.

Related

• [BUG] Established connections to the API go silent; client waits 180s+ before retrying (retry then succeeds in ~1.5s) #91502 (open) shows the same log lines ([first-byte] no response headers ... aborting request,
  then undefined Connection error., then a fast successful retry) on macOS, but occurring
  randomly without a known trigger. This may be the same problem; the Wi-Fi change here is a
  reliable way to trigger it.
• [BUG] Stalls before response headers have only the 600s API_TIMEOUT_MS backstop — silent 3-10 minute hangs with no error or retry #83238 (open): stalls before response headers have only the 600s API_TIMEOUT_MS backstop.
• [Bug] Missing wake notification handler causes stale socket connections after system sleep #89545 (open): stale sockets after sleep on macOS because the wake event is not handled.
• Earlier reports of stale connections after sleep or network changes were closed without a fix:
  Claude Code CLI unresponsive for ~5 minutes after laptop resume from suspend (Linux) #32116 (after suspend, ~5 min, closed as not planned), [BUG] Stale connection pool after sleep/wake/network change causes ECONNRESET on next API call #37078 (closed as not planned), [BUG] Claude Code fails to reconnect after network change (ECONNRESET) — requires process restart #23744.

What Should Happen?

Claude Code detects the dead connection quickly and retries on a new connection.

Error Messages/Logs

No response from the API after 3m · retrying once, waiting up to 10m
A proxy or gateway that buffers streaming responses can cause this · set CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS to change the first wait

Steps to Reproduce

1. Start claude --debug and send a prompt.
2. Switch the laptop to a different Wi-Fi network.
3. Send another prompt. The response takes about 3 minutes.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Versions

2.1.284
2.1.286
2.1.287
2.1.288

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

claude_code_debug_log_redacted.txt