Background subagent in a 7-way parallel fan-out: repeated zero-progress 600s stall, no named error, isolated to one large-context subagent (20% of launches over 5 weeks, Vertex AI)

Summary

One specific background subagent, launched alongside 6 siblings in a single message via the Agent tool, repeatedly shows zero tool calls and zero tokens for exactly 600,000ms, then gets aborted by (what we believe is) CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS's default stall timeout. This happens to the same conceptual slot in the batch — the largest-context subagent — at a ~20% rate over 5 weeks, while the other 6 same-shaped subagents launched in the identical batches have a 0% stall rate across 200 combined launches.

We've checked this against the official docs (env-vars.md, sub-agents.md, network-config.md) before filing, and our symptom does not match any documented failure mode we could find. Details below.

Environment

• Claude Code version: 2.1.284
• Platform: tool-use IDs in this environment are prefixed toolu_vrtx_..., consistent with running via Google Cloud Vertex AI
• Model: claude-sonnet-5
• Usage pattern: a Claude Code session dispatches 7 Agent tool calls in a single assistant message (confirmed via shared message ID across all 7 tool_use blocks in the same batch). One of the 7 is a large-context documentation-audit task (reads ~25 files, ~140K+ tokens of source content, does live web verification via curl/WebSearch) — this is consistently the one that stalls when it stalls.

Symptom, precisely

• The affected subagent shows tool_uses: 0 and subagent_tokens: 0 in the completion telemetry, for a recorded duration of exactly 600000ms.
• No error message, no partial output, no named failure reason is ever surfaced to the parent session — it reads as total silence for the full window, then the parent's own retry-once protocol treats it as stalled.
• This is not a mid-task hang — it's zero progress from the very first action, every time it happens.

Reproduction data (from our own telemetry log, collected over 5 weeks of real usage)

Across 83 launches of this specific subagent (same task shape, same repo, launched in an identical 7-way batch every time): 17 stalls (20%).

Across the same 5 weeks, the other 6 subagents launched in the exact same batches, same message, same session: 0 stalls out of 200 combined launches (0%).

Per-day incident counts: 2026-08-27 (1/2), 2026-09-01 (2/7), 2026-09-07 (1/5), 2026-09-09 (2/3), 2026-09-10 (1/5), 2026-09-11 (4/9), 2026-09-29 (6/11). Several other days in the same window show 0/N with no stalls at all — it's not universal, it's concentrated.

On 2026-09-29 specifically: 4 independent runs touched this subagent that day; 3 of the 4 had the stall occur AND the one allowed automatic retry also stall identically (a full, unrecovered double-stall) — only 1 of 4 succeeded cleanly with no stall at all. The retry does not appear to meaningfully improve the odds.

What we checked in the docs before filing (please correct us if any of this is wrong)

1. CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS (default 600000) is documented in env-vars.md: "The timer resets on each streaming progress event; if no progress arrives within the window, Claude Code aborts the subagent and reports the stall to the parent." This matches our symptom's shape exactly, so we believe this is the mechanism reporting the failure — not itself the bug.
2. network-config.md § Streaming idle watchdogs documents 4 independent, faster timers meant to catch a dead connection well before a 600s subagent-level timeout: first-byte deadline and byte-level watchdog (180-300s, but both explicitly "doesn't run on Google Cloud's Agent Platform" per the docs — consistent with our Vertex AI environment), event-level watchdog (300s, "every provider"), and body idle timeout (5 min, applies to non-direct-API/non-Bedrock providers). Given our platform, the event-level watchdog and body-idle timeout should still apply and should fire around the 300s mark — but our telemetry shows the full 600s elapsing with nothing, not an earlier retry-then-still-failing pattern.
3. sub-agents.md § API errors in subagents documents that a background subagent whose run ends on a genuine API error (rate limit, overload, server error) reports that failure back to the parent by name, with any partial output preserved: "Background: the subagent is marked failed, and the message Claude receives when it ends names the API error and includes the subagent's last output." We never see a named error — only silent zeros.
4. The documented concurrent-subagent limit (default 20, CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS) doesn't apply — we only launch 7 concurrently, and the docs say exceeding the limit fails immediately with a named error anyway, not a silent delay.

What remains unexplained

Given (2) and (3) above, we'd expect one of two outcomes if this were a documented, known failure mode: either an earlier (~300s) named error surfaces to the parent (a rate-limit/overload/server-error report), or the subagent recovers via the documented automatic retry-at-deadline behavior for a stalled response stream. We observe neither — just uniform silence for the full 600s, then the subagent-level stall-timeout closing it out with no error content at all.

We'd appreciate any guidance on:

• Whether the event-level watchdog and/or body-idle timeout are known to behave differently for background subagents specifically (vs. the foreground/main-conversation connection they're presumably designed around), which might explain why they never seem to fire here.
• Whether there's a known interaction between large request/context size (this subagent's initial dispatch prompt plus its tool definitions is among the largest in our fan-out) and connection establishment specifically on Vertex AI.
• Any client-side diagnostic we could enable (verbose logging, a debug flag) to capture what's actually happening on the wire during one of these 600-second windows, since our own telemetry currently only observes total silence with no lower-level detail.

Happy to provide our full telemetry log (JSONL, no customer data, tracks timestamp/scope/files/subagent_tokens/tool_uses/duration_ms/findings/retried per subagent launch across the whole 5-week window) if that would help reproduce or diagnose this.