### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? After the switching the machine to a different network, the next prompt gets no response for about 3 minutes. The network itself works: other programs and

Seeing the same signature on a **static network** (no Wi-Fi change, no VPN, no proxy), so the trigger seems broader than a network switch. **Environment** - Claude Code 2.1.289 (native install) - Linux, HPC cluster compute node, direct connection to api.anthropic.com (`/status` shows no proxy) - Started for me about two days ago; affects both the main session and subagents **What happens** With default settings, requests would hang for minutes and sometimes the turn ended with: ``` API Error:

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

Status Open

Reported on v2.1.293

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 11 comments · opened Oct 4, 2026

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?

After the switching the machine to a different 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 180 s for response headers and then times out, and then immediately succeeds on the next try within 3s.

During the 180s timeout wait, the claude code interface shows only the normal spinner. After the timeout, this error message is displayed for about 1s to a few seconds until the next 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

There is no proxy or gateway in between. The connection is direct and was only switched from one subnet to another, with virtually no network outage (less than 0.1s).

With CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=30000, the same test waits 30s instead of 180s and then succeeds almost immediately on the retry, so the variable shortens the wait but does not avoid it.

The bug description says Linux, but very likely the bug also exists in Claude Code for MacOS or Windows.

What Should Happen?

When the local network changed, close all existing connections. To detect a local network change, before each request, compare os.networkInterfaces() with the value saved at the previous request. If they differ, close all connections so the request opens a new connection. This solves the problem at virtually no cost, because the function call costs only about 3µs. Re-establishing the connection after a network change is required anyway, so doing it right away instead of waiting for a timeout is no extra cost.

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

The bug can be reproduced manually or with the attached bash script. Here are the steps for reproducing it manually:

start claude code
issue prompt "hi"
wait for the reponse
change the local network
issue prompt "answer with one word: reply"
the bug is verified to exist if claude code takes 10s or more to show the response to the second prompt. If the response is shown within less than 10 seconds, then the bug is not present.

Here is the bash script for starting a local docker container and switching its simulated network in-flight for automatically testing if the bug still exists in the latest version of claude code:
repro_bug_180s_timeout_after_network_switch.sh

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.293

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

3 Comments

HuangLMU · 9 days ago

Seeing the same signature on a static network (no Wi-Fi change, no VPN, no proxy), so the trigger seems broader than a network switch.

Environment

Claude Code 2.1.289 (native install)
Linux, HPC cluster compute node, direct connection to api.anthropic.com (/status shows no proxy)
Started for me about two days ago; affects both the main session and subagents

What happens
With default settings, requests would hang for minutes and sometimes the turn ended with:

API Error: No response from API (waited 5m, then 10m on the retry)

After setting CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=60000, I reproduced it in a fresh, small-context session with --debug. It hit 4 times in ~15 minutes, including immediately after a 5 s Bash call and an 18 ms Read, so it isn't tied to long idle periods:

13:59:31.830Z [WARN] [dispatch] connection error with anthropic-dispatch-id=v2d; retrying once with anthropic-dispatch-id=v2p
13:59:31.830Z [DEBUG] Stale connection — disabling keep-alive for retry
14:00:40.015Z [ERROR] [first-byte] no response headers 65s after dispatch — aborting request
14:00:40.016Z [WARN] [dispatch] connection error with anthropic-dispatch-id=v2d; retrying once with anthropic-dispatch-id=v2p
14:00:43.759Z [INFO] [Stall] tool_dispatch_start tool=Bash ...
14:00:49.224Z [INFO] [Stall] tool_dispatch_end tool=Bash ... outcome=ok durationMs=5465
14:01:54.273Z [ERROR] [first-byte] no response headers 65s after dispatch — aborting request
14:01:54.274Z [WARN] [dispatch] connection error with anthropic-dispatch-id=v2d; retrying once with anthropic-dispatch-id=v2p
14:07:51.177Z [INFO] [Stall] tool_dispatch_start tool=Read ...
14:07:51.195Z [INFO] [Stall] tool_dispatch_end tool=Read ... outcome=ok durationMs=18
14:08:56.219Z [ERROR] [first-byte] no response headers 65s after dispatch — aborting request
14:08:56.220Z [WARN] [dispatch] connection error with anthropic-dispatch-id=v2d; retrying once with anthropic-dispatch-id=v2p
14:14:50.107Z [ERROR] [first-byte] no response headers 65s after dispatch — aborting request
14:14:50.109Z [WARN] [dispatch] connection error with anthropic-dispatch-id=v2d; retrying once with anthropic-dispatch-id=v2p

The pattern is always the same: the v2d attempt gets no response headers, and the v2p retry (keep-alive disabled) goes through within seconds. For example, the next tool call starts ~4 s after the abort at 14:00:40.

Network check
From the same node, I held a plain keep-alive HTTPS connection to api.anthropic.com open and reused it after an idle period:

After 60 s and 240 s idle: reused fine.
After 420 s and 600 s idle: the server had closed it cleanly (FIN / RemoteDisconnected), not a silent drop.

So the network path doesn't seem to black-hole idle connections. This looks like the client sending on a connection it shouldn't be reusing.

Workaround
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=20000 in ~/.claude/settings.json turns each hang into a ~20–25 s delay instead of a multi-minute stall. In the earlier default-settings sessions, though, the retry also went unanswered (the 5m + 10m error above). I don't have a debug log for one of those yet and will add it if it recurs.

daniel-x · 7 days ago

@HuangLMU Interesting findings. You mentioned that this problem started for you about 2 days before your report, so I figure the first time was around Oct. 3rd.; Do you think it might be a regression bug? Was there any version that you used where you didn't notice this bug?

The earliest version that I tested is Claude Code 2.1.284, where I noticed this bug for the first time on 2026-09-29. For me, the bug is present in versions 2.1.284, 2.1.286, 2.1.287, 2.1.288, 2.1.289, 2.1.292, 2.1.293. (I haven't tested the versions in between. Most likely the bug is there as well). I did not test any versions before 2.1.284.