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

[silver72kr]

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.

[github-actions]

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

• Codex Desktop 26.810: repeated compacted image snapshots grow rollout to 16.9 GB and app-server to 19.5 GB #39013

Powered by Codex Action

[silver72kr]

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]

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.

[ORI-Fourreaumaxime]

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 compacted records re-embed identical inline image/Base64 payloads instead of referencing previously persisted media.

Sanitized measurements from my local .codex store:

• .codex total size: ~48.3 GiB
• sessions directory: ~44.5 GiB
• one affected rollout: ~19.63 GiB
• records in that rollout: 31,123
• compacted records: 588
• bytes attributable to compacted records: ~19.49 GiB (~99.3% of the file)
• unique PNG payloads identified: 89
• total copies of those PNGs: ~50,905
• estimated duplicated image payload in that single rollout: ~19.29 GiB
• across the audited local rollout corpus, duplicated Base64 payloads were estimated at ~35.8 GiB

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:

1. metadata traversal must handle Win32 long paths (\\?\) correctly; ordinary os.scandir failed deterministically on persistent node_modules paths around 256+ characters;
2. SQLite integrity checks must not open source DB/WAL/SHM families directly if the goal is a zero-mutation preflight. A clone-only check outside CODEX_HOME avoided 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.