Context compaction forgets AGENTS rules: task progress can jump from 97% back to 42%

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #25686
• #25394
• #25563
• #24779
• #24366

Powered by Codex Action

I don't see this as an issue. A self-reported progress estimate in the way you implemented it is always going to be arbitrary and performative unless you have the agent durably document it. Try using an ExecPlan.

If context compaction loses or weakens that memory, Codex may waste time/tokens, redo work, make inconsistent decisions, or violate project instructions.

If you're relying on context as your sole source of memory, then compaction will, by definition, weaken that memory.

I disagree that this is not an issue. I think it is a serious issue.

The purpose of context compaction should not be to arbitrarily weaken all memory. A good compaction system should compress lower-value or already-finished context while preserving the critical state needed to continue the task safely: the current goal, AGENTS/project rules, active TODOs, completed work, remaining work, blockers, and decisions that still affect the implementation.

Using an ExecPlan may be a useful workaround, but it should not be required just to survive compaction. If Codex loses the current task checkpoint after every automatic compaction, then long-running sessions can enter restart loops or become inconsistent. That is a product reliability problem, not just a user prompt-format problem.

There are also many related reports in this repo where users describe similar behavior: after context compaction, Codex loses memory, applies AGENTS.md inconsistently, or no longer knows what it should do next. For example, this issue was automatically linked to #25884 and #25900, which describe similar long-session/compaction continuity failures.

If someone has not run very long Codex tasks, this may be less visible. But for deep usage with long implementation sessions, this is a major failure mode. Imagine asking Codex to complete a long task, then every time the context is compacted, it forgets the current progress, loses the checkpoint, or becomes unsure what to do next. That is not acceptable for a coding agent that is expected to handle long-running work.

To be clear, I am not saying every old detail must remain verbatim in context forever. I am saying compaction needs to preserve the important context directly and summarize or archive lower-priority information. The compaction decision itself needs to be reliable. If it drops the wrong state, it can cause duplicated work, inconsistent decisions, missed requirements, or even bugs in the resulting code.

So yes, durable task documentation can help. But the underlying context compaction behavior still needs to be improved so critical project instructions and task state are retained across compaction boundaries.

A representative example: Before compaction, Codex reported progress around 97%. After context was automatically compacted, the task checklist and progress state appeared to restart or regress, and Codex reported progress around 42%. This kind of sudden progress regression suggests at least two possible problems: 1. Codex's task-progress estimation may be unreliable or poorly calibrated for long-running work. 2. More importantly, context compaction appears to lose or distort important task memory, including project rules, current task state, and previous progress decisions.

Your representative example is not at all suggestive of a serious issue. Based on what's visible, your prompts don't enforce any sort of rigor in progress accounting.

I am saying compaction needs to preserve the important context directly and summarize or archive lower-priority information.

Important stuff needs to be stored in a non-lossy vessel. If you're not using any sort of file for task/progress tracking, perhaps try it, and see if you still encounter the same issue. If you think that the agent shouldn't need such a thing, well, that's wish casting.

> A representative example: > > Before compaction, Codex reported progress around 97%. > After context was automatically compacted, the task checklist and progress state appeared to restart or regress, and Codex reported progress around 42%. > > This kind of sudden progress regression suggests at least two possible problems: > > 1. Codex's task-progress estimation may be unreliable or poorly calibrated for long-running work. > 2. More importantly, context compaction appears to lose or distort important task memory, including project rules, current task state, and previous progress decisions. Your representative example is not at all suggestive of a serious issue. Based on what's visible, your prompts don't enforce any sort of rigor in progress accounting. > I am saying compaction needs to preserve the important context directly and summarize or archive lower-priority information. Important stuff needs to be stored in a non-lossy vessel. If you're not using any sort of file for task/progress tracking, perhaps try it, and see if you still encounter the same issue. If you think that the agent shouldn't need such a thing, well, that's wish casting.

This response misrepresents the issue and draws an unsupported conclusion.

The report is not “wish casting,” and it is not merely about whether a progress percentage is perfectly calibrated. The attached screenshot shows a concrete continuity failure: Codex reported the task as being around 97% complete, then after “Context automatically compacted,” it rebuilt the task state as if much less had been completed and reported around 42%. That is not normal progress accounting drift. That is evidence that the post-compaction state no longer matched the pre-compaction state.

The claim that my prompts “don’t enforce any sort of rigor in progress accounting” is also incorrect. The second screenshot shows that my custom instructions explicitly require Codex to report the current phase, completed work, remaining work, blockers, TODO state, and to keep the percentage synchronized with the task state. You can argue that this is not a formal external ledger, but you cannot reasonably claim there was no rigor or no continuity requirement.

Also, if you have not encountered or reproduced this exact compaction failure mode, please do not casually conclude that it is “not at all suggestive of a serious issue.” The screenshots show a real state discontinuity across an automatic system transition. Dismissing it because you personally have not seen it, or because you prefer a durable file workaround, is not a technical rebuttal.

