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

Status Fixed / completed
Reported on v2.1.288
Maintainer reply None cached
Activity 7 comments · opened Sep 29, 2026 · closed 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?

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

  • #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

  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

View original on GitHub ↗

4 Comments

daniel-x · 15 days ago

<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" />

daniel-x · 15 days ago

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" />

daniel-x · 14 days ago

in claude code version 2.1.286 this bug is still open. i've verified it using claude --debug and 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

daniel-x · 14 days ago

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 prints BUG PRESENT (exit 1), BUG NOT OBSERVED (exit 0), or TEST INVALID (exit 2) if the setup did not exercise the bug. The first run builds the image cc-repro:2.1.286 and keeps it for later runs; docker rmi cc-repro:2.1.286 removes it. CC_VERSION=<version> tests another version. Claude's debug log is saved to repro_debug.txt.

Output of a run:

23:30:15 starting container on network cc-net-a
23:30:15 sending prompt 1: Reply with one.
23:30:19 answer to prompt 1 received
23:30:19 open HTTPS connections: 23; switching the container to network cc-net-b
23:30:19 sending prompt 2: Reply with two.
23:30:50 still waiting for the answer to prompt 2 (30 s)
23:31:21 still waiting for the answer to prompt 2 (60 s)
23:31:51 still waiting for the answer to prompt 2 (90 s)
23:32:20 still waiting for the answer to prompt 2 (120 s)
23:32:50 still waiting for the answer to prompt 2 (150 s)
23:33:20 still waiting for the answer to prompt 2 (180 s)
23:33:25 answer to prompt 2 received
23:33:25 debug log saved to repro_debug.txt, relevant lines:
2026-09-30T23:30:16.879Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=f7e8e25f-def6-44c8-892f-2ea52216c2c5 source=sdk
2026-09-30T23:30:18.419Z [DEBUG] [API:timing] first byte after 1548ms
2026-09-30T23:30:20.088Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=a6978eeb-7835-4f52-89dd-90184bbfd603 source=sdk
2026-09-30T23:30:50.086Z [WARN] Slow first byte: no stream chunk 30.0s after request sent (attempt 1)
2026-09-30T23:33:22.089Z [ERROR] [first-byte] no response headers 182s after dispatch — aborting request
2026-09-30T23:33:22.092Z [ERROR] API error (attempt 1/11): undefined Connection error.
2026-09-30T23:33:22.109Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=9e594087-7945-4eb0-b82a-d539b7863ea9 source=sdk
2026-09-30T23:33:25.369Z [DEBUG] [API:timing] first byte after 3266ms
BUG PRESENT

<details>
<summary>repro_bug_98184.sh</summary>

#!/usr/bin/env bash
# Reproduces anthropics/claude-code#98184 without Wi-Fi: sends a prompt, moves the container to
# another Docker network, which changes its IP address, then sends a second prompt from the same
# Claude Code process. Logs in with the host user's Claude Code credentials (~/.claude/.credentials.json).
# Prints BUG PRESENT (exit 1) if the second request waited on a dead pooled connection,
# TEST INVALID (exit 2) if the setup did not exercise the bug, else BUG NOT OBSERVED (exit 0).
# Builds the image cc-repro:<version> on the first run and keeps it; remove_repro_image.sh deletes it.
# Always saves Claude's debug log to repro_debug.txt and its output to repro_out.txt.
set -euo pipefail

CREDENTIALS="${HOME}/.claude/.credentials.json"
[ -f "$CREDENTIALS" ] || { echo "missing $CREDENTIALS, log in with claude first"; exit 2; }

C=cc-repro
IMG=cc-repro:${CC_VERSION:-2.1.286}
cleanup() { docker rm -f $C >/dev/null 2>&1; docker network rm cc-net-a cc-net-b >/dev/null 2>&1 || true; }
save_logs() {
    docker exec $C sh -c 'cat ~/.claude/debug/*.txt' > repro_debug.txt 2>/dev/null || true
    docker exec $C cat /out > repro_out.txt 2>/dev/null || true
}
log() { echo "$(date -u +%T) $*"; }
cleanup
trap 'save_logs; cleanup' EXIT

if ! docker image inspect $IMG >/dev/null 2>&1; then
    log "building image $IMG"
    docker build -t $IMG - <<EOF
FROM debian:12
RUN apt-get update -qq && apt-get install -y -qq curl >/dev/null \
    && curl -fsSL https://claude.ai/install.sh | bash -s ${IMG#cc-repro:}
EOF
fi

log "starting container on network cc-net-a"
docker network create cc-net-a >/dev/null
docker network create cc-net-b >/dev/null
docker run -d --name $C --network cc-net-a -v "$CREDENTIALS:/root/.claude/.credentials.json" \
    $IMG sleep infinity >/dev/null
docker exec -d $C bash -c "mkfifo /in && (sleep infinity > /in &) && ~/.local/bin/claude -p --debug \
    --input-format stream-json --output-format stream-json --verbose < /in > /out 2>&1; touch /done"

prompt() {
    log "sending prompt $2: $1"
    if ! docker exec $C timeout 10 sh -c "echo '{\"type\":\"user\",\"message\":{\"role\":\"user\",\"content\":\"$1\"}}' > /in"; then
        echo "TEST INVALID: claude does not read its input"; exit 2
    fi
    local start=$SECONDS next_note=30
    while [ $((SECONDS - start)) -lt "$3" ]; do
        if [ "$(docker exec $C grep -c '"type":"result"' /out)" -ge "$2" ]; then
            log "answer to prompt $2 received"; return
        fi
        if [ $((SECONDS - start)) -ge $next_note ]; then
            log "still waiting for the answer to prompt $2 ($next_note s)"; next_note=$((next_note + 30))
        fi
        docker exec $C test -e /done && break
        sleep 1
    done
    echo "TEST INVALID: no answer to prompt $2 within $3 s"; exit 2
}

until docker exec $C test -p /in; do sleep 1; done
prompt "Reply with one." 1 30
open_https=$(docker exec $C sh -c "cat /proc/net/tcp /proc/net/tcp6 | grep -c ':01BB 01 '" || true)
log "open HTTPS connections: $open_https; switching the container to network cc-net-b"
docker network disconnect cc-net-a $C
docker network connect cc-net-b $C
prompt "Reply with two." 2 400

save_logs
log "debug log saved to repro_debug.txt, relevant lines:"
grep -E "API REQUEST|first byte|no response headers|Connection error" repro_debug.txt || true
if grep -q "Slow first byte" repro_debug.txt; then echo "BUG PRESENT"; exit 1; fi
if [ "$open_https" -eq 0 ] || [ "$(grep -c '\[API REQUEST\]' repro_debug.txt)" -lt 2 ]; then
    echo "TEST INVALID: no open HTTPS connection before the switch, or no request after it"; exit 2
fi
echo "BUG NOT OBSERVED"

</details>

Showing cached comments. Read the full discussion on GitHub ↗