Runaway inline image duplication during context compaction creates 20+ GB rollout files #37346

Activity

1. krosman19

   added

   bugSomething isn't workingSomething isn't working

   on Aug 7, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   on Aug 7, 2026
3. github-actions commented on Aug 7, 2026

   

   github-actionsbot

   on Aug 7, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Current Windows Desktop still fails remote compaction for image-heavy long-running tasks (reconnect 5/5) #36232
   • Codex crashes when serializing image-heavy saved task payloads #36157

   Powered by Codex Action
4. krosman19 commented on Aug 7, 2026

   

   krosman19

   on Aug 7, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Related to #34863, which tracks the same compaction/image-amplification mechanism primarily through Desktop and app-server symptoms. This report adds an independent Codex CLI 0.146.1 occurrence involving dormant 21.0 GB and 7.7 GB rollouts. Please consolidate or close as a duplicate if both cases share the same fix.
5. robinhur commented on Sep 7, 2026

   

   robinhur

   on Sep 7, 2026

   More actions

   Still reproducing on Codex CLI 0.153.2 (the report above was on 0.146.1), macOS 26.6, Apple Silicon. Adding a measurement that pins the amplification law exactly: growth is linear in compaction count, at one full copy of the image set per compaction.

   Single-thread breakdown (678 MB rollout, 319 JSONL records)

   • 44 records exceed 1 MB, and every one of them is a compacted record carrying replacement_history
   • each of those 44 records is 15.2 MB and contains exactly 30 input_image entries — identical size, identical count, record after record
   • data:image/png occurrences: 1,320 = 30 unique images × 44 compactions
   • unique image payload ≈ 30 × 526 KB ≈ 15.4 MB; file is 678 MB → 97.7 % duplication
   • input_image count outside compaction records: 0 — the images exist only inside replacement_history, i.e. this thread never captured them; it inherited the history and re-serialized it on every compaction

   The slope is stable across threads on the same host

   compactions	rollout size	MB per compaction
   44	678 MB	15.41
   51	786 MB	15.41
   57	878 MB	15.40
   62	971 MB	15.66
   64	1,010 MB	15.78
   242	4,356 MB	18.00

   15.4 MB/compaction matches the unique image-set size almost exactly, which is what makes "one full copy per compaction" the mechanism rather than an estimate.

   Host-wide impact

   • 48 rollout files over 100 MB, totalling 29.7 GB, out of 34.7 GB of session data — ~86 % of all rollout bytes on this machine are duplicated image payload
   • oldest affected file dates to 2026-05-07, so this has been accumulating for four months
   • on the heaviest day, 20 concurrent threads produced 17 GB in a single day; the same host also hit sustained swap pressure, which lines up with Codex app-server reaches 27 GB footprint and 36 GB swap after compacted records grow one rollout JSONL to 10.2 GB with repeated inline PNG data URLs #34863

   No rollout contents, thread IDs, screenshots, prompts, or conversation data are attached — counts and sizes only.

   A fix that makes replacement_history reference prior image records instead of re-embedding them (or that drops image payloads from compaction snapshots entirely) would remove essentially all of this. A supported repair path for existing rollouts — stripping duplicated binary payloads while preserving the text transcript — would also help, since these files cannot safely be deleted wholesale while their threads may still resume.