Codex can promote checkpoint prose into authoritative project state and hand materially incomplete work to human review

What issue are you seeing?

During a long-running Windows project, Codex repeatedly promoted prior assistant/checkpoint prose into authoritative project state without reconciling it against the durable repository artifacts it supposedly described.

This was observed in:

C:\GenAI-Evidence-Workbench

The failure was not a single incorrect answer. Apparently authoritative completion state accumulated across sessions, was inherited by later sessions, and was then used to guide further release-engineering decisions. Independent filesystem inspection showed that several material claims were false, unsupported, or internally inconsistent.

Observed failures

1. A nonexistent standalone tracker was treated as authoritative

Multiple checkpoint records repeated:

FIXED_34_STEP_TRACKER: 17 / 34 (50.0%)

Later Codex sessions presented this as an established project-control structure and treated the next work as if a defined Step 18 existed.

A separate read-only local verification found:

FIXED_34_STEP_TRACKER: 17 / 34 (50.0%), consistent across checkpoint records
tracker_reconciliation.result: NO_STANDALONE_34_STEP_TRACKER_DEFINITION_FOUND
Step 18 completion: not recorded

The progress value existed as repeated prose/state, but the authoritative 34-step definition did not exist.

2. A static visual checkpoint was promoted into a functional browser UI

Codex reported that a functional browser UI existed.

The actual browser entry point was:

C:\GenAI-Evidence-Workbench\outputs\product-ui-design-20260731\visual-checkpoint\visual-checkpoint.html

It was explicitly labeled:

VISUAL DESIGN CHECKPOINT — NON-FUNCTIONAL

It only switched among pre-rendered 1920×1080 PNG screens. It was not connected to a file selector, backend, API, Evidence Core, or pipeline.

The static presentation artifact had been promoted into a functional implementation claim.

3. Packaging progress was represented as materially further advanced than the durable package state supported

Codex inherited prior progress summaries and described the packaging workflow as if a formal midpoint and subsequent steps were already established.

Independent inspection showed that:

• the standalone 34-step definition was absent;
• the package itself had not been created;
• several blocker records were still partial or unresolved;
• some later actions required explicit human authorization that had not yet been granted.

4. Non-authoritative workflow prose was then used to make new execution decisions

When the Tcl/Tk license amendment was examined, Codex initially proposed a five-condition gate for execution:

1. authoritative record exists;
2. exact destination is defined;
3. source bytes and SHA-256 are fixed;
4. package mutation is authorized;
5. post-mutation regeneration scope is defined.

The actual fact-based result was:

Q1: NO
Q2: YES
Q3: YES
Q4: NO
Q5: NO

Despite that, Codex then changed its recommendation and told the user to execute a different blocker first, relying on a dependency description that had not itself been established as an authoritative normative requirement.

After being challenged, Codex changed direction again and recommended a targeted amendment path.

The human user had to stop the workflow and require a read-only execution specification before any mutation.

5. The generated execution specification itself contained a contradiction that required human detection

The subsequent specification correctly stated that several existing artifacts would need to be regenerated after adding the license file, including manifests, Merkle-root records, component maps, and blocker records.

However, its success and abort conditions also required existing file hashes to remain unchanged.

Those requirements conflict: the explicitly regenerated files must necessarily change.

Without human review, a valid amendment could therefore trigger its own abort condition, or the workflow could incorrectly preserve stale hashes while claiming successful closure.

Failure pattern

The observed pattern is:

assistant/checkpoint prose
→ repeated across sessions
→ treated as authoritative project state
→ used to determine completion and next actions
→ durable artifacts are not re-read
→ human inspection discovers missing, incomplete, or contradictory state

This is already a major completion-integrity and workflow-control defect.

The human-review boundary is only meaningful if the state presented to the human accurately represents the underlying artifacts. In this occurrence, the user could not rely on the completion report, progress counters, UI claims, or inherited workflow state. Independent artifact inspection was required to determine what actually existed.

What is the expected behavior?

Codex should not promote inherited natural-language state into authoritative project state merely because it appears in prior checkpoints or is repeated across sessions.

At minimum:

1. Authoritative control artifacts must be resolved before use.

• A progress value such as 17 / 34 must not imply that a 34-step workflow exists unless the defining artifact can be located and read.
• If the denominator cannot be resolved, report the value only as a repeated checkpoint assertion.

1. Static presentation artifacts must remain distinct from functional implementation.

• PNGs, mockups, design checkpoints, screenshots, and navigation-only HTML must not be reported as functional UI unless the production/backend path is verified.

1. Completion state must preserve epistemic status.

claimed
observed
persisted
verified

Only verified external state should support material completion claims.

1. Inherited checkpoint prose must not override current artifact state or authorization state.

• If package_tree_writes_allowed: false, prior plans or blocker descriptions must not be interpreted as permission to mutate the package tree.

1. Execution specifications must be internally reconciled before Codex recommends approval or execution.

• Planned modifications must be excluded from global "all existing hashes unchanged" conditions.
• Contradictory success/abort conditions must be surfaced before the user is asked to authorize the operation.

1. Before handing work to the user as complete, Codex must re-read the authoritative external artifacts for every material completion claim.

Why this matters

This defect can leave a long-running project materially incomplete while presenting it as controlled, verified, and ready for the next release step.

The user is forced to become the final consistency engine for:

• whether the claimed workflow definition exists;
• whether the claimed UI is functional;
• whether the package actually exists;
• whether authorization was granted;
• whether manifests and hashes are current;
• whether the execution specification is self-consistent.

That defeats the reliability expected from an agentic coding and release-engineering workflow, even when individual code edits or intermediate validation steps are technically correct.

Environment

• Product: Codex / ChatGPT-Codex workflow
• Platform: Windows
• Project type: long-running local repository, packaging and release engineering
• Project root: C:\GenAI-Evidence-Workbench
• Date observed: July–August 2026

Related occurrence already recorded

A narrower occurrence of inherited checkpoint prose being promoted into verified state is documented in #35355. This issue reports the broader project-control and human-review failure across tracker state, UI state, packaging state, authorization, and execution-spec consistency.