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

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:

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.

Start by tracing automatic context compaction and payload.replacement_history in the Codex Desktop rollout handling, then reproduce the single-image compaction measurements described in the report. Done means preventing repeated full data:image payload serialization while preserving the original rollout and validating integrity and repair behavior against the reported counts.