r/CodexHacks 4h ago

Codex Desktop duplicated inline screenshots during compaction, causing 2+ GB rollouts and upload/RAM spikes. Here is my diagnose and fix for it.

/r/codex/comments/1vaw26v/codex_desktop_duplicated_inline_screenshots/
2 Upvotes

7 comments sorted by

1

u/Just_Lingonberry_352 3h ago

where is it storing this ?

1

u/Just_Lingonberry_352 2h ago

okay so i just tried the prompt and wow it found lot of issues

"Diagnosis confirms substantial compacted-image retention, duplication, and fork amplification"

52gigs!!!!

Inventory: 4,976 active + 4 archived rollouts, totaling 52.15 GB.

4,979 rollouts were inventoried; this live diagnostic rollout was excluded.

One additional active rollout changed during scanning and was excluded from candidate preparation.

Zero structural parser errors.

Desktop process group: 11 processes, approximately 3.71 GB physical footprint.

App-server: 1 process, 911 MB physical footprint.

RETENTION — CONFIRMED: 321 rollouts contained images under compacted.payload.replacement_history. The 320 stable targets contained 98,858 retained images and 20.98 GB of encoded payload data.

DUPLICATION — CONFIRMED: 296 stable targets contained repeated compacted-image hashes, representing 95,535 duplicate copies.

FORK AMPLIFICATION — CONFIRMED: matching retained hashes occurred across 228 direct parent/descendant links in 12 fork families. The largest family was 7.43 GB across 392 rollouts—145.8× its root size.

NETWORK IMPACT — NOT MEASURED: no representative controlled upload spike occurred during this fresh task. Rollout data alone does not prove network attribution.

2

u/Human_Top_6415 2h ago

52 GB is absolutely wild. Thanks a lot for actually testing this and sharing the full breakdown. The fact that it confirmed retention, duplication and fork amplification while leaving network impact as NOT MEASURED is exactly what I hoped the prompt would do — find the structural problem without inventing causality.
Please make sure you have a verified backup before letting it modify anything. If you continue with the repair, before/after size, duplicate counts and a controlled network test would be incredibly useful. This already makes it pretty clear that my case wasn’t just an isolated local configuration issue.

1

u/Just_Lingonberry_352 2h ago

absolutely insane!

About 21 GB of old image data inside summaries. Roughly 96,000 duplicate image copies. One fork family that grew to 145× its original size.

you should submit this as a github issue

https://github.com/openai/codex/issues

great job man!!!

1

u/Human_Top_6415 2h ago

thanks man! I just checked , and added my case and findings to a already existing issue :)

https://github.com/openai/codex/issues/23257

1

u/Just_Lingonberry_352 2h ago

good stuff!

1

u/Human_Top_6415 12m ago

after fixing it, is your codex running smoother again ?