I’m implementing a Goal that requires my approval upon completion of each stage before proceeding.
However, today I discovered that context compression is causing Codex to attribute previous approval errors to the task currently requiring approval.
As you can see from the screenshot, I didn’t reply between the two contexts; there was only one context compression.
After context compression, it attributed the error of the previous task’s approval request to this task, thus skipping the current approval and continuing the task.
This was a huge mistake .
EricGT
July 30, 2026, 10:31am
2
Welcome to the forum!
You are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for OpenAI Codex .
I asked ChatGPT to identify the closest related issue and, if that issue was closed, the closest related issue that remains open:
opened 02:17AM - 28 Apr 26 UTC
closed 04:51PM - 11 May 26 UTC
bug
context
@etraut-openai first off, incredible work on the new goals feature. This fixed t… he most painful part of using Codex: having the model sandbag its work and not actually complete what you want fully. This is genuinely life changing stuff.
There is quite a persistent issue with it, however. That issue is that after compaction, the goal is sometimes not carried through cleanly to the new agent.
I have been using the goals feature extensively over the past few days, and none of the times I have ran it on ambitious work has the work been completed, and that is due to one specific reason: compaction.
Often, the compaction message does not carry the goal task through cleanly, and more specifically it often does not carry through cleanly the most important "perform a completion audit against the actual current state" requirement of the goal prompt.
This leaves a concrete failure mode: the agent is busy finishing up a local task of its own -- for example running tests and verifying its changes. Compaction happens in the model of this finishing up process, and the compaction message conveys to the agent with fresh context that this specific task is almost done, the previous agent was just verifying their changes, continue with the verification and subsequent completion. This new agent then proceeds to perform the verification process, and after it is done mark the goal as complete because it was only fed that the local task and not the global goal and the audit requirements of it (the bigger picture).
I have found this to be the root cause of the agent prematurely stopping:
- After compaction in these circumstances, the new agent often sends a message to the commentary channel before running any tools like "Let me finish running tests so I can wrap this goal up". The agent then runs the tests, looks at the `git status` and a few modified files, and that evidence is enough to satisfy its confirmation bias to mark the goal as complete. This is a red flag as it shows the agent has treated completion of the goal as a foregone conclusion, then interpreted circumstantial evidence as confirmation.
- I have reverse engineered the opaque compaction message in these scenarios, and it clearly does not convey the completion audit requirement of the goals prompt effectively, if at all.
I have implemented a fix locally for this where the active goal continuation prompt is now reattached during mid-turn compaction for both local and remote compaction paths, using the persisted active goal and only when the current turn is the synthetic goal-continuation turn. Manual/pre-turn compaction stays unchanged to avoid duplicate prompts.
I have ran many ambitious, long-horizon tasks after this change and the rate of premature closure has dropped significantly due to these changes eliminating the primary failure mode.
This is the correct solution as:
- The continuation prompt without the `{{ objective }}` placeholder is 462 tokens (via `o200k_base`). Add a relatively average user goal prompt and that is likely 500-1000 tokens. This is a perfectly acceptable amount of tokens to inject after compaction.
- This keeps the persisted goal table as the source of truth and avoids depending on the compacted summary to remember the active objective.
- The orthogonal-to-this-solution way to fix this failure mode is essentially adding a tool to retrieve the goal prompt for the new agent to call, which is the wrong fix as if the agent already has the goal in their context, this tool is practically useless. The only scenario the agent will not have the goal in its context is compaction, which makes the correct fix injecting the goal directly after the only time the model may lose it.
An alternative acceptable solution is making and injecting after compaction a brand new compaction-centered message with the goal. This is still not the optimal fix in my opinion as the current continuation prompt is short and is already in the optimal shape for a post-compaction injection ("Continue working toward the active thread goal."), and this would just be reinventing a prompt to achieve the exact same outcome as the current continuation prompt.
I have a small local patch of roughly 193 lines for this and would be happy to open a PR or discuss the approach further, since I understand goals is a WIP and likely still evolving.
opened 07:19AM - 02 Jun 26 UTC
bug
model-behavior
context
app
### Codex app version
`26.527.60818 (3437)`
### Platform
- macOS Tahoe `26.5`…
- Apple Silicon MacBook Pro
- Pro plan
### Related feedback ID
```text
019e8703-d740-74e0-91ca-ece6a548c2a3
```
### Summary
I am reporting a serious long-task reliability issue in Codex: after **context automatically compacted**, Codex can appear to lose important project/task memory, including instructions from AGENTS/custom rules.
In my project rules, Codex is required to report task progress in real time during long tasks, including percentage progress and a short explanation of the current phase, completed work, remaining work, and blockers. However, in long-running tasks I frequently see Codex behave inconsistently after context compaction.
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.
### Observed behavior
During a long Codex task:
- Codex follows the project/AGENTS rules before compaction.
- The conversation is automatically compacted.
- After compaction, Codex may lose important context about the current task state.
- Progress percentage can drop sharply, for example from about **97%** back to about **42%**.
- The task may repeat previously completed reasoning or re-open work that was already near completion.
- The AGENTS/custom instruction requirement for progress tracking may no longer be applied consistently.
### Expected behavior
Context compaction should preserve all important execution state needed to continue a long Codex task safely and consistently, especially:
- AGENTS.md / project rules / custom instructions.
- The current task goal and acceptance criteria.
- Completed work and remaining work.
- Current checklist/TODO state.
- Progress-reporting requirements.
- Previously made decisions and current blockers.
After compaction, Codex should continue from the same task state. It should not behave as if the task has gone backwards or partially restarted.
### Actual behavior
After context compaction, Codex can lose important context and produce a much lower progress estimate than before. This makes the long-task workflow unreliable because the user cannot trust whether Codex is continuing correctly, repeating old work, or forgetting earlier instructions.
### Why this matters
Long Codex tasks often depend on accumulated context: project rules, repository-specific requirements, safety constraints, TODO state, implementation decisions, and verification progress. If context compaction loses or weakens that memory, Codex may waste time/tokens, redo work, make inconsistent decisions, or violate project instructions.
This issue has been present since the GPT-5.5 era began and still does not seem well optimized. Please prioritize improving context compaction so that critical project rules and task state are retained reliably across compaction boundaries.
### Request
Please investigate and improve how Codex compresses and restores long-task context. In particular, compaction should explicitly preserve:
- project rules and AGENTS/custom instructions,
- live TODO/checklist state,
- progress percentage assumptions and rationale,
- current task phase,
- completed vs remaining work,
- validation/verification requirements.
Codex should also avoid reporting a sharply reduced progress percentage after compaction unless there is a clear, evidence-based reason and it explains why the earlier estimate was wrong.
<img width="2048" height="1610" alt="Image" src="https://github.com/user-attachments/assets/832d6515-f024-471d-b027-67a320a9aad5" />
<img width="1528" height="596" alt="Image" src="https://github.com/user-attachments/assets/b7ea5998-174b-470a-a75f-5d1a07795775" />
If any issue matches your problem, consider adding a
If the issues are not a match, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible.
Compaction-related problems have been ongoing, as shown by the many related issues that have been reported.
Your concern is one I share as well.
Thank you for your reply. I have provided a new issue on GitHub.
reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.