[Windows][Regression] Context compaction loses task state, repeats completed work, and exhausts weekly usage

What version of the Codex App are you using (From “About Codex” dialog)?

26.721.41059

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Codex repeatedly loses or fails to restore the active execution state of a long-running software-development task after automatic context compaction.

I was using GPT-5.6 Sol in Ultra reasoning mode with subagents enabled. During execution, the main agent and its subagents made substantial and observable progress toward completing the task. Codex inspected the relevant source files, modified the code, built the application, ran verification steps, and repeatedly reached what appeared to be the post-build testing or final-reporting stage.

However, after automatic context compaction, the agent began behaving as though a significant part of the completed work and current task state was no longer available.

It returned to earlier stages of the task, reread files that had already been analyzed, reran commands that had already completed, reopened implementation questions that had already been resolved, and repeated work previously performed by the main agent or its subagents.

The session repeatedly entered the following loop:

substantial progress → near completion → automatic context compaction → loss of active task state → repetition of completed work → another context compaction

The agent sometimes reformulated its reasoning differently, but functionally returned to the same earlier work instead of continuing from the latest valid checkpoint.

This continued for approximately two hours. The task was never completed, despite Codex reaching the build, post-build verification, or final-reporting stage several times.

Before the affected execution, my included weekly Codex usage allowance was approximately 100%. After the repeated execution loop, the allowance had decreased to 0%, while the requested task remained unfinished.

This is not a complaint about the normal usage cost of GPT-5.6 Sol, Ultra reasoning, or subagents. I deliberately selected this configuration and understood that it would consume more usage.

The issue is that the allowance was consumed by repeated work following context-compaction events rather than by continued progress toward completion.

What steps can reproduce the bug?

Open an existing local software project in Codex Desktop on Windows 10 x64.
Select GPT-5.6 Sol.
Select Ultra reasoning mode.
Allow Codex to use subagents.
Submit a multi-stage software-development task that requires:
- repository analysis;
- modification of existing source files;
- coordination between the main agent and subagents;
- building the application;
- post-build testing or verification;
- production of a final completion report.
Allow Codex and its subagents to work until substantial progress has been made.
Observe that Codex:
- identifies the relevant files;
- performs implementation work;
- modifies the code;
- builds the application;
- runs tests or post-build checks;
- approaches the final reporting stage.
Wait for an automatic context-compaction event.
Continue observing the agent after compaction.
Instead of continuing from the latest valid execution checkpoint, Codex begins repeating earlier work. Typical behavior includes:
- rereading files that were already inspected;
- rerunning repository searches;
- repeating diagnostic commands;
- reconsidering implementation decisions already made;
- reopening resolved problems;
- repeating work completed by subagents;
- returning from post-build verification to earlier repository analysis.
Allow the session to continue.
The repeated work consumes more context and causes another automatic context-compaction event.
After the next compaction, Codex again returns to earlier work instead of completing the task.
The cycle continues without a stable final result.

The problem reproduced repeatedly during attempts made on July 28–29, 2026.

Approximate execution pattern:

analysis → implementation → build → verification → near completion → context compaction → task-state regression → repeated analysis and implementation → another compaction

Observed usage impact:

Weekly allowance before the affected execution: approximately 100%.
Weekly allowance after approximately two hours: 0%.
Final task result: not delivered.
Exact token and context-window counters were not exposed in the desktop user interface.
The application displayed automatic context-compaction events during the affected execution.

The affected conversation was also submitted directly through the built-in Codex feedback function. The feedback interface did not display a session ID to me.

What is the expected behavior?

Automatic context compaction should preserve a structured and reliable continuation checkpoint.

After compaction, Codex should continue from the latest valid execution state instead of reconstructing the task from an incomplete general summary or returning to an earlier phase.

At minimum, the preserved state should include:

