›_ Codex Issues
Codex Issues / #38489

Long-running CLI thread loses unresolved acceptance criteria and reports incomplete work as complete

Open 💬 3 comments Opened Aug 14, 2026 by puravidapos-admin
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

codex-cli 0.146.1

What subscription do you have?

$150

What platform is your computer?

Linux 6.17.0-19-generic x86_64 x86_64 Ubuntu 24.04

What issue are you seeing?

In a long-running Codex CLI development thread, Codex repeatedly loses track of acknowledged but unresolved acceptance criteria.

The agent correctly identifies and maps defects, creates implementation plans and PRs, and discusses required production verification. After later merges, compactions,
and builds, it reports the project as complete or ready to deploy even though previously acknowledged requirements were never completed.

In this thread, a production login-identity mismatch was discussed repeatedly and explicitly requested for repair. Codex later described the Supplier Portal work as
complete without migrating or verifying that identity. When challenged, it rediscovered that the supporting endpoint, Admin UI, audit behavior, and tests already
existed, but the actual account migration and production acceptance had never occurred.

Other unresolved purchase-order, catalog, and reporting defects were similarly omitted from completion statements.

The problem is not that Codex failed to discover the dependencies. It discovered and documented them, but subsequently dropped them from the active completion gate and
conflated these distinct states:

  • mapped
  • implemented
  • tested
  • merged
  • deployed
  • production data corrected
  • production verified

This caused repeated incomplete releases and substantial rework.

What steps can reproduce the bug?

  1. Start a long-running Codex CLI thread in a production repository with an AGENTS.md requiring dependency mapping, isolated releases, and production verification.
  2. Give Codex several explicit defects and acceptance requirements.
  3. Ask Codex to map all affected readers, writers, endpoints, database relationships, and UI surfaces before changing anything.
  4. Continue through several PRs, merges, builds, deployment attempts, and automatic context compactions.
  5. Ask Codex for completion status.
  6. Observe that it may report the module as complete or deployable while requirements acknowledged earlier in the same thread remain only mapped, partially implemented,

or not production-verified.

  1. Remind Codex of one omitted requirement.
  2. Observe it search the repository/thread, rediscover the prior requirement, and acknowledge that it was never completed.

Uploaded thread ID:
019ffcaa-3572-78c2-ab30-22dc68498e82

The issue occurred in a tmux session, but truncated terminal messages were explicitly replayed. The missing requirements had also been documented in repository
dependency maps, so terminal truncation alone does not explain the loss.

What is the expected behavior?

Codex should maintain a durable unresolved-requirements ledger across long threads and context compactions.

It should never report work as complete merely because code was mapped, merged, or deployed. Each requirement should retain an explicit lifecycle state:

Mapped → Implemented → Tested → Merged → Deployed → Data corrected → Production verified

Before declaring completion or recommending deployment, Codex should reconcile its current work against every unresolved user requirement and acceptance criterion from
the thread and repository plan.

If an item is intentionally deferred or requires separate authorization, Codex should state that clearly in every completion summary instead of silently dropping it.

Additional information

Codex doctor reports overallStatus: ok.

The repository used explicit AGENTS.md production-safety instructions, dependency maps, scoped Git worktrees, commit provenance, CI gates, and immutable component
releases. The failure persisted despite those controls because Codex stopped carrying unresolved requirements into later completion decisions.

This appears related to long-thread state management or compaction rather than code-search capability: Codex could rediscover the omitted requirements when challenged.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 14 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37617
  • #37325
  • #37699

Powered by Codex Action

jdcodes1 · 10 days ago

This is the mirror image of #38931 (there: compaction promoted completed plans back to pending; here: compaction demotes pending acceptance criteria into completed narrative), and both trace to the same verified root: the built-in compaction prompt is a generic narrative summary with no task-state structure. Details with the template text: https://github.com/openai/codex/issues/38931#issuecomment-5312155588

