[Bug] Concurrent subagents wedge on model token stall after tool_result with no error trace
Bug Description
Three sibling subagents in one fan-out wedged simultaneously: no model tokens
after tool_result, no isApiErrorMessage trace
Version: 2.1.216 (macOS 25.5.0)
Three subagents spawned within 25s of each other all stopped receiving model
output at the same wall-clock instant (~15:11:56 UTC). Each was on its next
model request after a tool_result and produced zero tokens:
[REDACTED] a93fcb497294db121 — last tool_result 15:11:56.301Z — 623s silence — killed by 600s stream watchdog
agent abdcddf1a20b6a790 — last tool_result 15:11:55.607Z — 623s silence — killed by 600s stream watchdog
agent a6f340c9889d64903 — assistant turn began 15:11:56.515Z — 535s silence — "API Error: Connection closed mid-response"
Concurrency at that moment: 7 live subagent contexts, 3 levels of nesting
(main -> worker -> verifier lanes). Sibling fan-outs of the same shape at
lower concurrency (n=3) completed normally in 215-225s, so this is not a
per-agent timeout.
Two things that made this hard to diagnose:
- grep for '"isApiErrorMessage":true' across every session + subagent
transcript returns 0. The watchdog-killed agents leave no error record at
all — the failure is only visible as a time gap between a tool_result
entry and the next entry. Two of the three deaths are invisible to any
error-based audit.
- A parent blocked on a child is indistinguishable from a wedged agent in
the UI. Measured on the same session: a parent showed 1107s and 1217s of
"silence" that were simply it awaiting a healthy child. With 3 nesting
levels there are always idle-looking parents, so users cannot tell a real
wedge from normal blocking and end up killing working agents.
Repro shape: an orchestrator dispatching 2 workers in parallel, each worker
nesting a 3-way verifier fan-out.
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.1.216
- Feedback ID: 57017368-046a-4094-bb08-ab15b62dd2ef
Errors
[{"error":"Error: 522 {\"type\":\"https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-522/\",\"title\":\"Error 522: Connection timed out\",\"status\":522,\"detail\":\"Cloudflare could not establish a TCP connection to the origin server. The TCP handshake timed out, which may indicate the origin is overloaded, firewalling Cloudflare, or unreachable at the network level.\",\"instance\":\"a1eb90428da0b65d\",\"error_code\":522,\"error_name\":\"connection_timeout\",\"error_category\":\"origin\",\"ray_id\":\"a1eb90428da0b65d\",\"timestamp\":\"2026-07-21T16:26:05Z\",\"zone\":\"api.anthropic.com\",\"cloudflare_error\":true,\"retryable\":true,\"retry_after\":120,\"owner_action_required\":true,\"what_you_should_do\":\"**Wait and retry.** Back off for at least 120 seconds. If the error persists, the website operator should verify firewall rules and ensure the origin accepts connections from Cloudflare IP ranges.\",\"footer\":\"This error was generated by Cloudflare on behalf of the website owner.\"}\n at generate (/$bunfs/root/src/entrypoints/cli.js:40:49240)\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:80:7690)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-07-21T16:26:05.938Z"}]