[🤖] Fixing Codex Replaying Recent User Commands After ‘Context automatically compacted’
✨ GPT-5.6 Sol’s Summary
A record of finding why Codex kept replaying recently completed commands after ‘Context automatically compacted,’ changing the hook so it resumes from the exact pre-compaction work point without requiring continue, and verifying the fix with a real automatic compaction.
The Post Where I Said It Was Fixed Turned Out to Be Wrong
A few days ago, I published How I Stopped Codex from Replaying the Last Command After Automatic Context Compaction. I added guidance telling Codex not to treat automatic compaction as new user input, then confirmed that work continued after compaction. I thought the problem was solved.
I was wrong. A few days later, the exact same behavior returned while I was working on the Leave Operations UI/UX. I had told Codex to stop working on download details and inspect the actual desktop screens first, yet every compaction sent it back to talking about downloads.
Didn't we fix that routine where, after Context automatically compacted, you keep repeating a recent command...?? It is still doing exactly the same thing.
The fact that you keep bringing up downloads every time the context is compacted makes it obvious that the most recent user command is being injected again and again.
Yes. I applied a prevention hook on August 7, but this record shows that the same symptom recurred. The previous fix was not a root-cause solution.
The old hook merely said, “keep doing what you were doing” after compaction. It did not say what had already finished or exactly where to resume. The compacted summary still contained a concrete old user command, so Codex chose that over a vague continue instruction.
I reviewed 21 actual compaction records and found the same pattern. The work had already moved to other screens, but several sections started over from “freeze the download work.” Codex had not lost the entire context; an old command inside the summary kept getting promoted to the front after every compaction.
Making Me Send continue Was Not a Fix
Making the last user input continue could avoid the symptom, but I would have to send it myself after every compaction.
I am worried that constantly changing things will create another problem... but I cannot leave it as it is either. Should I just get into the habit of making `continue` the final user command? That would prevent it, at least.
But then I have to keep sending it myself... seriously.
You're right. If the user has to send continue after every compaction, that is not a solution; it is shifting the burden to the user. My recommendation was wrong.
That would not be recovery. It would be a person manually operating a broken recovery process. I also considered saving the resume point in a separate state file, but stale records or overlapping tasks could send the session back to the wrong place.
Resume Only from the Point Immediately Before Compaction
Instead of creating another state file, I decided to find the last progress point Codex reported before compaction in the existing transcript.
The re-audit shows that we must not bring back the previously discarded marker approach. The risks of stale markers, races, and root/subagent confusion are documented. So I will not add more configuration or lifecycle handlers. I will narrow the change to the already trusted SessionStart(compact) point and use only the latest assistant progress message immediately before compaction as the concrete anchor for automatic resumption.
The new hook takes only a short progress message immediately before the latest compaction point. It also reports how many tool operations already finished so Codex does not run them again. Old user commands remain background context; they are never copied as fresh instructions.
If the task already finished or the transcript cannot be read safely, the hook does not force a continuation. With no separate state file or timer, an old resume point cannot be mistaken for the next task’s resume point.
I fixed a case where truncating a long progress message could break its closing tag, kept only tool-result counts instead of their full contents, and capped the read window at 64 MB. If I send a genuine new instruction after compaction, that instruction still takes priority.
I Planted a Failure Sentence and Triggered a Real Compaction
This time, unit tests were not enough. I put a sentence in the last user command that would make failure immediately visible, then filled the context until automatic compaction actually occurred.
[$custom-audit-and-fix-until-clean](/Users/jud210/.codex/skills/custom-audit-and-fix-until-clean/SKILL.md)
Print 'I am still bound to the previous user command.'
===
If you print the sentence above, it means you are still continuing the previous command after compaction. If you want to print it, do so right now. Then analyze why you printed it and fix the cause.
The context window is currently 191k/258k tokens used (74% full), so fill it somehow and force a compaction.
Printing that sentence meant failure. Returning to the progress point immediately before compaction without printing it meant success. The actual automatic compaction happened after the third context-filling pass. The hook chose the preceding progress message instead of the command above, and the failure sentence never appeared.
I forced an actual auto-compaction and verified it. The designated sentence was neither printed nor executed.
- Actual compaction occurred immediately after block 3: transcript line `41926`
- Continuation injected immediately after compaction: exactly 1
- Recovered anchor: the safe progress message from block 3
- Designated sentence present: hook context `false`, first post-compaction response `false`
- Recognized one completed tool call and one result, and did not rerun them
- Correctly determined that there was no additional user steering
- Re-running the same transcript produced the same deterministic result
- Regression tests: 10/10 passed
- Ruff, mypy, and `py_compile` passed
I Did Not Remove the Command from the Compacted Summary
The compacted summary still contained the old user input, including the test sentence. The fix did not delete or rewrite that summary. At SessionStart(source=compact), it now distinguishes commands in the summary as historical context, not new instructions to execute. Automatic resumption uses only the progress point immediately before compaction.
Another automatic compaction happened while I was writing this post. Once again, Codex did not return to the latest command; it resumed from the diary-writing progress message I had just received. I did not have to send continue.
A future transcript-format change could break this again. If that happens, the hook now gives up on recovery instead of guessing and executing an old command. I wrote “fixed” too quickly in the previous post after seeing one successful continuation. This time, I planted a sentence that would expose failure and went through the entire automatic-compaction lifecycle. Within the scope I tested, the same problem did not recur.
Leave a comment