the exact current user request;
the task acceptance criteria;
the current execution phase;
work already completed;
work still remaining;
files already inspected;
files already modified;
commands already executed;
results of completed commands;
build results;
test and verification results;
implementation decisions already made;
issues already resolved;
known unresolved issues;
approaches already rejected;
relevant findings returned by subagents;
changes already completed by subagents;
the exact next action;
the explicit task-completion condition.

After context restoration, Codex should verify the current repository state and continue from the latest valid checkpoint.

It should not silently return to initial repository analysis, reopen resolved questions, or repeat completed commands and implementation work.

The runtime should also detect likely repetition loops, including:

repeated reading of the same files without a new reason;
repeated execution of the same searches or diagnostic commands;
repeated reconsideration of the same resolved issue;
repeated assignment of substantially identical work to subagents;
repeated builds without intervening code changes;
returning from final verification to initial analysis;
repeatedly approaching completion without producing the final response.

When reliable continuation is no longer possible, Codex should stop and explicitly report that state instead of indefinitely consuming the user’s limited usage allowance.

Additional information

Environment

Product: Codex Desktop for Windows
Installation source: Microsoft Store
Application version: 26.721.41059
Operating system: Windows 10 x64
Subscription: ChatGPT Plus
Model: GPT-5.6 Sol
Reasoning mode: Ultra
Subagents: Enabled
Dates observed: July 28–29, 2026
Time zone: Europe/Kyiv, UTC+3

Severity and impact

Severity: High

The issue caused:

failure to complete an otherwise finite software-development task;
repeated loss or weakening of the current execution state;
repetition of already completed work;
apparent loss or weakening of subagent findings;
repeated execution of commands and repository analysis;
exhaustion of the entire included weekly Codex usage allowance;
loss of approximately two hours of execution time;
inability to continue using the selected Codex configuration;
no completed final result.

This was not simply an incorrect answer or an unsuccessful implementation attempt.

The agent repeatedly reached the build, post-build verification, or final-reporting stage and then regressed after context compaction.

Regression information

This appears to be a regression.

I previously used Codex for comparable long-running software-development tasks. Automatic context compaction also occurred in earlier sessions, but it appeared less frequently and did not normally cause this degree of task-state regression.

Earlier sessions generally continued toward a logical completion after compaction. In the current behavior, compaction can cause the agent to return to substantially earlier stages and enter a non-terminating repetition loop.

Subagent-specific concern

Subagents were enabled during the affected execution.

Some work was completed or investigated by subagents, but after context compaction the parent agent sometimes behaved as though those findings or completed actions were no longer available.

Please investigate whether:

subagent outputs are fully retained across parent-context compaction;
completed subagent tasks remain marked as completed;
the parent agent can distinguish completed subagent work from pending work;
repository changes and conclusions produced by subagents survive compaction;
repeated compaction progressively weakens or removes subagent results.

Possible affected components

The exact root cause cannot be determined from the user interface.

The behavior appears correlated with automatic context compaction and may involve:

preservation of the active execution checkpoint;
restoration of the current task phase;
retention of completed and remaining work;
retention of subagent results;
synchronization between repository state and compacted conversation state;
loss of command, build, or test results;
repeated compaction of already compacted summaries;
loss of the latest task-completion condition;
absence of repetition-loop detection.

These are suspected affected areas, not confirmed root causes.

Requested investigation

Please investigate:

Whether automatic context compaction preserves the latest active execution checkpoint.
Whether the current task phase remains explicitly available after compaction.
Whether completed work remains marked as completed.
Whether command, build, and test results survive compaction.
Whether subagent results remain available to the parent agent.
Whether repeated compaction progressively removes important task state.
Whether the restored state is synchronized with the actual repository state.
Whether Codex can detect repeated post-compaction behavior.
Whether the runtime can prevent non-terminating execution loops.
Whether usage consumed during confirmed repetition loops can be identified in telemetry.

Reporting status

The affected conversation has already been submitted through the built-in Codex feedback function.

OpenAI Support has also been contacted regarding the account-level impact and the weekly allowance consumed during the failed execution.

Possible related reports include:

