Context automatically compacted / [RUINS SESSIONS] - [ CRITICAL BUG]

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

• #29947
• #30194

Powered by Codex Action

i have de same issue

user-ARpTy5d0ZgjgKzFSwRc4h0wB

I would like my resets and usage back if possible; I was keeping them for 5.6 sol
This bug cost me a lot while providing 0 progress

You can verify it

I understand that this problem is affecting all users who have the Codex app and are experiencing the same issue.

It is a critical problem; they need to release a fix as soon as possible or roll back the changes, because it is currently impossible to work.

Helloooooooooooooooooooooo

This bug ruined my 1 month + session and I had to create a new one without any context.
Why no one talks about it, when can I receive my compensation

Mine is doing the same shit non stop. Used all of my 5 hour limits twice now.

Literally the first prompt in a new chat and it's compacting....

I am seeing the same compaction-loop failure on the current Windows release, with additional reproducible evidence.

Environment

• Windows 11
• ChatGPT/Codex application version: 26.727.6591.0
• The application reports that it is up to date.
• Local Git repository
• Repository-level .codex/config.toml: not present
• User-level %USERPROFILE%\.codex\config.toml: present, but contains none of:

• model_context_window
• model_auto_compact_token_limit
• model_auto_compact_token_limit_scope
• compact_prompt

The applicable model/platform compaction defaults were therefore being used.

Observed behavior

One implementation task entered a repeating cycle:

1. Context automatically compacts.
2. The agent announces that it is reconstructing or reconciling its working state.
3. It rereads the same central source files, tests, migration, and documentation.
4. It rediscovers decisions or gaps that had already been established.
5. Another automatic compaction occurs shortly afterward.

At an earlier protocol checkpoint I counted:

• 98 explicit Context automatically compacted markers
• 805 occurrences of Get-Content
• 103 read commands involving one central React page
• 85 involving the central Netlify endpoint
• 74 involving the Cloudinary helper
• 73 involving the media service
• 49 involving the new database migration

The compactions occurred every 24–174 visible protocol lines, averaging approximately 67 lines apart. The same task has since progressed to well over 100 automatic compactions.

The protocol labels these as automatic compactions; these counts do not include manually requested /compact operations.

This appears to be a feedback loop: compaction loses the exact working set, reconstructing that set generates enough tool output to trigger another compaction, and meaningful implementation progress becomes increasingly slow.

/feedback failure

I attempted to report the affected session using /feedback.

The upload failed and retained this Feedback ID:

019f1a12-0ee3-7d33-b396-899e85e7358a

Retrying the upload consistently causes the current Windows application to terminate with “ChatGPT stopped unexpectedly.” The Update ChatGPT action confirms that version 26.727.6591.0 is already current.

This may indicate that the unusually large or pathological session also breaks feedback-session serialization or upload. The Feedback ID was generated, but the UI explicitly says that the upload failed.

Expected behavior

Automatic compaction should reclaim enough usable context for a long-running task to continue without repeatedly rereading the same files and compacting again.

If sufficient space cannot be reclaimed, Codex should stop the loop, preserve the filesystem state, and offer a continuation or fresh-context recovery path.

Submitting /feedback for an affected session should not terminate the application. If the session is too large to upload, the UI should report that safely and allow a reduced diagnostic report to be submitted.

Compactions continued way past 100 prior to attempting /feedback.

OS Name Microsoft Windows 11 Pro Insider Preview
Version 10.0.26220 Build 26220

The failing execution caused a huge waste of time and tokens

Working for 3h 56m 37s.txt

<img width="745" height="382" alt="Image" src="https://github.com/user-attachments/assets/f7804226-f84d-4ec0-b477-a9cc8bf33a78" />

<img width="1668" height="444" alt="Image" src="https://github.com/user-attachments/assets/a177299d-d6a4-44f9-bf18-797e3fff24c7" />

<img width="828" height="433" alt="Image" src="https://github.com/user-attachments/assets/cfc1f30a-a994-4b00-8a45-5fb80d48b954" />

Images documenting some of the error messages.

I used the following prompt to investigate the issue that I reported above from withing Codex:

Review the file that I just uploaded. It is a partial protocol of the work and the endless automatic compactions that occurred over the last five hours or so. The issue is a known bug - I found an existing issue that matches your case closely: openai/codex #31033 — repeated automatic compaction loop. It remains open and already carries the labels bug, context, app, and rate-limits. See if there is anything you can detect about the error that is not visible to outside observers or error reporting. I submitted the error report below under the error that I quoted above:

"text"

The response included the following 'Suggested Issue Addendum':

Additional local forensic evidence identifies the feedback crash cause.

The affected task JSONL reached approximately 9.8 GiB. During the first
feedback/upload attempt, the Codex desktop log reported:

memory allocation of 10424232598 bytes failed

The retry reported:

memory allocation of 10424232600 bytes failed

Both app-server processes exited with Windows status
3221226505 / 0xC0000409. The requested allocations closely match the task
record size, strongly suggesting feedback/upload materializes the complete
session in one contiguous allocation.

The exported protocol contains 114 explicit automatic-compaction markers,
with an average of 65 visible lines between compactions, plus repeated reads
of the same central files. No obvious JSONL corruption was found at the end
of the task record.

This appears to be two linked defects:

1. compaction/reconstruction repeatedly expands the session;
2. feedback submission crashes when serializing the resulting session.