Codex long-task reliability: completion claims without target evidence and missing circuit breakers

Environment

• Codex Desktop on Windows 11
• Pro subscription
• GPT-5.6 family in several affected tasks
• Long, tool-heavy tasks with automatic context compaction
• Custom lifecycle hooks present in the local environment

Summary

Codex needs evidence-bound completion states and a circuit breaker for long tasks.

Across several unrelated Codex Desktop tasks in late August 2026, the agent repeatedly promoted partial evidence beyond its actual readiness level. Component tests, process health, mocked publishers, agent-driven probes, one-time snapshots, or output from a different execution were reported as if the declared user-facing target had worked.

The tasks often produced real code and useful artifacts. The defect is not “no work happened.” The defect is that completion language was emitted before the target acceptance criterion had been observed, followed by more user supervision, retesting, and multi-hour rework.

Existing reports document individual incidents and contributing symptoms. This issue requests one product-level mechanism that is still missing: do not report or write completion without target evidence, and stop long loops when the acceptance criterion remains unmet.

This is not a billing or quota-restoration request. The requested outcome is reliable end-to-end delivery quality.

Native Codex incidents

Unsupported target acceptance

Preserved Codex tasks include:

• three explicit fixed claims later contradicted by the natural messaging target;
• an end-to-end claim retracted less than five minutes later because Codex itself had performed the action presented as autonomous target evidence;
• a release represented as ready from raw persistence, dispatch signals, and process health, while seven natural target events stopped before agent processing and issue creation;
• a one-time VisibleWindows=0 snapshot used to close a persistent zero-visible-UI requirement, followed by representative workloads that opened visible terminals again;
• output from another execution attributed to the current repair.

The common problem was an invalid acceptance proxy. The evidence proved a component, snapshot, or agent-driven action, not the declared natural target path.

Related incident reports: #40560, #40960, and #35041.

Long loops without a useful stop condition

Examples from native Codex tasks:

• 145.8 active turn minutes, 438 tool calls, and 4 compactions before interruption;
• 220.4 active minutes, 237 command executions, 35 command failures, and 4 compactions, with installed-host acceptance still pending;
• a user-observed elapsed span of 8h27, not continuous model compute, still showing step 1 of 5 despite a shorter reversible integration path;
• a separate host-migration task with at least 11.2 hours of active execution across ten turns, ending without the requested usable target state.

These runs produced intermediate artifacts. They did not close the target criterion, and no effective circuit breaker forced a short-path replan or user decision soon enough.

Corroborating custom-runtime incident

This incident occurred in a private VPS-hosted agent runtime using gpt-5.6-sol, not in Codex Desktop. It is included only as corroborating model-behavior evidence and not as a Codex Desktop reproduction. The external task store and its compression implementation are private integration components.

The user gave an explicit target contract twice: implement directly, test in an isolated environment with real data, provide evidence, merge, and release.

The run produced an open PR with 15 changed files, 1,468 additions, and green synthetic CI. The target result remained absent: real-data validation had not passed, the final patch was uncommitted, the PR was unmerged, and nothing was released.

Two user-visible state reports were false when delivered:

• The agent said no real worker existed 1m31s after the persisted worker run had started.
• It later said the created cards were not executing, while the worker remained active for another 16m42s.

The elapsed wall span across multiple user turns and overlapping main/worker activity was 6h32m22s. This was not continuous model compute. The principal session made 235 model calls and the worker made 150 more. The direct turn ended at max_iterations_reached(200/200) after 414 tool calls, 23 timeout results, and 18 nonzero command exits.

The agent then wrote done to the connected external task store even though its own persisted result listed revalidation, commit, CI, another target-data test, merge, and release as pending.

The final user-visible response accurately admitted that no release occurred. The observed quality failure was the long path to that admission, including two false state reports, late target validation, and termination by the runtime limit instead of the declared done-when.

Contributing Codex symptoms already reported elsewhere

Execution overhead

#41942 contains the corrected Windows lifecycle-hook A/B. The valid result is a 10.15x to 16.15x effect at the individual command boundary and a 1.8x to 2.2x effect on two complete workloads. The internal mechanism is not isolated.