This report documents an independent reproduction involving Windows 10 x64, the Microsoft Store desktop application, ChatGPT Plus, GPT-5.6 Sol, Ultra reasoning mode, subagents, and complete exhaustion of the included weekly allowance.

Requested resolution

A complete resolution should include:

reliable preservation of structured task state before compaction;
restoration from the latest valid checkpoint;
retention of completed and remaining work;
retention of relevant subagent results;
synchronization with the actual repository and build state;
detection and prevention of repeated post-compaction execution;
a safe stop condition when reliable continuation is impossible;
protection against exhausting the user’s allowance through repeated completed work.

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

Context auto-compaction loop repeatedly rereads files, loses progress, and consumes paid Codex credits #35226
Codex Desktop auto-compaction completes but leaves long-running thread ~80% full, causing repeat compaction and usage waste #35032

Powered by Codex Action

This looks like a checkpoint-integrity failure rather than ordinary model drift. A useful regression test would persist the current phase, completed actions, modified files, verification outputs, and exact next action before compaction, then assert that the restored session does not repeat prior commands or reopen resolved decisions. A repeated-work detector should stop the run once the same phase or command sequence recurs without new repository state.

I have an independent metric-level reproduction that matches this issue and shows a mid-turn operational-state loss even though compaction reclaimed ample headroom.

Environment

Codex Desktop for Windows: 26.803.5235.0
Model: GPT-5.6 Sol, High reasoning
Model context window: 258,400 tokens
Automatic compaction occurred in the middle of one still-active turn
Reproduced on 2026-08-10

Observed sequence

The agent began a bounded investigation, read official documentation, queried related GitHub issues and comments, and published intermediate findings.
Immediately before compaction, the last model request used 236,838 / 258,400 input tokens.
The active turn contained approximately 413,695 characters of model-facing tool outputs, plus the tool calls and visible assistant progress messages.
Codex generated a 5,050-character preservation summary.
Fourteen milliseconds later, compaction replaced the model-visible history.
The compacted record contained a 5,450-character message: a 400-character service preface followed by that preservation summary verbatim.
Its replacement_history contained 19 items:
- 16 user messages
- 3 developer messages
- 0 assistant messages
- 0 tool calls
- 0 tool outputs
- 0 reasoning items
The full audit trail, including the omitted tool results, remained present in the rollout JSONL, but those items were not present in the replacement history supplied to the continuing model.
After compaction, the context dropped to approximately 20,370 tokens; the first continuation request used 21,254 input tokens.
Despite this large amount of free headroom, 6.4 seconds after compaction the agent announced the same investigation again, reread its official-documentation instructions, and repeated documentation and GitHub queries it had already completed.

The active turn had added roughly 65,500 input tokens before compaction. Replaying its operational tail after compaction would therefore have produced a prompt of roughly 86,000 tokens in this case, still far below the 258,400-token window.

This appears distinct from a compaction that simply fails to reclaim enough space. The compaction reclaimed substantial space, but the immediate continuation lost the completed action sequence and restarted work that the preserved summary already described.

I understand from #14589 that dropping raw tool outputs and assistant reasoning was previously classified as working as intended. Could a maintainer clarify the intended behavior for this narrower failure mode?

Is a mid-turn continuation expected to rely solely on the compacted summary even when all current-turn assistant/tool items are removed?
Is preserving a bounded or complete current-turn operational tail being considered?
Are PreCompact plus SessionStart(source="compact") intended as the supported mitigation for this case, or only as general extension points?
Is there another tracking issue or planned fix for repeated work after mid-turn compaction?

I am not attaching the raw rollout or a screenshot because they contain unrelated private task context, but I can provide additional redacted structural metrics if useful.

I have an independent metric-level reproduction that matches this issue and shows a mid-turn operational-state loss even though compaction reclaimed ample headroom.

Environment

Codex Desktop for Windows: 26.803.5235.0

Model: GPT-5.6 Sol, High reasoning

Model context window: 258,400 tokens

