›_ Codex Issues
Codex Issues / #40323

[Windows] Automatic compaction repeatedly embeds inline images, growing a long-running rollout beyond 16 GiB

Open 💬 3 comments Opened Aug 24, 2026 by silver72kr
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  • #23257
  • #33493
  • #35470
  • #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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 days ago

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

  • #39013

Powered by Codex Action

silver72kr · 4 days ago

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 · 3 days ago

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.

| Measurement | Session A | Session B |
|---|---:|---:|
| Original rollout | 18,654,924,713 bytes | 4,601,464,470 bytes |
| Recovered rollout | 111,967,801 bytes | 55,526,189 bytes |
| Bytes removed | 18,542,956,912 bytes | 4,545,938,281 bytes |
| JSONL records | 17,859 | 15,990 |
| compacted records | 152 | 54 |
| inline input_image objects replaced | 14,552 | 2,794 |
| unique inline image values | 110 | 94 |
| remaining inline input_image objects | 0 | 0 |

Recovery method

  • The original rollout was never edited in place. An untouched copy was preserved on another drive, and a second immediate rollback copy was retained.
  • The source SHA-256 was recorded and verified against the untouched backup.
  • The JSONL was streamed one record at a time; the full multi-gigabyte file was never loaded into memory.
  • Every existing record was retained, including all compacted records and their window-linkage fields.
  • Only exact input_image objects whose image_url began with data:image/ were replaced with valid input_text placeholders in the recovered copy.
  • Conversation text, compaction summaries, encrypted_content, IDs, turn IDs, window IDs, and non-image attachments were not intentionally modified.
  • For these recovered copies, both the repeated compaction copies and the original inline-image objects were removed, so old images could not seed another compaction. The untouched originals still contain all images.

Validation

  • Every output record parsed as valid JSON.
  • The total JSONL record count and compacted-record count were unchanged.
  • A full source-versus-output comparison confirmed that unchanged records were byte-identical and changed records matched only the exact image-object transformation.
  • The recovered file installed in the live session matched the separately validated recovered copy by SHA-256.
  • Opening either recovered thread caused a 0-byte increase and did not restore the images.
  • Both threads displayed immediately and retained their text context and conversational continuity.
  • Both threads responded normally and quickly. After one short exchange in Session B, the file increased by only 8,318 bytes; the compacted count remained 54 and inline input_image remained 0.

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:

  1. back up and hash the original rollout;
  2. deduplicate or externalize repeated media payloads;
  3. preserve conversation text and thread/window linkage;
  4. validate the transformed rollout completely;
  5. provide a safe rollback path.

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.