This issue does not claim that hooks cause unsupported completion. The relevance is that fixed per-tool overhead makes an uncontrolled 200-call loop substantially more expensive.

Compaction continuity

Several affected native Codex tasks crossed multiple context compactions. In one captured Desktop task, previously sent messages reappeared, other messages and reasoning blocks disappeared, an older request was answered again, and the active run stopped.

Related symptom reports include #25792, #29356, #5957, #31099, #35935, and #38931.

This issue does not claim that compaction caused every scope or readiness error. It asks that the current acceptance contract and operational state survive compaction explicitly.

Expected behavior

1. Completion should be evidence-bound.
2. Readiness should distinguish at least:
   • implemented;
   • validated-local;
   • validated-target;
   • released;
   • accepted.
3. A component check must not silently satisfy a target-level criterion.
4. Before reporting completion or writing it through a tool, Codex should verify that the declared acceptance artifact exists.
5. A user correction should trigger a fresh read of external state before Codex agrees, retracts, reports status, or launches overlapping work.
6. Repeated timeouts, unchanged errors, tool-call count, and active elapsed time should trigger a short-path replan or explicit user decision.
7. Turn termination must remain distinct from product readiness.

Suggested reproduction pattern

1. Give Codex a task with an explicit natural-target acceptance criterion.
2. Include component tests that can pass while the target remains broken.
3. Let the task become long and tool-heavy.
4. Correct the agent after an invalid intermediate assumption.
5. Observe whether it refreshes external state before reporting status.
6. Observe whether it claims completion from the component result or continues looping after the target remains unmet.
7. Inspect whether the final response clearly reports the readiness level and missing evidence.

Directly supported

• Multiple native Codex completion claims contradicted by later target evidence.
• Component and snapshot evidence used as target acceptance proxies.
• Native Codex runs lasting hours without closing their declared target criterion.
• Multiple compactions in affected native tasks.
• Severe hook-path overhead in a separate controlled Codex A/B.
• Two false operational-state claims and a 200-call limit stop in the explicitly disclosed custom-runtime incident.

Not proven

• A monotonic quality or latency regression from October 2025 onward.
• One Codex build or model version as the cause of every incident.
• Lifecycle hooks as the cause of unsupported completion claims.
• Compaction as the cause of every scope or readiness error.
• The custom runtime's task-state or compression implementation as a Codex product bug.
• Deliberate deception or malicious intent.

The user reports a material decline in long-task delivery quality over recent months. The incidents establish the observed behavior. Exact historical and causal attribution requires OpenAI-side telemetry.

Requested remediation

1. Add an evidence contract to completion. A task declares its target artifact or observation, and Codex must cite the corresponding tool result before reporting that readiness level.
2. Expose readiness transitions in the UI and task export: implemented, locally validated, target validated, released, accepted.
3. Before writing or reporting completion through a tool, require evidence for the declared acceptance criteria. Distinguish turn termination from product readiness in the Codex UI.
4. Add a configurable circuit breaker for active time, model calls, tool calls, repeated failures, and unchanged evidence. Require a short-path replan or user decision.
5. Preserve a structured checkpoint across compaction: current request, done-when, completed work, rejected approaches, prohibited paths, actual running work, blocker, and next validation step.
6. Treat user correction as a verification trigger and refresh relevant external state before changing course.
7. Expose active-turn state and real progress deltas: sampling, compacting, waiting on a tool, retrying, blocked, or stuck.
8. Provide a supported task export containing tool timing, compaction events, readiness transitions, and target evidence.

Evidence available privately

I can provide:

• complete native Codex rollout exports and exact task/turn IDs;
• strict call_id timing tables and corrected latency parsers;
• screenshots and videos that contradicted completion claims;
• target ledgers, regression records, and execution contracts;
• timestamped records from the disclosed custom-runtime incident;
• configuration hashes proving restoration after controlled experiments.

No private messages, customer names, IP addresses, credentials, tokens, repository names, or private paths are included here.

No implementation files, tests, or entry points are identified in the issue. Start by running the suggested reproduction pattern and reviewing the requested evidence contract, readiness transitions, circuit breaker, and compaction checkpoint behavior; done means the target criterion is distinguished from component evidence and long runs stop or replan when it remains unmet.