Automatic compaction occurred in the middle of one still-active turn

Reproduced on 2026-08-10

Observed sequence

The agent began a bounded investigation, read official documentation, queried related GitHub issues and comments, and published intermediate findings.

Immediately before compaction, the last model request used 236,838 / 258,400 input tokens.

The active turn contained approximately 413,695 characters of model-facing tool outputs, plus the tool calls and visible assistant progress messages.

Codex generated a 5,050-character preservation summary.

Fourteen milliseconds later, compaction replaced the model-visible history.

The compacted record contained a 5,450-character message: a 400-character service preface followed by that preservation summary verbatim.

Its replacement_history contained 19 items:

16 user messages

3 developer messages

0 assistant messages

0 tool calls

0 tool outputs

0 reasoning items

The full audit trail, including the omitted tool results, remained present in the rollout JSONL, but those items were not present in the replacement history supplied to the continuing model.

After compaction, the context dropped to approximately 20,370 tokens; the first continuation request used 21,254 input tokens.

Despite this large amount of free headroom, 6.4 seconds after compaction the agent announced the same investigation again, reread its official-documentation instructions, and repeated documentation and GitHub queries it had already completed.

The active turn had added roughly 65,500 input tokens before compaction. Replaying its operational tail after compaction would therefore have produced a prompt of roughly 86,000 tokens in this case, still far below the 258,400-token window.

This appears distinct from a compaction that simply fails to reclaim enough space. The compaction reclaimed substantial space, but the immediate continuation lost the completed action sequence and restarted work that the preserved summary already described.

I understand from #14589 that dropping raw tool outputs and assistant reasoning was previously classified as working as intended. Could a maintainer clarify the intended behavior for this narrower failure mode?

Is a mid-turn continuation expected to rely solely on the compacted summary even when all current-turn assistant/tool items are removed?

Is preserving a bounded or complete current-turn operational tail being considered?

Are PreCompact plus SessionStart(source="compact") intended as the supported mitigation for this case, or only as general extension points?

Is there another tracking issue or planned fix for repeated work after mid-turn compaction?

I am not attaching the raw rollout or a screenshot because they contain unrelated private task context, but I can provide additional redacted structural metrics if useful.

Thanks for documenting this in such detail. This matches the failure mode I observed very closely.

In my case, the problem also wasn't simply that compaction failed to reclaim enough context. Codex would compact successfully and continue the same active task, but then fall back to an earlier execution state and repeat work that had already been completed.

Your finding that the replacement history contained none of the assistant or tool execution trail, even though the continuation still had plenty of context headroom, seems especially relevant to what I observed.

It makes the difference between normal compaction and losing the current operational checkpoint much clearer.

I'd also be interested in a maintainer clarifying whether preserving some bounded part of the current-turn operational history is expected or planned, since that seems directly related to the repeated-work behavior reported here.

Thanks again for the independent reproduction.

This overlaps with #36584 at the checkpoint/handoff level, but the failure documented here is more specific: automatic compaction can restore an earlier task state and repeat completed work, consuming time and usage.

A handoff/checkpoint should therefore be available as a manual recovery path before or after compaction, not only as a warning. It should persist the exact next action, completed and pending work, modified files, Git/worktree identity and dirty state, build/test results, artifacts, subagent findings, and unresolved blockers, then create a successor task while leaving the original intact for audit.

A useful regression test would assert that a resumed task does not repeat commands or reopen resolved decisions when repository state has not changed.

I’m exploring how people preserve state across long coding-agent sessions.

In your case, what is the one artifact you wish had persisted before compaction — decisions, next steps, verification state, or something else?

I’m trying to understand the failure mode properly.

@iliaschatt1993-code

@iliaschatt1993-code Thanks for asking. The most important missing artifact was not another prose summary, but a structured execution checkpoint.

It should preserve:

