[Bug] advisor server-tool 'overloaded' kills workflow-spawned subagents with a generic 'Connection closed mid-response' instead of a recoverable tool error (main loop degrades correctly)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When the advisor server tool returns a transient error (error_code: "overloaded"), workflow-spawned subagents die mid-response and contribute zero output to the run. The main conversation loop, receiving the same outage in the same session, degrades correctly and continues.

The subagent's terminal record is a generic transport error that names neither the advisor nor the overload:

API Error: Connection closed mid-response. The response above may be incomplete.

Two things make this worth separating from the many generic "Connection closed mid-response" reports:

1. The correlation is with a server-tool error result, not with load in general. In the run below, every agent that touched advisor during the outage window died; all 16 that completed did so without a trailing advisor error.
2. The main loop and the spawned-agent loop diverge on identical input. In the same session, a direct advisor call in the main loop returned a clean, actionable, non-fatal message — The advisor is temporarily overloaded. Do not try to use it again this turn. — and the loop continued. The spawned agents got a connection teardown instead.

A second occurrence (same day, during the resumeFromRunId recovery of the very same run) additionally rules out agent-side mishandling as the cause: two of the three agents killed had already observed the outage and explicitly reasoned past it, and were killed anyway. See "Second occurrence" below — this is the part that most constrains the fix.

What Should Happen?

A transient server-tool failure should surface to a spawned agent as a recoverable tool error it can observe and route around — the same way a failed Bash call or a 404 from a CLI does, and the same way the main loop already handles this exact error. An overloaded advisor should cost an agent one paragraph of reasoning, not its entire contribution.

Ideally, in priority order:

1. Retry overloaded with backoff before surfacing it at all, since it is explicitly transient.
2. Hand the agent the error text and let it continue, rather than closing the response stream.
3. Failing both, do not convert a named dependency error into an unnamed transport death — the observed message identifies neither the advisor nor the overload, which is why diagnosing this required diffing transcript tails across six agents.

Error Messages/Logs

First occurrence — 6 of 22 agents errored, all with the identical terminal record. Two of the three failed agents show the advisor error as the last content block before death:

// agent-a7a2d5f96bd9d578d  (died 09:15:29.879Z)
{"type":"advisor_tool_result","tool_use_id":"srvtoolu_01WCyAqcZtA8xHt5XqVqjKtK",
 "content":{"type":"advisor_tool_result_error","error_code":"overloaded"}}

// agent-a946dfa20bbb8b7d5  (died 09:11:34.246Z)
{"type":"advisor_tool_result","tool_use_id":"srvtoolu_01BKV2bGHbe3drXmtfep7FBS",
 "content":{"type":"advisor_tool_result_error","error_code":"overloaded"}}

The third (agent-a79a8e506074fefce, died 09:11:34.260Z) shows a server_tool_use naming the advisor immediately prior. Those latter two terminated 14 ms apart, consistent with one shared upstream event rather than three independent failures.

Second occurrence — three more agents, terminating within 16 ms of each other:

agent-ae422674523728718  10:05:50.493Z
agent-a0632dd6acccb610a  10:05:50.500Z
agent-a971d119486c87728  10:05:50.484Z

On two of them, the record immediately before death is the agent handling the outage correctly and preparing to continue:

// a0632dd6acccb610a, ts=10:05:36.920Z
"Advisor is rate-limited; my verdict rests on decisive empirical evidence. Recording it now."

// a971d119486c87728, ts=10:05:40.380Z
"Advisor is rate-limited; proceeding on the evidence I gathered."

Both were then killed ~10–14 s later by the same generic transport error. This is why "let the agent handle the error" is necessary but not sufficient — these agents did exactly that. Whatever closes the response stream appears to sit below the agent's control.

One wording note worth preserving: the agents describe the condition as "rate-limited" while the structured result carries error_code: "overloaded". Both surface in the same outage window; neither reaches the operator in the death message.

Steps to Reproduce

This is not deterministically reproducible on demand — it requires an advisor outage window, which we cannot induce. Reporting it as an observed correlation across two independent occurrences with transcript-level records, rather than as a recipe.

Conditions under which it was observed, twice:

1. Run a multi-agent workflow that fans out ~20 subagents in parallel, each permitted to call the advisor server tool.
2. Have the fan-out overlap an advisor overload window (ours lasted minutes and affected both occurrences).
3. Observe: agents whose advisor call returns advisor_tool_result_error terminate with API Error: Connection closed mid-response, contributing no output. Agents that never called advisor complete normally. The main loop, calling advisor in the same window, receives a clean non-fatal error and continues.

A definitive trace would need the harness-side request log for the srvtoolu_* ids above; the death message on the client side is generic transport, so we report causation as a strong correlation rather than as proven.

Downstream cost

For context on why this is more than a thinner run:

• 3 fan-out angles lost outright → coverage gap on the reviewed work.
• 3 verifier agents lost → 3 findings stranded unadjudicated.
• The run then set its budget-exhausted flag and skipped its synthesis stage entirely, so the surviving findings shipped provisional and partly duplicated — i.e. a transient dependency outage rendered the output unusable, not merely smaller.
• Recovery cost a full resumeFromRunId round, which hit the same failure again (the second occurrence above).

Claude Model

Opus (workflow subagents and main loop alike).

Is this a regression?

Not sure — we have no earlier data point for this code path.

Claude Code Version

2.1.225 at the time of filing. The two occurrences were recorded on 2026-07-30 on the version installed then, which we cannot now recover; we have not re-verified since, because doing so requires another advisor outage window.

Platform

Anthropic API (1P).

Operating System

Linux.