[Bug] Transient API 529 "Overloaded" halts an autonomous /goal run permanently — no self-resume, requires manual "continue"

Preflight Checklist

• [x] I have searched existing issues and this specific aspect (autonomous-loop halt with no self-resume) hasn't been reported.
• [x] This is a single bug report.
• [ ] ~~I am using the latest version of Claude Code.~~ — Run was on 2.1.183; checked 2.1.185 (latest) changelog and confirmed it only changes a stream-stall hint, not 529 handling or autonomous resume.

What's Wrong?

When an autonomous /goal run (with teammate/subagent coordination) hits a transient API Error: 529 Overloaded, the turn ends immediately and the goal loop does not resume. It sits idle indefinitely until a human types another prompt (e.g. continue).

For an interactive session this is annoying. For an autonomous system, it's critical: the entire point of /goal is unattended progress, and a single transient server-side error silently parks the run for hours with an active, unfinished goal.

In my case the run sat dead for ~4 hours (00:35 → 04:43 UTC) on an active goal, and only resumed because I manually typed continue. It never self-recovered.

This is distinct from the existing reports, which all cover interactive sessions dying or subagents dying — none frame the autonomous /goal loop halting and never re-prompting itself, which is the severe case. Related (but not duplicates):

• #35801 — "Auto-retry on 529 in interactive mode" (closed by stale-bot, never fixed)
• #68502 — 529 hard-fails parallel subagents, no backoff (open, no maintainer reply)
• #37077 — root-cause decompile: maxRetries: 0 + partial custom retry (closed by stale-bot)

What Should Happen?

A transient 529 should not terminate an autonomous run. After retry/backoff is exhausted, the /goal loop should automatically resume (re-issue the turn after a backoff) rather than waiting for human input — or, at minimum, there should be a setting/env var to enable auto-continue-on-transient-error for autonomous modes.

Actual Behavior

• 529 surfaced as a terminal turn-ending message (in the transcript: a model: <synthetic> assistant entry with apiErrorStatus: 529, stop_reason: "stop_sequence").
• The goal loop did not re-prompt itself; the session went idle.
• Resumed only after a human manually typed continue ~4 hours later, after which it picked the goal back up normally.

Steps to Reproduce

1. Start an autonomous /goal run (bonus: with parallel teammate/subagent coordination).
2. Have it run during a period of Anthropic server overload (or otherwise trigger a 529).
3. Observe: the turn ends on the 529 and the goal loop does not resume on its own.

Error Message

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.

Transcript Evidence (timestamps UTC)

00:35:12  assistant  model=<synthetic>  apiErrorStatus=529  stop_reason=stop_sequence   ← turn ends
   …      (no activity — goal loop does not resume)
04:43:42  user       promptSource=typed  origin=human  "...529 Overloaded... continue"  ← manual re-prompt
04:44:18  assistant  (goal resumes normally)

~4h of dead time on an active goal, broken only by a manual continue.

Environment

• Claude Code version: 2.1.183 (latest at run start; 2.1.185 released mid-run — the in-flight /goal session could not adopt it without a restart)
• Platform: Windows 11
• Model: claude-opus-4-8
• Mode: autonomous /goal with teammate/subagent coordination

Additional Information

No settings.json key or env var currently exists to configure API-error retry/recovery for autonomous modes (confirmed in #35801). --fallback-model only applies to non-interactive -p mode and doesn't cover an interactive /goal session. The prior recovery requests (#35801, #37077) were both closed by the inactivity bot without a fix.

Note on version: the run was on 2.1.183; 2.1.185 (current latest) was checked and does not address this. Its only API-related change is a stream-stall hint — "now reads 'Waiting for API response · will retry in …' instead of 'No response from API · Retrying in …', and triggers after 20s of silence instead of 10s." That covers stream stalls (no bytes arriving), a different path from a returned 529 overloaded_error, and does nothing for autonomous-loop self-resume after a transient API error. The underlying maxRetries: 0 + manual-re-prompt design (#37077, #35801) is unchanged.