Context compaction can turn completed plans into active work, causing repeated investigation loops

Summary

In long-running Codex tasks, context compaction can appear to preserve the content of an earlier plan while losing its execution state. As a result, work that was already performed can be reintroduced after compaction as if it were still the next action.

This causes repeated investigation/planning loops and wastes context/tokens.

What I observed

I asked Codex to inspect whether a UI migration had caused any functional regressions, with the constraint that it should first perform a read-only audit and not modify code.

Before compaction, Codex explicitly stated that it would perform a read-only audit and then proceeded with the inspection.

After context compaction, Codex again emitted essentially the same plan:

I’ll first do a read-only inspection, focusing on routes, key interactions, notifications, login flow, and static assets; I won’t modify code yet.

This was not a new user instruction. It was a restatement of an earlier plan that had already been acted on.

The session still remembered useful facts discovered before compaction (for example, that type checking passed and some routes/build artifacts had been checked), so the problem did not look like complete context loss. Instead, it looked like the compaction summary preserved an old plan without clearly marking whether it was completed, in progress, or still pending.

Why this matters

For agentic coding tasks, these are semantically different pieces of state:

• user goal
• constraints
• confirmed findings
• completed actions
• currently-running action
• remaining actions

If compaction collapses them into a generic narrative summary, an earlier statement such as “next I will inspect X” may be interpreted after compaction as a fresh instruction to inspect X again.

This can produce a loop like:

1. inspect repository / routes / UI behavior
2. collect findings
3. context compaction occurs
4. old plan is restored as current work
5. inspect the same areas again
6. repeat after later compactions

Steps to reproduce

This is easiest to observe in a long-running Desktop task:

1. Ask Codex to perform a multi-step read-only investigation before making changes.
2. Let it execute several checks and report intermediate findings.
3. Continue until automatic context compaction occurs.
4. Observe the first planning/status messages after compaction.
5. In affected runs, Codex restates an earlier already-executed plan and begins re-investigating the same areas.

Expected behavior

Compacted context should preserve task state explicitly enough that completed work is not promoted back into pending work.

Conceptually, a compaction handoff should distinguish at least:

GOAL
USER CONSTRAINTS
CONFIRMED FINDINGS
COMPLETED
CURRENTLY INVESTIGATING
NEXT

The exact internal representation is not important, but the post-compaction agent should be able to tell that an earlier plan has already been executed.

Actual behavior

The compacted context appears to preserve the wording/intention of an earlier plan, but not always its temporal state. The next model continuation can therefore treat historical plans as current tasks and repeat work.

Related issues

#38466 mentions repeated status/planning messages after repeated compaction in very large Desktop threads, but this report is narrower: the issue is specifically loss of completed vs pending task-state semantics during compaction, which can directly cause duplicated tool work even when much of the factual context is still retained.

I can provide a screenshot showing the near-duplicate pre- and post-compaction planning messages if useful.

Start by locating the context-compaction handoff and the post-compaction planning flow for long-running Desktop tasks. Trace how completed actions, current work, and pending work are represented, then find or add coverage that demonstrates a completed investigation is not repeated after compaction.