Long session unrecoverable: writes blocked during upstream 529, then oversized tool result forces 'Prompt is too long' with no compaction escape

Environment

• Claude Code 2.1.216
• macOS (Darwin 25.5.0), zsh
• Model: Opus 4.8 (1M context)
• Long-running session: browser automation (chrome-devtools MCP) + large-PDF text extraction

Summary

Two distinct failure modes combined to make a long session unrecoverable ("corrupted"). Reporting them together because they compounded, but they are independent bugs.

---

Bug 1 — During an upstream model overload, all write/tool actions are refused while read-only calls still pass, with no in-session way to proceed

Observed behavior. During a period of upstream HTTP 529 Overloaded / 500 errors, a background Sonnet subagent died with a 529. Immediately after, every write/browser/shell tool call in the parent session was refused by the harness's tool-vetting layer, while read-only calls continued to succeed. This persisted for ~20 minutes across four retry attempts. The effect was a hard stop on already-authorized, in-progress work (filling a web form in an already-logged-in browser), with:

• no error the user could act on — writes simply would not go through,
• no documented in-session control to disable/bypass the check or degrade gracefully, and
• read-only calls succeeding throughout, which made it look like the session was "up" when it could do nothing useful.

Why it's a bug (not just an outage). Coupling the availability of the user's authorized write actions to the availability of a model tier that happens to back a harness-internal check means a transient upstream overload escalates into a total inability to make progress. A vetting layer that cannot reach its backing model should fail in a way the user can understand and, where the action was already user-authorized, choose to proceed — not silently refuse every write while pretending to be alive.

Repro (approximate). Run a session that issues write/browser tool calls during a window when upstream is returning 529s. Read-only tool calls succeed; write/browser/shell calls are refused for the duration.

Expected. Either (a) a clear, user-actionable error identifying that a harness check is unavailable due to upstream overload, with an option to proceed on already-authorized actions, or (b) the check degrades to a lighter path rather than failing closed on everything.

---

Bug 2 — A single oversized tool result is admitted to context uncapped, driving the session into an unrecoverable Prompt is too long state

Observed behavior. The session extracted text from very large PDFs (one extraction ~2.2M characters) and captured full-page screenshots. These landed in context as single tool results — one JSONL entry measured 1,059,585 characters (~1 MB); the transcript reached 5.4 MB. The session then hit Prompt is too long and repeated it on the next turn. After that the session could not continue and could not be auto-compacted (the compaction step itself has to load the oversized context). The session was effectively dead — the file is valid JSONL, but Claude Code cannot resume it.

Why it's a bug. A single tool result large enough to blow the context window is admitted whole, with no truncation, streaming-to-disk, or size guard at the point of ingestion. Once it's in the transcript, every subsequent turn — including the compaction that is supposed to rescue the situation — inherits the overflow, so the session cannot self-heal.

Repro. Extract text from a multi-hundred-page PDF (or capture several full-page screenshots) in one session so a single tool result approaches/exceeds the context budget. The session becomes unable to continue and cannot compact.

Expected. Tool results above a threshold should be capped/summarized/spilled-to-disk at ingestion (with a pointer the model can re-read on demand), and/or Prompt is too long should trigger a recovery path (drop or externalize the largest results) rather than a dead end.

---

Impact

A ~4-hour operational session doing legitimate authorized work (web-form automation + document verification) was lost with no recovery path. Bug 1 blocked progress during the outage; Bug 2 then made the session permanently unresumable. Individually each is a degradation; together they turn a transient upstream blip into total, unrecoverable work loss.

Suggested priority

Bug 2 (unrecoverable context bloat + no compaction escape) is the higher-severity of the two — it destroys work and has no user workaround.