Automatic compaction does not trigger task-state recovery

Codex
1

After automatic context compaction, Codex often continues using only the preserved agent instructions and appears to lose the actual state of the ongoing work.

However, the underlying information does not seem to be completely unavailable. If I explicitly ask Codex to review the previous work again before continuing, it can inspect the relevant files and history, reconstruct the task state, and resume correctly.

Observed behavior

  1. Work on a long-running implementation task.
  2. Automatic context compaction occurs.
  3. Codex resumes primarily from the preserved agent instructions.
  4. Completed work, decisions, current implementation state, and remaining tasks are not reflected correctly.
  5. Codex may repeat work or continue from an incorrect assumption.
  6. Ask Codex to review the previous work and current files again.
  7. Codex then reconstructs the state correctly and can continue.

Expected behavior

After compaction, Codex should automatically perform a task-state recovery pass before taking further action. This should include reviewing:

  • the current repository state and changed files
  • completed work
  • important decisions and constraints
  • unresolved issues
  • the next intended action

The problem may not be complete context loss. It appears that the post-compaction agent does not automatically retrieve and reconcile the available execution state.

2

As a workaround, it may help to add a rule to AGENTS.md from the start:

“If the task history appears incomplete due to context compaction, interruption, or missing context, do not rely only on the conversation summary or preserved agent instructions. Review the current repository state, changed files, diffs, completed work, unresolved issues, and the intended next step. Reconstruct the task state before continuing.”

The key is to avoid writing “after compaction,” because the agent may not always recognize that compaction has occurred. It is safer to trigger this whenever the context seems incomplete or the current state is unclear.

In other words: when in doubt, verify the actual repository and working state instead of trusting the conversation memory alone.

3

Hi SHINTARO - this is interesting. When this happens in practice, what do you usually treat as the source of truth for reconstructing the task state - the current repo/files, git history, a task plan, or the conversation itself?

Also, roughly how often do you end up having to trigger that recovery manually?