the exact objective and acceptance criteria;
the current execution phase;
completed and pending work;
the exact next action;
decisions made and approaches already rejected;
files changed and repository/worktree identity;
Git HEAD and dirty state;
build, test, and verification results;
relevant artifacts and subagent findings;
unresolved blockers.

If I had to choose the single most important field, it would be the exact next action together with the completed-versus-pending verification state.

In my case, Codex had reached build/verification and then, after compaction, behaved as if it had returned to an earlier phase. It reread files, repeated commands, and reconsidered resolved decisions. The failure was therefore loss of operational state, not merely loss of conversational context.

A HANDOFF.md-style artifact would be useful as a human-readable projection, but the runtime should also preserve machine-readable state so the next continuation can resume from the exact next action rather than reconstructing the task from a general summary.

@barcuchj

Nothing here needs a code change. The artifact @barcuchj described (the exact next action plus verification state) can be produced on current builds with one file and a write rule. The measurement from @post1917a above is why it has to be a file: after compaction the continuation receives the summary plus user and developer messages, with zero assistant turns, tool calls, or tool outputs carried over. It is reasoning about work it can no longer inspect, so it re-derives the task instead of continuing it.

RUN.md at the repo root, one per task:

# RUN.md
TASK: <objective> | ACCEPT: <how completion is judged>
PHASE: integration-testing
HEAD: 4f2c9a1 (re-verify: git rev-parse HEAD)
DONE:
- [x] 7. adapter implemented | receipt: commit 4f2c9a1
- [x] 8. unit suite green | receipt: .codex/logs/unit-08.txt (41 passed)
NEXT: run the integration suite for the retry path, then update REPORT.md section 3
REJECTED: Cedar adapter (duplicates webhooks on retry), see decisions.md#cedar
BLOCKED: none

Rules that make it hold:

Append after every completed step, before starting the next one. Compaction fires mid-turn, so anything deferred to the end of the session can be lost before it is written.
No entry without a receipt: commit sha, log file, artifact path. If the artifact does not exist, the item stays pending. This is what lets a resume check work instead of remembering it.
First action after any compaction or resume: read RUN.md, take the NEXT line, then reconcile the repo against the HEAD line (git rev-parse HEAD, git status --porcelain). On a mismatch, fix the ledger before any other work.
Keep entries to one line each. Depth lives in the receipt files.

Put rule 3 in AGENTS.md so it covers every task, and repeat it in the task prompt for any run already in flight: Codex builds the instruction chain once per run, so an AGENTS.md edit does not reach a live session (developers.openai.com/codex/guides/agents-md).

For subagent work, have each subagent write its receipts under the same run directory before returning, and reference them from the main DONE list. Subagent tool output disappears at the boundary; the files do not.

Try it on the next long task: put a unique token in NEXT, trigger compaction mid-run (/compact), and confirm the continuation resumes from the token without re-reading old files. If a continuation ever runs the same command twice with no new artifact between the runs, stop it and reconcile from RUN.md.

@samvallad33

@samvallad33 Yes — I think persisting task state outside the compacted conversation and reloading/reconciling it after compaction is the right architectural direction.

The important distinction is between a conversation summary and execution state. A summary can say that implementation and testing were performed, but that is not enough to reliably determine what actually completed, what remains pending, what the exact next action is, which commands/tests produced verified results, or what subagents already established.

@John-Rood's RUN.md proposal is a useful workaround on current builds because it moves some of that state outside the compacted history. I would use something similar for long-running tasks today. But I don't think it means the underlying issue requires no product change.

There is still a failure window if an action completes and compaction occurs before the model updates RUN.md. More generally, users should not need to implement their own checkpoint protocol in AGENTS.md to prevent an internal compaction mechanism from causing completed work to be repeated.

Ideally, Codex itself would maintain persistent machine-readable execution state outside the compactable conversation history, including at least:

current phase;
completed vs. pending work;
exact next action;
repository/worktree identity, HEAD and dirty state;
command/build/test results and receipts;
decisions and rejected approaches;
artifacts;
subagent results;
unresolved blockers.

