Repository navigation
[Windows] Automatic compaction repeatedly embeds inline images, growing a long-running rollout beyond 16 GiB #40323
Description
What version of the Codex App are you using?
Codex Desktop 26.818.5229.0
What subscription do you have?
ChatGPT Pro
What platform is your computer?
- Windows 11 Home 25H2
- OS build 26200.9168
- SSD storage with sufficient free space
- No VPN or proxy
What issue are you seeing?
A long-running, image-heavy Codex Desktop thread has become nearly unusable because automatic context compaction repeatedly appends full historical inline image payloads to the persistent rollout JSONL.
The last safely verified rollout size was 17,331,077,911 bytes (16.141 GiB). The thread has continued to compact after even very short messages and is now estimated to exceed 20 GB, but I will not intentionally trigger another compaction merely to measure it because doing so makes the affected thread larger and less usable.
A read-only analysis at an earlier point found:
| Measurement | Result |
|---|---|
| Rollout size at detailed scan | 16,742,745,744 bytes |
| Inline data:image payload bytes | 16,639,121,243 bytes (99.381%) |
| Inline image occurrences | 13,109 |
| Unique image values | 110 |
| Unique image data | 144,420,446 bytes |
| Weighted storage amplification | approximately 115.21x |
| Maximum repetition of one image | 236 copies |
This was not caused by 16 GB of original user images. Approximately 144 MB of unique embedded image data was repeatedly serialized until it occupied almost the entire rollout.
Compaction evidence
One recent compacted record added 146,948,534 bytes (140.141 MiB) in a single operation. It contained 111 complete inline data:image/png;base64 payloads.
All 111 images were under user messages in this structure:
{
"type": "message",
"role": "user",
"content": [
{
"type": "input_image",
"image_url": "data:image/png;base64,[BASE64 REMOVED]"
}
]
}
The original rollout was not modified during analysis.
Controlled reproduction
I also performed a controlled test in a separate thread using one 30.35 KiB PNG uploaded exactly once.
Before and after one automatic compaction:
- type: compacted records: 6 -> 7
- complete inline image data URIs: 56 -> 59
- the test image existed once before compaction and twice afterward
- the new compacted record also reinserted two older images
This independently confirms that payload.replacement_history appends complete historical Base64 image data to the persistent JSONL during compaction.
User impact
- Opening the affected thread is extremely slow.
- Sending even a short greeting can immediately trigger another compaction.
- Each compaction adds another large record containing historical images.
- The thread becomes progressively slower and more difficult to recover.
- Starting a new thread is not an equivalent recovery method because it does not preserve the accumulated conversational context and continuity.
A separate archive failure observed earlier was fixed by an app update. The inline-image re-serialization and storage-amplification problem remains reproducible on the version listed above.
Expected behavior
- Store each unique image blob once and reference it by ID or content hash.
- Do not reinsert complete historical Base64 payloads into every compacted record.
- Bound retained image count and byte size during compaction.
- Avoid immediate repeated compaction when the replacement history remains near the context threshold.
- Provide a supported repair/optimization tool that removes duplicated media payloads while preserving the original conversation.
- Preserve the original rollout and provide integrity verification and rollback during repair.
Privacy and diagnostic data
No raw rollout, local paths, thread IDs, Base64 contents, screenshots, email addresses, or conversation text are included publicly. The original rollout has been preserved, and additional sanitized measurements were provided through a private OpenAI Support case.
Related reports
- Desktop compaction repeatedly embeds full image base64 in compacted checkpoints #23257
- Local compaction v2 retains unbounded input_image payloads, causing repeated auto-compaction #33493
- Codex copied the image file 150,000 times, consuming 400 GiB of disk space #35470
- Codex Desktop 26.810: repeated compacted image snapshots grow rollout to 16.9 GB and app-server to 19.5 GB #39013
This report is being filed separately because it provides an independent, controlled Windows reproduction on a newer Codex Desktop build, plus a measured 16.141 GiB real-world rollout and a 140.141 MiB single-compaction increase.
Activity
github-actions commentedon Aug 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
silver72kr commentedon Aug 24, 2026
Thank you. I reviewed #39013 before filing this report.
I am keeping this issue open because it provides an independent reproduction on Windows 11 using a newer Codex Desktop build, plus a controlled single-image reproduction and byte-level measurements showing a 140.141 MiB increase from one compaction.
#39013 documents the same failure pattern on macOS. This report confirms that the storage amplification also affects the current Windows desktop build and provides additional Windows-specific evidence.
silver72kr commentedon Aug 24, 2026
Update: two independent preservation-first local recoveries succeeded
I performed two separate, unsupported local recovery experiments after preserving verified original backups. No raw rollout, local path, thread ID, Base64 payload, authentication data, screenshot, or conversation text is disclosed here.
Recovery method
Validation
Interpretation and limitations
This is strong evidence that repeated persistent inline-image serialization was the dominant cause of the storage growth and loading failure in these two threads: removing only the image objects reduced 18.65 GB to 111.97 MB and 4.60 GB to 55.53 MB while preserving usable conversation history.
This does not mean the product bug is fixed. These were unsupported local repairs, and I have not reintroduced images or intentionally triggered another image-containing compaction. The recovery procedure was designed, implemented, and validated by Codex itself under explicit user supervision and approval.
I am deliberately not publishing the current recovery runner because direct modification of a user's rollout can destroy a conversation if the path, schema, expected counts, or hashes do not match. I can provide maintainers with a sanitized description of the transformation and validation logic if useful.
Product request
Please prevent historical image payloads from being serialized repeatedly into compacted records, and provide an official preservation-first repair tool that can:
These two independent successful recoveries show that affected long-running conversations can remain usable when duplicated inline media is removed without discarding the conversation itself.
ORI-Fourreaumaxime commentedon Aug 29, 2026
Independent Windows corroboration with a larger local corpus and a separate forensic audit.
I observed the same amplification pattern in Codex Desktop local rollouts: repeated
compactedrecords re-embed identical inline image/Base64 payloads instead of referencing previously persisted media.Sanitized measurements from my local
.codexstore:.codextotal size: ~48.3 GiBsessionsdirectory: ~44.5 GiBcompactedrecords: 588compactedrecords: ~19.49 GiB (~99.3% of the file)The important point is that the affected rollout did not contain ~19 GiB of unique user images. The original image payloads were already present in earlier events; compaction repeatedly serialized them again.
This is consistent with the reproduction reported here and in related issues, and strongly suggests the persistent rollout format/compaction path needs content-addressed or reference-based media handling rather than repeated inline Base64 serialization.
I also had to build a fail-closed recovery workflow because manual JSONL editing is too risky for long-running sessions. The recovery work uncovered two secondary implementation hazards relevant to any future official repair tool on Windows:
\\?\) correctly; ordinaryos.scandirfailed deterministically on persistentnode_modulespaths around 256+ characters;CODEX_HOMEavoided creating new sidecars in the source tree.I have retained anonymized structural reports, SHA-256 evidence, duplication counts, and read-only diagnostics. I am intentionally not posting raw rollouts, screenshots, thread contents, UUIDs, or local paths because they contain private project data.
A supported Codex repair/optimization command that can deduplicate historical image payloads while preserving text/context and verifying archive/restore integrity would be very valuable for already-affected users.