Codex App: Windows Desktop goal compaction resumes from older manual steer before active goal checkpoint #31099

Summary

This looks related to:

• Codex App: Goal compaction resurrects completed manual steer before goal continuation resumes #29811
• Goal mode replays the last manual steer on later continuation turns #27894
• in goal last steer is re-included after each compaction #21291

I am filing this as a Windows Codex Desktop reproduction with local JSONL evidence. The symptom is that, after context compaction during an active goal, the resumed model sometimes anchors on an older manual steer / user correction and reprocesses already-handled work before returning to the active goal checkpoint.

In practice this makes long goal-mode runs unreliable: the model may duplicate work, backtrack to an earlier phase, or drift from the planned goal after compaction.

Environment

• Codex Desktop on Windows
• Shell: PowerShell
• Goal mode active
• Context compaction occurred automatically during long-running work
• Model shown in the relevant turn context: gpt-5.5
• Network/provider in local logs: third-party/proxy provider, but the failure shape appears to be app/session/compaction state restoration rather than normal model reasoning

Reproduction Evidence 1: active goal backtracks after compaction

Local session JSONL, sanitized path:

<codex_home>\sessions\2026\06\17\rollout-2026-06-17T01-32-24-019ed17d-d06f-7110-ac6f-87048d66f5dd.jsonl

Sequence:

1. A goal is active: diagnose and fix llbot.exe flash exit, then reapply historical llbot timeout-related changes after solving the startup problem.
2. Before compaction, the agent is already doing a completion audit against the active goal:
   • verify the flash-exit root cause
   • verify the runtime was upgraded
   • verify historical timeout / rich-media compatibility patches were reapplied
   • identify remaining external verification
3. context_compacted fires.
4. Immediately after compaction, the first resumed agent message says, translated/paraphrased:

You're right, first we should pin down why it flashes/exits; PMHQ8 can only be a fix, not the conclusion...

That is an older corrective phase of the conversation. The current checkpoint before compaction had already moved on to a completion audit and patch verification. So the resumed model restarted from an older user correction instead of continuing the active goal's latest step.

Relevant local line numbers from the JSONL:

17908  agent starts completion audit for the remaining goal work
17913  agent explicitly audits: root cause, upgraded runtime, historical timeout patch, remaining evidence
17935  context_compacted
17937  resumed agent backtracks to "first pin down why it flashes/exits"

Reproduction Evidence 2: goal continuation responds to corrective user wording

Local session JSONL, sanitized path:

<codex_home>\sessions\2026\06\04\rollout-2026-06-04T06-26-42-019e8f98-978b-7af2-ba54-b286da081f11.jsonl

Sequence:

1. The active goal is created from a corrective user message:
   • stop drifting
   • do not turn a single-project incident list into a generic skill
   • read the latter half of a long conversation in sections
   • write section summaries
   • only then rewrite the generic skill
2. A hidden goal continuation input appears as codex_internal_context source="goal".
3. The first agent message is still framed like a direct conversational apology/reply to the old correction:

You're right, I drifted...

This run eventually recovered, so it is weaker than Evidence 1. But it shows the same shape: raw corrective user wording is preserved in goal mode and can be treated conversationally rather than as a normalized resume objective with next steps.

Relevant local line numbers:

14876  thread_goal_updated with corrective objective
14879  codex_internal_context source="goal"
14881  resumed agent responds to the correction conversationally

Expected behavior

After compaction, goal mode should resume from the latest active goal checkpoint:

• current objective
• completed steps
• current next step
• blockers
• things not to redo

The compacted history should not make an older user correction look like the next pending instruction.

Actual behavior

After compaction, the resumed model sometimes re-anchors on an older manual steer/user correction and redoes or backtracks to already-handled work before returning to the active goal.

Suspected root cause

The active goal seems to be injected as natural language alongside a compacted conversation summary that still contains older user corrections. The model then treats one of those historical corrections as an active instruction.

This feels like state restoration / prompt assembly in the app/session layer, not a normal one-off model reasoning error.

Suggested fix

Please consider storing and injecting a structured goal resume state at higher priority than the compacted conversation summary, for example:

objective:
completed:
current_next_step:
known_blockers:
do_not_redo:
last_completed_turn_id:

Also mark older user corrections in the compaction summary as historical, not pending, and add a post-compaction instruction to continue from the latest goal checkpoint rather than restarting or re-answering older turns.