After compaction, Codex could reload that checkpoint, reconcile it against the actual repository state, and continue from the recorded next action rather than reconstructing operational state from a prose summary.

The ordering matters too: an action should only become “completed” once its result/receipt and updated task state have been persisted. Otherwise the same race can simply move from the conversation summary into the checkpoint mechanism.

So I see RUN.md as a good user-space mitigation and potentially a useful model for the feature, while persistent runtime-managed execution state would address the underlying regression.

@barcuchj

@barcuchj The ordering point is the right place to tighten, and it exposes the gap in what I posted above: a journal written only after completion always loses whatever finished inside the window.

Write ahead of the action instead of behind it. Log the step as IN-FLIGHT with the exact command or target, then flip the line to DONE with the receipt once it lands. If compaction fires mid-step, the resume finds an in-flight line and reconciles that single item against the repo before anything else runs. Worst case shrinks from "completed work replayed" to "one line to verify".

And I agree it shouldn't stay a user-space protocol. Runtime-managed execution state that reloads and reconciles after compaction is the real fix; the file is the bridge for builds that don't have it yet.

@John-Rood

@John-Rood Agreed — IN-FLIGHT → receipt → DONE closes most of the race window and makes RUN.md a much stronger workaround.

I would still emphasize that this should remain a temporary bridge rather than the expected user-side solution, especially because the workaround itself consumes the user's usage. Reading and updating the journal, producing receipts, and reconciling state after compaction all require additional model/tool work.

That matters particularly for this issue because one of the reported consequences of the regression is wasted usage from replaying completed work. Users should not have to spend additional usage implementing and maintaining a checkpoint protocol to compensate for an internal compaction mechanism.

If execution-state persistence is runtime-managed, the bookkeeping can happen at the system boundary rather than being repeatedly performed by the model as part of the user's task. The user-space journal is a good mitigation until that exists, but its cost should not become part of the normal workflow.

“Nothing here needs a code change” is an extraordinary conclusion to draw from a workaround. If users have to keep an IN-FLIGHT journal so Codex can get through its own automatic compaction, what exactly has been fixed?

In my reproduction, compaction left ample context headroom, the continuing model received no assistant or tool trail, and Codex promptly repeated completed work. The repetition is the bug.

RUN.md may limit the damage, at the user’s expense in time and usage. It does not make the failure disappear. A workaround for lost execution state is evidence that execution state needs to survive compaction – not an argument for leaving the issue unfixed.

@post1917a

@post1917a Fair. "Nothing here needs a code change" overstated it. What I meant: nothing blocks a mitigation on current builds. The repetition is the bug and the fix belongs in the runtime, either carrying the current-turn tool trail across compaction or reloading a reconciled checkpoint at the boundary. The journal is only for runs in flight before that ships.

Navigation Menu

Repository navigation

[Windows][Regression] Context compaction loses task state, repeats completed work, and exhausts weekly usage #35935

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Severity and impact

Regression information

Subagent-specific concern

Possible affected components

Requested investigation

Reporting status

Requested resolution

Environment

Observed sequence

Environment

Observed sequence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows][Regression] Context compaction loses task state, repeats completed work, and exhausts weekly usage #35935

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Severity and impact

Regression information

Subagent-specific concern

Possible affected components

Requested investigation

Reporting status

Requested resolution

Activity

github-actions commented on Jul 29, 2026

Keesan12 commented on Jul 30, 2026

post1917a commented on Aug 10, 2026

Environment

Observed sequence

Lexoid2 commented on Aug 11, 2026

Environment

Observed sequence

barcuchj commented on Sep 3, 2026

iliaschatt1993-code commented on Sep 15, 2026

barcuchj commented on Sep 15, 2026

John-Rood commented on Sep 18, 2026

barcuchj commented on Sep 23, 2026

John-Rood commented on Sep 23, 2026

barcuchj commented on Sep 23, 2026

post1917a commented on Sep 23, 2026

John-Rood commented on Sep 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions