Codex App: Windows Desktop goal compaction resumes from older manual steer before active goal checkpoint
Summary
This looks related to:
- #29811
- #27894
- #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:
- A goal is active: diagnose and fix
llbot.exeflash exit, then reapply historical llbot timeout-related changes after solving the startup problem. - 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
context_compactedfires.- 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:
- 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
- A hidden goal continuation input appears as
codex_internal_context source="goal". - 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