Subagents are terminated permanently on API 529 (Overloaded) instead of retrying, leaving half-finished edits behind

Summary

Background subagents (Agent tool) are terminated permanently when the API returns
529 Overloaded. The agent is killed mid-task, its work is lost, and any files it
already edited stay behind in the working tree in a half-finished state. A transient
server-side condition should not be a terminal error for a subagent.

The subagent prompts in my case contained an explicit instruction to wait and retry on
529 — the harness terminates the agent before the model ever gets to act on it.

Environment

• Claude Code CLI on Windows 11 Pro (26200)
• Model: Opus 5 (1M context)
• Session length: ~13h, multiple background agents via the Agent tool

What happened

Over a single long session (2026-07-29 19:38 → 2026-07-30 08:58 local), four background
agents died this way. Example notifications:

Agent "…" failed: Agent terminated early due to an API error:
API Error: 529 Overloaded. This is a server-side issue, usually temporary —
try again in a moment. If it persists, check https://status.claude.com.

The main loop hit the same 529 repeatedly in the same window, so this was a sustained
overload period rather than a one-off blip.

Concrete damage in my case: one agent had already written ~577 lines across 3 source
files before it was killed. Those edits were left in the working tree without the tests
that were part of the same task, and without any report back — so from the outside the
task looks partially done, with no indication of where it stopped. A second agent died
seconds after starting, having done nothing at all, which was equally invisible until I
went digging through the transcript.

Expected behaviour

1. Retry 529 at the harness level with backoff, the same way a transient network error

would be handled, rather than treating it as terminal.

1. If an agent must be terminated, hand back what it produced (its partial output /

which files it touched) instead of only an error string, so the parent can decide
whether to keep, revert, or resume.

1. Ideally, make the agent resumable after a transient failure.

Actual behaviour

The agent is terminated on the first 529. The parent receives only the error text. Work
in progress is silently left on disk.

Impact

On long autonomous runs this is the difference between "slow because the API is busy"
and "the run is destroyed". Partial, untested edits left in a repository are worse than
no edits, because they are easy to mistake for completed work.