Codex App: compaction replays completed plan-only prompt before active goal resumes

What version of the Codex App are you using?

26.901.22334 (build 7746)

What subscription do you have?

Not included in this public report.

What platform is your computer?

macOS 26.6.2 arm64

What issue are you seeing?

After context compaction in a long-running Codex App thread with an active goal, a completed historical user request was presented to the model as the current actionable request. The model re-executed that old request, then the hidden goal continuation was injected again and the model resumed the active goal.

This appears closely related to:

• #27731
• #29811
• #19910

The distinctive part of this reproduction is that the resurrected message was a completed plan-only request, while the active goal explicitly said that the plan had already been confirmed and execution should continue without replanning.

Observed control flow

The project and exact conversation text are anonymized, but the structure was:

1. An ordinary user message requested:

   Investigate and produce a detailed plan only. Do not modify files.
   

2. That planning request was completed.

3. A later active goal explicitly stated:

   The detailed plan was confirmed. Persist the confirmed plan and execute it through real acceptance. Do not replan or ask whether to start.
   

4. Codex continued implementing the goal and accumulated substantial implementation, test, and runtime context.

5. Context compaction occurred.

6. The resumed context surfaced the old ordinary plan-only request as if it were the current user request.

7. The model ignored the already-confirmed execution phase and generated a new plan again.

8. On the following continuation turn, the hidden active-goal context was injected again, and the model resumed implementation.

The visible behavior therefore looked like:

active goal is executing
→ compaction
→ completed historical "plan only" prompt becomes current
→ model replans
→ goal continuation is injected again
→ model resumes implementation

This was not a normal interpretation conflict. The old plan-only instruction had already been completed, and the active goal explicitly invalidated the earlier planning-stage instruction.

What steps can reproduce the bug?

1. Start a Codex App task with an ordinary request that has strong, recognizable constraints:

   Produce a detailed implementation plan only. Do not modify files.
   

2. Let Codex complete that request.

3. Start an active goal that explicitly advances to the next phase:

   The plan is confirmed. Execute the confirmed plan through implementation and verification. Do not replan.
   

4. Let the goal run for multiple turns and perform substantial implementation/testing work.

5. Allow automatic compaction to occur.

6. Inspect the first model action after compaction.

7. The stale plan-only request may be treated as newly submitted, causing the model to replan instead of continuing from the active goal checkpoint.

8. Let that turn finish. The next hidden goal continuation may then cause the model to resume execution, demonstrating that two different task pointers were restored at different times.

What is the expected behavior?

Compaction should preserve enough task lifecycle state to distinguish:

historical user request: completed

from:

current active goal: continue execution from latest checkpoint

A completed planning-stage prompt must not become the current instruction after compaction. The model should continue from the latest active goal checkpoint, or stop and report a state conflict if the current task cannot be determined reliably.

Why this matters

This can silently replace a confirmed plan with an unreviewed regenerated plan. In other cases, the resurrected instruction could involve destructive operations, external communication, data cleanup, rollback, or expensive verification.

The failure appears to be in compaction/task-state restoration rather than model reasoning alone:

• before compaction, the active goal correctly continued execution;
• immediately after compaction, the historical ordinary user message regained priority;
• after that repeated turn completed, goal continuation resumed again.

Suggested fix

• Preserve the active goal checkpoint and current execution phase through compaction.

• Mark ordinary user messages as completed after the corresponding task completes.

• Do not place a completed historical message as the latest actionable user item in replacement history.

• Include an explicit post-compaction boundary such as:

  The last ordinary user request was completed.
  Current active work is the goal continuation at checkpoint X.
  Do not re-execute the historical request.
  

Additional information

Thread IDs, local repository paths, source code, credentials, and business data are intentionally omitted from this public report. A private in-app feedback report can provide the original thread identifier if needed.

No source files or tests are named. Start by reproducing the described sequence around automatic compaction, then trace task-state restoration and the ordering of historical user messages versus active-goal continuation. Done means a completed plan-only request is not replayed and execution resumes from the latest active-goal checkpoint, or a state conflict is reported.