Claude Desktop: 5h46 of cumulative waiting in one day — 23 silent ~15-minute stalls across 6 sessions

## Summary

Claude Code has a systemic failure class that is currently reported as at least five separate issues: when an API connection dies silently (no FIN/RST), nothing detects it. The user sees only a spinner, for 3 to 15 minutes, with no error, no retry, and no indication that anything is wrong — while an immediate manual interrupt-and-retry would succeed in seconds. This issue consolidates the scattered reports, adds new evidence (including that the desktop app overrides the only user-side mitigation), and argues that the UX impact is far larger than the fragmented issue list suggests.

## The failure mechanism

All of the following have been independently reported and are facets of one defect — dead connections are never proactively detected:

- Before response headers: no byte watchdog is armed; the only backstop is `API_TIMEOUT_MS` (600s default). A stall here is a silent 10-minute hang (#83238).
- Mid-stream: the byte watchdog exists but stalls still hang until the same backstop; sessions can hang indefinitely with no read timeout (#25979).
- `CLAUDE_SLOW_FIRST_BYTE_MS` (30s) only logs and emits telemetry; it does not abort, retry, or inform the user (#83238).
- Long requests amplify exposure (#39906); desktop-app sessions hang with an infinite spinner (#54297).

## New evidence

Measured on macOS, desktop app, Claude Code 2.1.234, one working session over two days:

1. Transcript timestamps show turn stalls of exactly 900s, 939s and 753s, each ending in `api_error Request timed out`, each followed by a retry that succeeded in seconds. Headers had arrived (mid-stream case).
2. **The desktop app injects `API_TIMEOUT_MS=900000` into the CLI's environment at spawn**, visible via `ps eww` on the process chain (Claude.app -> disclaimer helper -> claude CLI; the variable is absent from the app's own environment and from all shell profiles, launchd, and settings files). Because process env takes precedence over the settings.json `env` block, the documented workaround (`API_TIMEOUT_MS=90000`, #83238, #5615) silently does nothing on the desktop app: we measured 900s walls with settings.json set to 90000. Desktop users cannot protect themselves. Precedent for the desktop app overriding configured timeouts: #43791.

## Why the UX impact is larger than the issue list suggests — and why it stays underreported

- **The symptom is camouflaged as normal behavior.** A silent spinner is indistinguishable from "the model is thinking", and users have been trained to accept multi-minute reasoning turns. Victims misattribute the stall to model slowness, their network, or API load — the product silently absorbs the blame.
- **The folk workaround suppresses reports.** Users get impatient, press Escape, retry, and it works in seconds. Nobody files an issue for "I pressed Escape and it worked". The failure pattern removes its own evidence before it can be reported.
- **The most-affected cohort is the least equipped to report.** CLI power users can set settings.json and stop suffering; desktop users — who cannot even apply the workaround (see above) — are the least likely to dump process environments and file issues.
- **Fragmentation prevents prioritization.** Five medium issues (#83238, #25979, #54297, #39906, #43791) never accumulate the reactions that one consolidated issue would.
- **Anthropic likely already has the data.** `CLAUDE_SLOW_FIRST_BYTE_MS` emits telemetry on these stalls. The aggregate frequency across the user base is measurable internally today.

Cost per event is 10-15 minutes of a paying user's time staring at a spinner, plus broken flow and eroded trust ("Claude is slow today"). In agentic and autonomous-loop usage, stalls multiply per session. Even a low per-session probability, multiplied across the user base, adds up to a substantial, unmeasured waste.

## Proposed fixes (consolidated from the linked issues)

1. Arm a first-byte watchdog before headers; make `CLAUDE_SLOW_FIRST_BYTE_MS` actionable (abort + retry) instead of log-only.
2. Retire pooled connections that have delivered zero bytes for N seconds, reusing the existing stale-connection retry logic.
3. Surface a UI affordance after ~30-60s of zero bytes: "this request looks stalled — retrying" (automatic) or at least a visible diagnostic instead of an indefinite spinner.
4. Desktop app: stop injecting `API_TIMEOUT_MS=900000` over user configuration, or make settings.json take precedence, and document the precedence rules.

## Related issues

#83238 (stalls before headers, workaround), #25979 (indefinite mid-stream hang), #54297 (desktop infinite spinner), #39906 (long requests), #43791 (desktop overrides configured MCP timeouts), #5615 (timeout configuration guide, contradicted on desktop by the evidence above).

Start with the settings.json env block and the desktop app's CLI spawn environment; use ps eww to verify how API_TIMEOUT_MS is injected and which configuration takes precedence. Trace the timeout and stalled-connection behavior described in the linked issues. Done means silent stalls are detected and surfaced or retried, and desktop configuration no longer silently overrides the documented timeout workaround.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.