Context auto-compaction loop repeatedly rereads files, loses progress, and consumes paid Codex credits

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

• #34322
• #34095
• #35032

Powered by Codex Action

Diagnostic update from the affected session

I recovered the missing session and environment details:

• Primary Codex /feedback Session ID: 019f5be9-903c-7fd0-a8c9-5014bccc05b8
• Codex version: 26.721.31836
• Release date shown in the app: July 23, 2026
• Model/mode shown: GPT-5.6 Sol, Medium reasoning
• Computer: MacBook Pro with 16 GB memory
• Context state at the time of capture: 93% full
• Tokens shown: 240k / 258k tokens used
• Estimated paid usage consumed by the defective loop: approximately 10%–15%

The app had been working normally before this incident. The high usage was not caused by productive implementation work. It came from repeated automatic compaction, rereading the same files, reloading the same project instructions, and restating the same plan without completing the requested code change.

The screenshot from the affected chat confirms the 93% context state and 240k / 258k token count. I can provide the image through a secure diagnostic channel if needed.

Please use the session ID above to inspect the compaction sequence and usage records. I am requesting that the team:

1. identify the repeated compaction/re-analysis loop in this session;
2. determine the paid usage attributable to that defective behavior; and
3. restore the approximately 10%–15% of usage/credits consumed by the loop.

Duplicate review and reasoning-setting clarification

I reviewed the three potential duplicates flagged by GitHub Actions: #34322, #34095, and #35032.

This report appears related to the same broad context-compaction failure, but it adds a separate affected session with useful comparison data:

• Codex Desktop version 26.721.31836
• MacBook Pro with 16 GB memory
• GPT-5.6 Sol
• 93% context usage (240k / 258k tokens)
• linked /feedback Session ID 019f5be9-903c-7fd0-a8c9-5014bccc05b8
• estimated 10%–15% of paid ChatGPT Pro usage consumed during the non-productive loop

One correction and added detail about the model configuration: this long-running project thread was used with GPT-5.6 Sol at Extra High reasoning first, then High, and later Medium. The screenshot showing 93% context usage was captured after the setting had been reduced to Medium. The report therefore should not be read as a Medium-only configuration.

Please keep or link this issue as a separate affected session for diagnostic comparison unless a maintainer selects a canonical issue. I am willing to consolidate it after the session ID, newer app build, macOS environment, reasoning-setting sequence, and paid-usage impact have been recorded against the main investigation.

A measured mechanism that would produce this loop

(Edited — my first version said truncation was silent and that a capped read fills the context window. Both were wrong. Corrected below, with the measurements that replace them. The corrected version is a narrower and I think more useful finding.)

I've been auditing tool-output truncation in a different environment (large private repo, Codex sessions over three days).

Truncation is marked, but the two paths mark it differently, and one of them buries the notice mid-payload.

| path | marker | offset |
|---|---|---|
| exec / custom_tool_call_output | Warning: truncated output (original token count: N) | 47 — at the head |
| small shell_command presentation truncation | same warning form | 704 — near the head |
| large-cap shell_command / function_call_output | …252144 tokens truncated… | 20,044 — mid-payload |

The large-cap path delivers a head + notice + tail elision: about 20k characters of the beginning, the notice, then about 20k of the end, for a total delivered payload of 40,069 characters. The response reads as complete at both ends, and the only evidence of loss sits in the middle — where a model scanning for the content it requested is least likely to weight it. The exec path puts its notice at character 47, where it cannot be missed.

Worked example, verbatim from the logs:

• record type function_call_output, tool shell_command
• delivered logical text: 40,069 characters / 40,073 UTF-8 bytes
• Warning: truncated output present: no
• inline marker present: …252144 tokens truncated… at offset 20,044
• that marker reports the estimated dropped count, not the original total

Frequency. Across three days: 7,070 tool outputs, 84 truncated (1.19%). Of 4,841 shell_command / function_call_output records, 9 hit the large cap; none of those nine carried the Warning: truncated output form, while it does appear once on a smaller 10,024-original-token presentation truncation on the same record type.

Split by call type:

| call type | truncations | approx. tokens dropped | largest single drop |
|---|---:|---:|---:|
| shell_command | 38 | ~1,370,000 | 252,144 |
| exec | 37 | ~58,000 | 12,375 |
| wait | 8 | ~19,000 | 7,019 |
| issue-comment fetch | 1 | 2,134 | — |

Every drop above 80,000 characters was an ordinary shell_command, not a batched exec — worth noting since the thread on #35050 has been discussing truncation as a batching side-effect. In this sample roughly 96% of dropped content came from non-batched calls, which points to a general output limit affecting both arms rather than something batching introduces.

Correcting my own arithmetic. I previously argued that a capped read delivers ~252k tokens and fills ~98% of a 258k context window. That is wrong. Delivered payloads on the cap path are about 40k characters — considerably less than a normal large read, not more. So a capped read does not fill the window. If a reread loop like the one reported here is driven by truncation, the driver would be the missing middle of a response that looks complete, prompting a reread of the same file, rather than context pressure.

That is consistent with creativeImageService.ts appearing three times consecutively in the log above, but I want to be clear it is now a hypothesis about why a reread happens, not a claim about context filling.

Workaround that stopped the reread loop in my environment: bound every read explicitly. No unfiltered cat / Get-Content or broad grep / rg over large files or trees; target an exact line range or a small head/tail window; keep expected output well under 50,000 characters per call and make several bounded calls instead of one large one; and treat uncertain completeness as incomplete rather than inferring from an apparent end of data.

