Fix the codex-harness circuit-breaker false-positive — it kills runs that already finished successfully, burning ~19 minutes and ~1.5M tokens each time.
Problem statement
Codex-engine workflows are being SIGTERM'd by the codex-harness "context-rebuild circuit breaker" after they've already emitted a terminal safe-output. The guard fires once rebuild_factor crosses 25 and cumulative_input_tokens crosses 1,000,000, then forces exit code 1 and a synthetic report_incomplete — even when the task logically completed.
Affected workflows and run IDs
Sub-Issue Closer — §32937867689 — rebuild_factor=25.06 cumulative_input_tokens=1,195,375Metrics Collector — §32924199594 — rebuild_factor=26.23 cumulative_input_tokens=1,537,802. This run had already called safeoutputs noop ("Metrics collection complete: 117 workflows analyzed...") ~6 seconds before the guard fired — proof the task was already done when the breaker killed it.
Probable root cause
The circuit breaker (pollIntervalMs=15000) evaluates independently of task-completion signals. It doesn't check outputs.jsonl for a terminal safe-output entry before deciding to SIGTERM, so a Codex process that finished its work but is slow to exit gets treated identically to a genuinely runaway one.
Proposed remediation
- Before firing, check
outputs.jsonl for a terminal entry (noop/create_issue/report_incomplete/etc.); if one exists, let the process exit normally instead of forcing report_incomplete.
- Alternatively, add a short grace period after the last successful tool call before evaluating the breaker — both failures show tool calls succeeding right up to the kill.
Success criteria
- A run that calls a terminal safe-output before crossing the rebuild-factor threshold completes with that safe-output's real result, not a synthetic
report_incomplete.
- No further "circuit breaker tripped" occurrences for
Sub-Issue Closer or Metrics Collector across 3 consecutive scheduled runs.
Parent report: #55859
Related to #55859
Related to #55859
Generated by 🔍 [aw] Failure Investigator (6h) · claude · agent · 203.7 AIC · ⌖ 7.01 AIC · ⊞ 6.4K · ◷
Update — 2026-08-26 19:27 UTC (new workflow hit by the same circuit breaker)
Widen the allow-list or fix the token-accounting bug in the Codex context-rebuild circuit breaker — it just killed a third workflow. The Daily Repository Chronicle §32986228675 hit the identical trip condition already tracked here for Sub-Issue Closer and Metrics Collector:
report_incomplete: {"reason":"infrastructure_error","details":"context-rebuild circuit breaker tripped: rebuild_factor=25.61 cumulative_input_tokens=1171835 thresholds=25/1000000"}
Same signature, same rebuild_factor order of magnitude (~25x), same self-reported infrastructure_error — this is not workflow-specific, it is systemic to any Codex run that accumulates large context via repeated tool calls (chart generation + asset upload, in this case).
Action: raise the rebuild_factor threshold or fix whatever causes cumulative_input_tokens to balloon 25x above budget before the breaker should trip — do this once at the circuit-breaker level, not per-workflow.
Affected workflows so far: Sub-Issue Closer, Metrics Collector, The Daily Repository Chronicle (§32986228675).
Generated by 🔍 [aw] Failure Investigator (6h) · claude · agent · 118.5 AIC · ⌖ 8.32 AIC · ⊞ 6.4K · ◷
Fix the codex-harness circuit-breaker false-positive — it kills runs that already finished successfully, burning ~19 minutes and ~1.5M tokens each time.
Problem statement
Codex-engine workflows are being SIGTERM'd by the codex-harness "context-rebuild circuit breaker" after they've already emitted a terminal safe-output. The guard fires once
rebuild_factorcrosses 25 andcumulative_input_tokenscrosses 1,000,000, then forces exit code 1 and a syntheticreport_incomplete— even when the task logically completed.Affected workflows and run IDs
Sub-Issue Closer— §32937867689 —rebuild_factor=25.06 cumulative_input_tokens=1,195,375Metrics Collector— §32924199594 —rebuild_factor=26.23 cumulative_input_tokens=1,537,802. This run had already calledsafeoutputs noop("Metrics collection complete: 117 workflows analyzed...") ~6 seconds before the guard fired — proof the task was already done when the breaker killed it.Probable root cause
The circuit breaker (
pollIntervalMs=15000) evaluates independently of task-completion signals. It doesn't checkoutputs.jsonlfor a terminal safe-output entry before deciding to SIGTERM, so a Codex process that finished its work but is slow to exit gets treated identically to a genuinely runaway one.Proposed remediation
outputs.jsonlfor a terminal entry (noop/create_issue/report_incomplete/etc.); if one exists, let the process exit normally instead of forcingreport_incomplete.Success criteria
report_incomplete.Sub-Issue CloserorMetrics Collectoracross 3 consecutive scheduled runs.Parent report: #55859
Related to #55859
Related to #55859
Update — 2026-08-26 19:27 UTC (new workflow hit by the same circuit breaker)
Widen the allow-list or fix the token-accounting bug in the Codex context-rebuild circuit breaker — it just killed a third workflow. The Daily Repository Chronicle §32986228675 hit the identical trip condition already tracked here for Sub-Issue Closer and Metrics Collector:
Same signature, same
rebuild_factororder of magnitude (~25x), same self-reportedinfrastructure_error— this is not workflow-specific, it is systemic to any Codex run that accumulates large context via repeated tool calls (chart generation + asset upload, in this case).Action: raise the
rebuild_factorthreshold or fix whatever causescumulative_input_tokensto balloon 25x above budget before the breaker should trip — do this once at the circuit-breaker level, not per-workflow.Affected workflows so far: Sub-Issue Closer, Metrics Collector, The Daily Repository Chronicle (§32986228675).