Compaction should preserve the current task checkpoint to avoid restart loops in long-running sessions

Summary

In long-running Codex sessions, automatic compaction can complete successfully but still restore the session to the wrong semantic point. After compaction, Codex may resume from an earlier part of the task rather than the current execution point. This causes it to repeat already-completed analysis, re-read the same files, re-run the same exploration, and sometimes enter a compaction/restart loop until the available context or quota is exhausted.

This is different from remote compaction transport failures, timeout errors, or context_length_exceeded deadlocks. The compaction itself may appear to succeed; the problem is that the compacted state does not reliably preserve the current task control-flow state.

Observed behavior

During a long task with multiple phases or a large debugging/analysis chain:

1. The user starts a specific task or phase.
2. Codex makes substantial progress inside that phase.
3. Automatic compaction is triggered mid-task.
4. After compaction, Codex often behaves as if it is back near the beginning of the current round or an earlier phase.
5. It repeats previously completed work instead of continuing from the latest execution point.
6. The repeated work consumes more context, causing another compaction.
7. The session can become stuck in a loop of:

make progress -> auto-compact -> lose current checkpoint -> restart earlier work -> consume context -> auto-compact again

Expected behavior

Compaction should preserve a minimal but explicit continuation checkpoint for the current task, not only a general summary of historical conversation context.

After compaction, Codex should know at minimum:

• the latest user task / active phase,
• the current execution point,
• major steps already completed,
• stable conclusions already established,
• rejected paths that should not be repeated,
• the exact next action,
• the stop condition for the current task.

If there is ambiguity, Codex should verify the continuation point instead of restarting older work.

Why this matters

This is especially painful for long-chain tasks such as:

• large repository analysis,
• complex debugging,
• reverse-engineering-style local research,
• multi-file refactors,
• phased investigation workflows,
• tasks where earlier hypotheses have been explicitly rejected.

In these workflows, the cost of losing the current checkpoint is much higher than losing some general historical context. A single bad compaction can undo a long analysis phase and make the agent repeat the same loop several times.

Related but distinct from existing issues

There are existing reports about compaction failures, context limits, and responding to earlier messages. This issue is specifically about successful compaction that loses the current task checkpoint / continuation pointer, causing repeated work and compaction loops.

It is related in spirit to cases where Codex replies to earlier messages instead of the latest one, but here the failure mode appears during long-running sessions after compaction and affects the task execution state.

Suggested improvement

Consider making compaction produce a structured checkpoint instead of, or in addition to, a free-form summary. For example:

CURRENT_TASK:
CURRENT_PHASE:
PROGRESS:
CONFIRMED_FACTS:
REJECTED_PATHS:
NEXT_ACTION:
STOP_CONDITION:
DO_NOT_REPEAT:

Potential product-level improvements:

1. Preserve a structured current-task checkpoint across compaction.
2. Make the compacted summary/checkpoint visible to the user.
3. Allow users to configure compaction to happen only at task/goal boundaries.
4. After compaction, run a continuation verification step before doing tool calls.
5. Detect repeated post-compaction loops, such as repeatedly reading the same files or restarting the same exploration.
6. Allow advanced users to maintain a lightweight local round-state file that Codex treats as authoritative after compaction.

Workaround currently used

A practical workaround is to maintain a temporary, round-local state file such as .CODEX_ROUND.md with a very small state register:

GOAL:
SCOPE:
PROGRESS:
FACTS:
REJECTED:
NEXT:
STOP:
RULE:

This file is updated only after major steps or stable conclusions, not after every small file read or command. It is deleted when the current task is complete.

This workaround helps, but it should ideally be built into Codex's compaction/recovery protocol so users do not need to manually enforce it in every long-running session.