Claude Code — ~60s "Request timed out" regression in 2.1.183-2.1.185 (client-side; network_down=false, rate_limited=false)

Summary

Starting with Claude Code 2.1.183, long / heavy Opus turns fail with Request timed out at a flat ~60–95s per-attempt ceiling, then death-spiral through retries (1 → 10/10) and the session dies producing zero output. Builds ≤ 2.1.178 show 0% of this; 2.1.183 and 2.1.185 show ~96–97%. It is not network and not rate limiting (network_down=false, rate_limited=false on every affected event). API_TIMEOUT_MS=600000 does not help.

Filed by an enterprise user running heavy parallel sub-agent workloads.

Environment

• Claude Code via VS Code extension (entrypoint claude-vscode), native installer
• macOS 26.5.1 (Darwin 25.5.0), Apple Silicon
• Model: claude-opus-4-8
• Single native install (~/.local/bin/claude); no npm-global / Homebrew / bundled copy (no install conflict)
• autoUpdates: false — version is operator-pinned, not auto-bumped
• Observation window: 2026-05-29 → 2026-06-22 (UTC); failures concentrated 2026-06-20 / 06-21

Symptom

API Error: Request timed out repeated at a flat ~60s+ gap until the retry cap (10/10), after which the session terminates with no assistant output. Worst on the heaviest, highest-value Opus turns.

Evidence (local ledger over all session transcripts)

• 1,446 api_error events; 662 (46%) were "Request timed out"; 0 rate-limited.
• 24 sessions hit the 10/10 retry cap and died. On 2.1.183 / 2.1.185 deaths: median retry gap ~60–96s, network_down=false on every one.
• Of all timeout events on 2.1.183 / 2.1.185: 502 / 502 had network_down=false AND rate_limited=false.

Timeout share by client version

| Claude Code version | "Request timed out" share | network_down |
|---|---|---|
| ≤ 2.1.178 (May – Jun 17) | 0% | — |
| 2.1.179 (Jun 17–20) | 25% | 25% |
| 2.1.183 (Jun 20–21) | 97% (435 / 447) | 0% |
| 2.1.185 (Jun 21) | 96% (67 / 70) | 0% |

Decisive controlled test — same day (2026-06-20), same machine, same (large) context, same workload, split only by client version:

• 2.1.179 → 0 timeouts / 10 requests (0%)
• 2.1.183 → 401 timeouts / 413 requests (97%)

Same context, opposite outcome ⇒ context size is not the driver — the client version is. 2.1.185 did not fix it.

Sample dead sessions (UTC)

| last event | session | retries | median retry gap | network_down | version |
|---|---|---|---|---|---|
| 2026-06-21T17:07:03Z | a1e45a09 | 10/10 | 69.3s | no | 2.1.185 |
| 2026-06-21T13:10:12Z | e4588426 | 10/10 | 77.8s | no | 2.1.185 |
| 2026-06-20T20:26:00Z | aab7fd02 | 10/10 | 77.7s | no | 2.1.183 |
| 2026-06-20T18:35:21Z | 7ed88c80 | 10/10 | 68.2s | no | 2.1.183 |

Note on request IDs: the client appears to abandon the request at ~60s before the server responds, so these timeouts produce no server request-id — itself consistent with a client-side regression.

What we tried

• API_TIMEOUT_MS=600000 — ineffective (set and live in-process; the ~60s ceiling persisted).
• Downgrade to 2.1.142 — stops the timeouts, but it's a ~6-week-old build.

Impact

Dozens of lost autonomous worker dispatches across 2026-06-20 / 06-21; zero-output failures concentrated on the largest, highest-value Opus turns.

Ask

Please confirm the ~60s client-side request-timeout regression in 2.1.183–2.1.185 and ship a fixed build > 2.1.185, so heavy Opus workloads can stay current without the timeout failures.

A full ledger (LEDGER.md) and per-event data (events.jsonl, version / network_down / rate_limited / retry attempt / timestamps) are available on request.