A task/progress file is a workaround, not a defense of the current behavior. Codex’s automatic context compaction is part of Codex’s own long-running task runtime. If that runtime silently loses or distorts AGENTS rules, custom instructions, current TODO state, acceptance criteria, completed work, remaining work, or validation requirements, that is a product reliability issue. Users should not have to build their own external state-preservation mechanism just to prevent Codex from regressing after an automatic internal compaction step.

Saying “store it in a non-lossy vessel” does not address the bug. It only shifts responsibility from the system to the user. The compaction system itself should preserve the high-priority execution state needed to continue the task correctly. If it cannot reliably do that, then the issue is exactly what this report describes.

This is also not an isolated interpretation of one percentage number. Similar reports describe Codex reverting to earlier work after compaction (#25686), losing the current turn and replaying previous work (#10346), or forgetting that it had edited files and stopping mid-task (#5957). The recurring pattern is that compaction can break task continuity.

So the problem is not that I expected a magic progress meter. The problem is that after automatic compaction, Codex appeared to continue from a degraded or reconstructed state rather than from the actual prior task state. That is a serious issue for long-running agent workflows, especially when project rules, TODO state, and validation requirements are involved.

The 97% → 42% progress regression is a textbook example of context compaction destroying structured knowledge. This is happening because the compaction algorithm treats all context equally — it doesn't understand that AGENTS.md rules and task progress metadata are structurally different from conversational history. What's needed is structured context preservation during compaction: AGENTS.md rules → should be re-injected, not compacted Task progress state → should be checkpointed to external storage Code changes made → should be tracked in a diff log Decision rationale → should be preserved as project memory The compaction algorithm is optimizing for token budget, not for _knowledge retention_. These are fundamentally different objectives. We ran into this exact problem space while building AgentRelay. The solution we landed on is a context tier system: Tier Content Compaction Behavior T0: Identity AGENTS.md, CLAUDE.md, project rules Never compacted, always re-injected T1: State Task progress, checkpoints, current goal Externalized to persistent store T2: Memory Key decisions, patterns, warnings Compressed with semantic priority T3: History Conversational context, tool outputs Aggressively compacted When the agent's context approaches the limit, the compaction process should: 1. Keep T0 intact (always in context) 2. Externalize T1 to the persistent store (can be re-loaded on demand) 3. Compress T2 using semantic importance scoring 4. Summarize T3 as usual This way, when compaction happens, the agent doesn't lose track of _what it was doing_ (T1) or _what rules it must follow_ (T0). The 97% → 42% regression simply can't occur because the progress state was never in the compaction zone. OpenAI has an opportunity to set the standard here. If Codex implements structured context tiers, it would immediately differentiate from competitors who treat all context as equally disposable. The fact that this is happening on both Claude Code and Codex suggests it's a systemic issue with the current generation of coding agents — not a bug in either product, but a fundamental architectural gap in how we handle agent memory.

Exactly. This is the core of the issue.

The problem is not just the numeric progress estimate. The problem is that Codex appears to treat critical execution state and ordinary conversational history as if they were the same kind of context during compaction.

AGENTS.md/project rules, current TODO state, completed-vs-remaining work, validation requirements, and previous decisions should not be compacted or weakened in the same way as normal chat history. They are part of the task runtime state.

A tiered context model like the one you described would directly address the failure mode shown in my screenshots: T0 rules should be re-injected, T1 task state should be checkpointed, and only lower-priority history should be aggressively summarized.

This is a clean illustration of why compaction and long-task state shouldn't run through the same mechanism. Progress jumping from 97% back to 42% isn't really a calibration problem. It's what it looks like when the checklist and the decisions behind it get summarized along with the rest of the conversation. Once they've been paraphrased the model is reconstructing where it was instead of reading it, and reconstruction drifts.

The things you listed under expected behavior aren't conversation. The AGENTS rules, the acceptance criteria, the live TODO state, the decisions already made. Those are execution anchors, and they want to be held verbatim and re-injected after every compaction rather than passed through the summarizer at all. The conversation around them can be lossy. That small set can't be, or you get exactly this kind of regression.

The progress drop is worth keeping as a signal in its own right too. A sharp backwards jump right after a compaction is a fairly reliable sign that the anchor set didn't survive. Instead of only trying to compress better, it would help to check those anchors are still present after compacting and say so, so the user knows whether the run is safe to continue or has quietly lost its rules.

We ran into the same shape of problem building a memory layer that has to survive context resets across tools, and what actually fixed it was giving that small set of facts its own home outside the transcript so compaction couldn't touch them. Compressing the conversation is fine. Letting it compress the task's source of truth is where it breaks.

Possible strong relation to #28736.

#28736 now has source + testcase evidence that SessionStart(source=compact) is not fired immediately after mid-turn auto-compaction. Compact events are queued and only delivered on a later turn.

If hooks are being used to restore AGENTS/custom rules or task-state reminders after compaction, that would mean the post-compaction agent continues the same logical turn without those restored rules/context. That seems consistent with the progress/rule drift described here.

Rules being lost during compaction is the fundamental problem with in-context memory — the model can't know which instructions will be needed later, so it sometimes drops critical ones. External persistent memory solves this: store rules and critical context at high importance (0.9+) in a memory server, and inject them into every post-compaction context window. Unlike in-context storage, external memories survive any number of compactions and are recalled by relevance. Our setup handles this: https://github.com/Dakera-AI/dakera-deploy/blob/main/docker/docker-compose.local.yml

@ferhimedamine yeah, an external home for the critical stuff is the fix — that's
the shape I ended up at too (it's the execution-anchors point I made earlier up the
thread: the rules / acceptance criteria / decisions want to live outside the
transcript so the summarizer can't paraphrase them). So we're agreed on the
load-bearing part.

The one spot I'd push is "recalled by relevance / high importance (0.9+)."
Importance answers which facts to re-inject after a compaction — it doesn't
answer whether a fact is actually true. And that's the failure that actually bit
me: a confident inference the model made earlier and nobody checked can score just
as "important" as a rule I set on purpose, so it comes back with the same 0.9
weight, wearing the same anchor clothes, and the next turn builds on it as settled
fact.

So importance is the right retrieval signal — I just don't think it should be the
gate for what returns as ground truth. What earned trust should: did a human sign
off, did a test pass, is it pinned to something real in the repo. Otherwise
compaction quietly becomes the moment your highest-confidence guess gets promoted
to fact.

The way I ended up handling it: tag each fact with how it earned trust, so the
re-inject step can tell a real anchor from a good-sounding guess instead of going
on importance alone.

Adding a very modest workaround here, not as a replacement for a native Codex fix.

I built a small hook-based tool for the same broad failure mode: after compaction, the resumed agent may no longer have enough live task state to continue safely.

Repo:

https://github.com/Sakiyary/codex-compact-continuity

The idea is intentionally lightweight:

• PreCompact writes a project-local continuity handoff and cumulative rollup;
• PostCompact creates a restore sentinel;
• PreToolUse blocks normal tool use until the resumed agent reads the required continuity files;
• PostToolUse records those reads and clears the sentinel when restoration is complete.

For the AGENTS/progress-state problem in this issue, I would call this only a partial workaround. It does not make Codex's native AGENTS/rules handling reliable, and it does not make progress percentages objectively correct. What it can do is externalize some operational state and force a post-compact reread before the agent continues, which reduces the chance that the resumed model silently proceeds from a vague summary.

This is also very much tied to the current Codex hook behavior. If Codex later adds native task-state preservation, context pins, a structured operational tail, or better compaction semantics, this kind of user-space hook may become unnecessary.

One safety note: the generated .codex-compact-continuity/ files may include task/session context and command summaries, so they should normally be treated as local state and ignored by Git.

I had an issue like this a few minutes ago. Hosting assets outside of a git repository. Codex knew the project relied upon them. In my AGENTS.md I explicitly state to never commit assets and NEVER use git add -f. The folder is even in my .gitignore.

I have a build and publish pipeline that allows me to publish assets from my repo and, likewise, download them. So I can test assets at runtime, and then publish when I am happy with them/redownload. Not tracked in git; they are MP3s and large images.

And yet, what happened post-compaction on a long running task where new images and sprites were added during the course of the work?
Of course, it figured "hey, the app needs them, so I will directly commit the files. Oh no, I can't, I should git add -f them". Because it lost the context in AGENTS.md of "assets live in another cloud storage and we have a fully complete pipeline which downloads them during build".

Thankfully it's not a _major_ issue as permissions guardrails exist meaning I have to approve commands, but it is still irritating seeing the agent try and do things it is explicitly told not to do and having to re-steer it - making it very clear that AGENTS.md is lost and not included post-compaction.

The overall issue is - post-compaction, agents lose important behavioural information. There is no way this is intentional.

Full disclosure: I maintain Data Olympus, a git-native governance knowledge base plus MCP server for coding agents: https://github.com/knaisoma/data-olympus

This issue is very close to the failure mode we built it around. The part that seems easy to lose in compaction is not ordinary transcript history. It is the small set of governing facts the agent is expected to keep treating as authoritative: project rules, accepted decisions, superseded decisions, current task constraints, and patterns the team has already standardized.

The implementation choice that has helped us is to move those facts out of the chat transcript entirely and serve them as a queryable governance layer:

• each rule/decision has a stable id, not just a file path;
• lifecycle is explicit via status, tier, type, supersedes, and superseded_by;
• the read path can ask for only currently in-force guidance, so deprecated or superseded rules do not quietly reappear after compaction;
• agent writes go through a proposed/pending path instead of silently becoming durable memory;
• the bundle is markdown in git, so humans can review exactly what became authoritative.

That distinction matters because preserving context is not enough. A resumed or compacted session needs to know which recovered facts are still allowed to govern behavior. In our usage, this means AGENTS-style instructions and project decisions are not treated as just more summarizable text. They are loaded from a governed source of truth when the agent needs to make a decision.

For Codex specifically, I think the product-level shape could be something like a first-class external "governance/context provider" separate from transcript compaction: compact the conversation aggressively, but reload governing rules and accepted project decisions by stable id and lifecycle status after compaction. That would also make it visible when the post-compaction session is missing required anchors instead of continuing from a degraded reconstruction.