Suggested fix, narrower than my first version: make the two paths consistent and move the cap notice to the head of the payload, in the same form as Warning: truncated output, including the original token count rather than only the dropped count. The information already exists — it is simply placed where it competes with content instead of where it governs interpretation.

Follow-up: I traced this to source and filed it separately as #35421.

Short version, and it corrects my comment above again — the loss is two-stage. The shell capture path retains only the first 1 MiB and discards the rest without counting it, before any model-facing formatting. The mid-payload …252144 tokens truncated… notice describes only the second stage, and that number is a constant: (1,048,576 − 40,000) / 4. It appears identically whether the command produced 1.1 MB or 900 MB.

So a broad read here returns a response that begins and ends normally, reports a fixed figure for what it dropped, and says nothing at all about the first-stage loss.

On whether that contributes to the reread loop in this thread — measured, and not supported. Across 9 cap-path truncations versus 9 matched non-truncated shell reads (matched on command shape, explicit-target count, boundedness, and delivered size), a same-target reread within the following 10 tool calls occurred 4/9 for truncated reads against a 5/9 baseline. Small sample, but within the exact rule I could measure, truncation does not raise the reread rate.

I am therefore retiring the loop mechanism I proposed for this thread. The correctness defect in #35421 stands on its own and does not depend on it.

I am experiencing the same issue described in this report.

Environment

• Product: Codex desktop application for Windows
• Installation source: Microsoft Store
• Operating system: Windows 10 x64
• Subscription: ChatGPT Plus
• Model: GPT-5.6 Sol
• Reasoning mode: Ultra
• Subagents: Enabled
• Dates observed: July 28–29, 2026

Observed behavior

During a software-development task, Codex repeatedly made substantial progress in the correct direction.

Based on the executed commands, code changes, build output, test activity, and the agent’s own status messages, the main agent and its subagents repeatedly reached the final stages of the task. The application had already been built, post-build checks were being performed, and Codex appeared ready to prepare the final report.

However, after automatic context compaction, Codex repeatedly lost or failed to preserve its current execution checkpoint.

It then:

• returned to earlier stages of the task;
• reread files that had already been analyzed;
• reran commands that had already been completed;
• reopened implementation questions that had already been resolved;
• repeated work already performed by the main agent and its subagents;
• behaved as though completed changes still needed to be implemented;
• failed to produce a stable final result.

The session repeatedly entered the following loop:

progress toward completion → automatic context compaction → loss of task state → repetition of completed work → another context compaction

This continued for approximately two hours.

The task was never completed, despite Codex reaching the build, post-build verification, or final-report stage several times.

Usage impact

Before the affected execution, my included weekly Codex usage allowance was approximately 100%.

After approximately two hours of repeated execution, the available weekly 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 a substantial amount of usage was consumed by repeated work after context-compaction events, rather than by meaningful continued progress toward completion.

Regression

This appears to be a regression.

In previous Codex sessions, context compaction also occurred during long-running tasks, but it happened less frequently and did not normally cause this degree of task-state loss.

Earlier sessions generally continued from the existing progress and reached a logical completion. In the current version, compaction appears capable of returning the agent to a much earlier execution state and causing a non-terminating repetition loop.

Expected behavior

After automatic context compaction, Codex should preserve and restore at least:

• the current task phase;
• completed work;
• remaining work;
• files already inspected;
• files already modified;
• commands and tests already executed;
• build and test results;
• implementation decisions already made;
• rejected approaches that should not be reconsidered;
• relevant results returned by subagents;
• the exact next action;
• the task completion condition.

Codex should continue from the latest valid checkpoint instead of restarting earlier phases of the task.

The runtime should also detect repeated post-compaction behavior, such as rereading the same files, rerunning the same commands, and reopening the same investigation.

Reporting status

I have already submitted the affected conversation through the built-in Codex feedback function.

I have also contacted OpenAI Support regarding the account-level consequences and the weekly allowance consumed during the failed execution.

Please treat this comment as an additional independent reproduction affecting:

• Windows 10 x64;
• the Microsoft Store desktop application;
• ChatGPT Plus;
• GPT-5.6 Sol;
• Ultra reasoning mode;
• subagent-based execution.

The defect makes long-running Codex tasks effectively non-terminating and can consume an entire weekly usage allowance without delivering the requested result.

Another affected Codex Desktop user here. I am seeing the same failure pattern today (2026-08-24) with GPT-5.6 Sol: the agent runs a few reads/commands, shows Context automatically compacted, resumes by re-reading/re-analyzing the same project state, then compacts again. This repeats in a loop instead of converging on the task.

The user impact is severe: a substantial amount of paid Codex usage/allowance was consumed by repeated compaction and repeated work with little useful progress. This is not simply a long-context inconvenience; the product can effectively burn paid usage while trapped in an internal recovery loop.

Please treat loop detection and usage protection as part of the bug fix. If the same files/plans are repeated across multiple compactions without meaningful working-tree progress, Codex should stop automatically rather than continue consuming allowance. Please also investigate whether usage consumed by confirmed compaction-loop incidents can be restored/credited.

I have screenshots of the repeated compaction/re-analysis sequence from the affected session, but I am not posting potentially sensitive project details publicly unless maintainers request a safe diagnostic path.