Model/API calls can stall indefinitely; API_TIMEOUT_MS (600s default) never fires - two occurrences in one session

Model/API calls can stall indefinitely; API_TIMEOUT_MS (600s default) never fires — two occurrences in one session

Environment: Claude Code on Windows 11 (native, no WSL), permissions.defaultMode: bypassPermissions, model claude-fable-5[1m], autoUpdatesChannel latest.

Summary. Two independent stall events in one evening, same signature: a pending call never resolves, no error, no retry event, no timeout — the session (or subagent) is wedged until manually interrupted or killed. The documented API_TIMEOUT_MS default of 600 s did not fire in either case (stalls ran 8x and 13x past it).

Occurrence 1 — WebFetch, main session, 80.3 minutes

• WebFetch to https://www.golflink.com/golf-courses/ia/charles-city/ issued at 2026-09-01T04:55:23.259Z (transcript line timestamps).
• Next transcript event of any kind: 06:15:40.891Z — the user's manual interrupt. No tool_result, no api_error, no retry entry in between.
• The target site is exonerated by measurement: from the same machine, bare curl walks DNS + TLS + 2 redirects + 83 KB to HTTP 200 in 0.26 s, with any User-Agent.
• A WebFetch to a different URL issued 1 s earlier in the same parallel block returned in 0.65 s — but it short-circuited at cross-host redirect detection, i.e. never exercised the post-fetch model-extraction stage.
• Monitor (background task) events generated during the window queued and were only delivered at the interrupt — the pending call blocked notification delivery too.

Occurrence 2 — subagent main loop, frozen >2h15m until killed

• A general-purpose subagent (web research task, ~205 WebFetch calls, all resolving normally) received its last two tool results at 04:05:17Z — both successful, sub-second fetches.
• Its transcript then simply stops: no next assistant message, frozen mid-turn between tool results and the next model response. It was still wedged 2 h 17 m later when we killed it via TaskStop.
• Note the two occurrences are ~50 minutes apart on the same machine; the network and machine were demonstrably healthy throughout (other sessions, background monitors, and curl all fine).

Expected

Any internal API/model request — the main agent loop, a subagent loop, or WebFetch's extraction stage — should be bounded by a wall-clock timeout (API_TIMEOUT_MS or equivalent) and surface an error/retry instead of hanging forever.

Asks

1. Enforce API_TIMEOUT_MS (or a first-byte/stream timeout) on WebFetch's extraction stage and subagent loop requests.
2. Emit a transcript event when a request has been pending past a threshold, so post-hoc diagnosis doesn't require inference by elimination.

Transcript excerpts with exact timestamps available on request.