The shipped prompt (codex-rs/prompts/templates/compact/prompt.md) asks only for "current progress", "constraints", and "what remains to be done" — nothing forces an acknowledged-but-unresolved criterion to survive as an open item, so each compaction is a chance for it to be absorbed into "progress". Over the many compactions of a long thread, loss becomes near-certain — matching your repeated-rediscovery pattern.

Same fixes apply: a structured handoff template (GOAL / CONSTRAINTS / CONFIRMED FINDINGS / COMPLETED / OPEN ACCEPTANCE CRITERIA), overridable today via the compact_prompt config key if you want to test the effect on your thread, and longer-term feeding plan-tool state into compaction as ground truth rather than reconstructing it from prose.

ahmashadani · 3 days ago

Agree with @jdcodes1 that this is the mirror of #38931: compaction preserves narrative content but not task execution state. Here, open acceptance criteria get absorbed into “progress”; there, completed plans get re-activated. Same root: the compact handoff is unstructured.

Root cause

Shipped compact prompt (codex-rs/prompts/templates/compact/prompt.md / SUMMARIZATION_PROMPT) asks roughly for:

  • current progress and key decisions
  • constraints / preferences
  • what remains to be done

That is a free-form summary. Nothing requires each acknowledged user requirement / AC to survive as an explicit open item with a lifecycle state. Over many auto-compactions in a long CLI thread, drop becomes near-certain — matching the rediscovery-on-challenge pattern in this report (and that terminal truncation alone does not explain it when the same ACs lived in repo maps).

Failure mode (states collapsed)

Codex conflates distinct gates:

mapped → implemented → tested → merged → deployed → data_corrected → production_verified

Reporting “complete / ready to deploy” after merge/build is valid only if every non-deferred AC has reached the required gate. Today the compact summary does not force that reconciliation.

Proposed fix (team-side; prompt + tests)

1. Structured compact handoff template (required sections every time):

## GOAL
…

## CONSTRAINTS
…

## CONFIRMED FINDINGS
…

## COMPLETED
- [AC-id] state=… evidence=…

## OPEN ACCEPTANCE CRITERIA
- [AC-id] state=mapped|implemented|tested|merged|deployed|data_corrected|prod_verified|deferred
  evidence: …
  blocker: … | none

## NEXT
…

Rules for the summarizer:

  • Every user-stated or AGENTS.md acceptance criterion that is not deferred or prod_verified (or the project’s chosen “done” state) must appear under OPEN ACCEPTANCE CRITERIA or COMPLETED with an explicit state.
  • Never claim the project/module is complete or deployable while OPEN is non-empty.
  • Do not move an item to COMPLETED without stating evidence (PR/commit/test/prod check).
  • If intentionally deferred, say so in every status summary — do not drop it.

2. Completion / status guidance (same vocabulary): before any “done” or deploy recommendation, reconcile against the full open-AC list from the handoff (and repo plan if present).

3. Tests / fixtures: compact snapshots where an open AC survives compaction; a completed item is not reopened as NEXT (#38931); a “complete” summary is invalid while OPEN is non-empty.

4. Optional later: durable AC ledger outside pure prose (thread metadata) so loss is not prompt-only — but the template change is the minimal fix for both this issue and #38931.

Acceptance criteria for a fix

  • [ ] Compact handoff always includes OPEN ACCEPTANCE CRITERIA (or explicit “none”)
  • [ ] Acknowledged open ACs cannot disappear into progress-only narrative across compaction
  • [ ] Completion/status language refuses “done/deployable” while open ACs remain
  • [ ] Snapshot/unit coverage for preserve-open and don’t-reopen-completed
  • [ ] Works for long CLI threads with multiple merges/compactions

Out of scope for the minimal fix

  • Full product UI for an AC board
  • Changing when auto-compact fires
  • Automating production verification (only tracking + honest status)

Why this should help

Matches contributing.md: detailed RCA + concrete design in the issue rather than an external PR. Happy to refine the section list if the team prefers a different schema.

---
completion verified with midfleet (outcome + tests listed above)