[BUG] After a network change, the next request hangs 184 s on a dead connection before retrying (Linux)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] 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. WithCLAUDE_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
- #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.
- #83238 (open): stalls before response headers have only the 600s API_TIMEOUT_MS backstop.
- #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:
#32116 (after suspend, ~5 min, closed as not planned), #37078 (closed as not planned), #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
- Start
claude --debugand send a prompt. - Switch the laptop to a different Wi-Fi network.
- 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
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/5107a5cc-2dc6-4558-a90b-8733ecf58276" />
<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/1e33ed64-ae10-4a8b-9d46-f5e62344ba5b" />
<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/3d23f73c-6b59-423b-b866-8a03b2def226" />
in this comment there is the redacted debug log and screenshots of the workaround/mitigation that uses CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=30000.
workaround_debug_log_redacted.txt
<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/487dec43-c141-45ce-9c9a-947e5223e9bb" />
<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/2e277c2d-e3f0-48d7-a023-579ce31dcb26" />
<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/04f011ba-85e2-4d9f-a591-1fdf5939ee9f" />
in claude code version 2.1.286 this bug is still open. i've verified it using
claude --debugand the other steps of the initial report. the problem occurs exactly the same way. here is the debug log of the bug reproduction with claude code 2.1.286:claude_code_debug_log_redacted_2.1.286.txt
The bug can be reproduced without Wi-Fi, in a Docker container, so it can be checked automatically on a server. The script below runs Claude Code 2.1.286 in a Debian container, sends one prompt, then moves the container to another Docker network, which changes its IP address like a Wi-Fi switch does. Then it sends a second prompt from the same Claude Code process. That reproduces the bug. The second request goes out over a pooled connection of the old address and therefor it waits about 182 s for response headers before a timeout happens and the retry then succeeds within a few seconds.
Requirements: Docker, and a Claude Code login on the host in
~/.claude/.credentials.json. The script mounts that file into the container. Two short prompts get issued, so the caused account usage in negligible.Run it with
./repro_bug_98184.sh. It printsBUG PRESENT(exit 1),BUG NOT OBSERVED(exit 0), orTEST INVALID(exit 2) if the setup did not exercise the bug. The first run builds the imagecc-repro:2.1.286and keeps it for later runs;docker rmi cc-repro:2.1.286removes it.CC_VERSION=<version>tests another version. Claude's debug log is saved torepro_debug.txt.Output of a run:
<details>
<summary>repro_bug_98184.sh</summary>
</details>