Repeated multi-minute 'Waiting for API response … check your network' stalls when the network is provably fine (33ms RTT to api.anthropic.com)

Summary

Long-running sessions repeatedly stall with:

Waiting for API response · will retry in 2m 35s · check your network

This has been recurring all day and night across many sessions. The retry backoff reaches 2+ minutes, during which the session is completely blocked. It is not an isolated blip.

The message tells the user to "check your network" — the network is fine, and the message misattributes a server/client-side stall to the user's connection. That is actively misleading and sent me chasing a non-existent local problem.

Evidence the network is NOT the problem

Measured on the affected machine at the moment the banner was displayed:

$ curl -s -o /dev/null -w "HTTP %{http_code} · dns %{time_namelookup}s · connect %{time_connect}s · total %{time_total}s\n" \
    --max-time 15 https://api.anthropic.com/v1/messages

api.anthropic.com: HTTP 405 · dns 0.001651s · connect 0.010869s · total 0.033178s

HTTP 405 is the expected response to a bare GET on that endpoint — it proves the endpoint is reachable and responding. Total round trip: 33 milliseconds. DNS 1.6ms, TCP connect 10.9ms. There is no packet loss, no DNS delay, no connectivity issue of any kind.

Environment

| | |
|---|---|
| Claude Code | 2.1.220 |
| Platform | macOS 26.5.2 (25F84), arm64 |
| Node | v23.8.0 |
| Shell | zsh |

Impact

• Sessions stall for minutes at a time, repeatedly, over a full working day.
• The stall frequently lands mid-task (during tool calls / long-running work), so work is left in an indeterminate state and the user cannot tell whether anything is still progressing.
• The 2m+ backoff is very long for what may be a transient condition.
• No actionable error is surfaced. There is no visible error code, request ID, or underlying failure reason — just the generic banner.
• I could find no client-side log capturing the failure: ~/.claude/ contains no *.log with any corresponding error entry, so there is nothing for a user to inspect or attach.

What I'd like to see

1. Fix the underlying stalls / long retry waits.
2. Stop printing "check your network" unless the client has actually established the network is at fault. Suggest surfacing the real condition instead (timeout vs. 5xx vs. overload vs. rate limit), ideally with a request ID.
3. Log the failure somewhere inspectable, so users can attach real diagnostics to reports like this one instead of a screenshot of a banner.
4. Consider a shorter initial backoff with a visible, cancellable countdown.

Notes

Happy to provide further diagnostics if you can tell me where the client records the failing request (I could not locate any log file containing it).