[BUG] Bedrock 503 mid-session permanently stops autonomous sessions — no visible backoff/retry, no recovery; 3 concurrent sessions all halted during same outage

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet — #67080 is Bedrock-503-on-resume (attachment size), #60577 / #41911 are Anthropic-API 529s (both closed stale)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.201)

What's Wrong?

When Amazon Bedrock returns a transient 503 (or the stream stalls) mid-session, Claude Code appends a terminal error message as an assistant turn and permanently stops — the session sits idle until a human types a new prompt. There is no visible backoff/retry, no periodic re-probe of the provider, and no automatic resumption when Bedrock recovers.

We run multiple long-lived autonomous sessions (agent fleets doing multi-hour engineering work). During a Bedrock outage window on 2026-07-05, three concurrent sessions in three different projects all halted simultaneously and stayed dead for ~6–9 hours until a human noticed and manually prompted each one to continue.

Observed timeline (all timestamps UTC, from session JSONL transcripts)

Session A — project switchboard-blue, session 6252e990:

07:19:36.288  last successful tool_result returned
07:22:39.881  assistant: "API Error: 503 Bedrock is unable to process your request.
              This is a server-side issue, usually temporary — try again in a moment.
              If it persists, check your Amazon Bedrock service status."
07:22:39.886  system: turn_duration          <- turn ends, session idles
15:58:52.263  user manually resumes ("bedrock went offline")  <- 8h36m dead

Session B — project ftc-blue, session 52915948 (stopped TWICE in one day):

07:20:33.982  teammate message received (in-flight multi-agent convergence work)
07:23:43.892  assistant: "API Error: 503 Bedrock is unable to process your request. ..."
              -> idle until 15:59:40 manual resume            <- 8h36m dead
16:00:04.408  tool_result returned (work resumed ~4 min earlier)
16:03:08.350  assistant: "API Error: 503 Bedrock is unable to process your request. ..."
              -> idle until 16:08:55 second manual resume     <- dead again immediately

Session C — project akey, session 904760aa:

09:42:13.997  assistant mid-task text (test rewrite in progress)
10:00:01.212  assistant: "API Error: Response stalled mid-stream. The response above
              may be incomplete."
              -> idle until 15:59:01 manual resume            <- 5h59m dead

Timing detail worth noting

In all three 503 instances the terminal error lands ~3 minutes after the last successful event (07:19:36→07:22:39, 07:20:33→07:23:43, 16:00:04→16:03:08). This suggests SDK-level retries may run for ~3 minutes and then give up terminally — after which the session makes no further recovery attempt, ever. Nothing in the transcript indicates any retry occurred (no "retrying in Ns" events), so from the operator's perspective it is a single hard stop.

Expected Behavior

Transient 5xx from the provider should be treated as retryable with a much longer horizon, especially for autonomous/headless workflows:

1. Exponential backoff with jitter, capped but long-horizon (provider outages last minutes-to-hours, not seconds) — or at least a configurable retry budget (e.g. CLAUDE_CODE_API_RETRY_BUDGET_MS).
2. Visible retry state in the transcript/UI ("Bedrock unavailable, retrying in 60s (attempt 4)…") instead of a terminal assistant-text error.
3. When retries are exhausted, the session should remain in a resumable "waiting for provider" state that periodically re-probes, rather than idling permanently as if the turn completed normally.
4. For fleets: a provider outage currently produces a correlated, silent, total stop of every session — the failure mode compounds with scale.

Actual Behavior

A single 503 (after ≤ ~3 min of whatever internal retrying occurs) becomes a terminal assistant message; the turn ends (turn_duration fires); the session idles indefinitely. In-flight multi-agent work (teammate sessions, dispatched subagents) is stranded. Human intervention is required per-session to resume.

Environment

| | |
|---|---|
| Claude Code | 2.1.201 (CLAUDE_CODE_ENTRYPOINT=cli) |
| OS | macOS 26.3 (25D125), arm64 |
| Provider | Amazon Bedrock (CLAUDE_CODE_USE_BEDROCK=1) |
| Auth | Bedrock API key (AWS_BEARER_TOKEN_BEDROCK, redacted) |
| Region | us-east-1 |
| Models | us.anthropic.claude-opus-4-7 (primary), us.anthropic.claude-sonnet-4-6, us.anthropic.claude-haiku-4-5-20251001-v1:0 |
| Mode | long-lived interactive sessions driving autonomous engineering work (auto mode, agent teams enabled) |

Notes

• The "Response stalled mid-stream" variant (Session C) is presumably the same outage surfacing before the HTTP 503 — same terminal-stop behavior, so likely the same code path should cover it.
• Happy to provide sanitized JSONL excerpts for any of the three sessions on request.