Repository navigation
Preserve Claude's terminal error instead of reporting only 'claude exited 1' #587
Description
This was generated by AI during triage.
The final Spec review of JacobStephens2/chart35#239 stopped at 2026-10-08 20:13 UTC after all 17 Tickets had landed into the Spec branch. The Run notification reported only Cause: claude exited 1, hiding the provider's actionable error. The preserved Spec PR is https://github.com/JacobStephens2/chart35/pull/261.
The captured terminal result was:
{"type":"result","subtype":"success","is_error":true,"api_error_status":429,"result":"You've hit your monthly spend limit · raise it at https://claude.ai/settings/usage?from=cc_cli_limit_message · your weekly limit resets Oct 10, 2am (UTC)"}The preceding root assistant API error contains api_error: usage_limit_reached, rateLimitType: seven_day, resetsAt: 1791597600, overageStatus: rejected, and overageDisabledReason: org_level_disabled_until. The prose describes a monthly spend limit while the structured fields identify weekly usage exhaustion with extra usage rejected. Reporting must preserve these distinctions, rather than infer a monthly reset from the weekly timestamp or classify every HTTP 429 as a transient throttle.
The session log is /home/jacob/.thirdshift/logs/JacobStephens2/chart35/sessions/239-20261008T132659+0000-spec-review.jsonl, with the root API error at record 810 and the terminal result at record 813. The command log with the same run stem records claude exited 1 at line 3090.
At main commit 3a81a11ff06dd4db14407732f1f282da60072f5a, the shared stream decoder records Claude's failure flag but explicitly supplies no diagnostic on completion. Grok already retains diagnostic text. Verification here consists of the captured failing Run and inspection of the current decoder; no live account limit was deliberately exhausted.
Quota-aware routing and fallback are tracked separately in #583. This issue is the bounded diagnostic-reporting bug.
Activity
JacobStephens2 commentedon Oct 9, 2026
Agent Brief
Category: bug
Summary: Preserve Claude's terminal failure diagnostic and supplied usage-limit details in the Run's failure reporting.
Current behavior:
The Claude protocol decoder detects failed terminal results, including
subtype: successwithis_error: true, but discards diagnostic text at completion. The Harness therefore returnsclaude exited 1orclaude's turn failed; the Run's terminal output and notification cannot explain the actual provider failure. An observed Spec review hit a usage/spend limit and HTTP 429 after all its Tickets landed.Desired behavior:
A failed Claude session carries its own terminal diagnostic through Harness completion to the Run's failure cause, terminal output, and Run notification. Prefer meaningful terminal
errorsentries, then nonempty terminalresulttext, with a relevant root API error as a fallback. Retain supplied usage-limit information needed to explain the limit and its reported reset; do not invent absent information or collapse distinct weekly and monthly limits. A recovered earlier API error or a child-agent error must not by itself fail a successfully completed parent session, and successful terminal prose must never become an error diagnostic merely because the process later exits nonzero.Key interfaces:
Streamand itsDecoder::completeresult: retain diagnostic facts in addition to the failure flag.Facts,Completion, and Harness failure formatting: preserve meaningful diagnostics and supplied structured limit details through failure, without requiring callers to parse raw logs.Sessions,Cause, andAccount: the terminal and notification consume the same failure cause.Acceptance criteria:
subtype: success,is_error: true, HTTP 429 result produces a failed outcome whose cause includes the actual spend-limit message, for a nonzero process exit and for a zero exit with a failed terminal result.errorstake precedence over nonempty failed-result text; missing or malformed diagnostic fields retain a useful generic failure without panicking.Out of scope: