Repository navigation
Codex copied the image file 150,000 times, consuming 400 GiB of disk space #35470
Description
What version of Codex CLI is running?
0.145.0
What subscription do you have?
Pro 20x
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Microsoft Windows NT 10.0.26220.0 x64
What terminal emulator and version are you using (if applicable)?
Windows Terminal (PowerShell)
Codex doctor report
What issue are you seeing?
Codex Base64-encodes every image sent by the user and stores the encoded data in the session’s JSONL file. Whenever context compaction occurs, previously uploaded images are stored again in the JSONL file as part of the compacted output. When a subagent is invoked, it copies the contents of the main session’s JSONL file.
In one session, I sent 57 images totaling approximately 3.5 MiB. The session underwent 1,052 context compactions, resulting in as many as 1,049 copies of these images within a single JSONL file. The file contained 483,017 image-data entries in total, occupying more than 2.8 GB. The session also created 169 subagents, causing those 1,049 copies to be duplicated up to another 142 times.
As a result of context compaction and subagent duplication, the earliest image I sent had approximately 150,000 copies under .codex/sessions, and the entire .codex/sessions directory consumed more than 400 GB of disk space.
What steps can reproduce the bug?
- Open the Codex CLI/App.
- Send an image.
- Continue the session.
- Watch the
.codexfolder keep growing until it consumes the entire disk.
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Jul 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
[-]Codex copied the image 150,000 times, consuming 400 GiB of disk space[/-][+]Codex copied the image file 150,000 times, consuming 400 GiB of disk space[/+]maaoding commentedon Jul 30, 2026
I confirmed the same on-disk compaction duplication pattern in a local Windows Codex session using payload hashes rather than marker-string counts.
Current environment:
26.721.11231.00.146.0-alpha.3.1One historical JSONL session is currently
433,181,092bytes. A streaming scan of actualdata:image/<mime>;base64,<payload>values found:The strongest individual example is a PNG payload with:
2,556,192characters1,917,142bytes91response_item/messagerecords:2compactedrecords:89, spread across 46 compaction recordsThe payload itself was not printed or uploaded; only SHA-256 hashes, lengths, MIME types, record types, and timestamps were inspected.
The session file spans multiple app builds, so this does not prove that the latest build created every copy. It does confirm that identical image payloads were persisted repeatedly by compaction records on Windows and that the resulting Base64 data accounts for a substantial portion of the JSONL size.
A durable fix likely needs image payloads to be stored once and referenced by content hash or attachment ID from compaction and subagent records, rather than embedding the full Base64 value again.
ctmaomao commentedon Aug 6, 2026
Independent Windows reproduction using streaming SHA-256 hashes rather than raw marker counts. No rollout content or image data was printed or uploaded.
Environment and current store
26.730.8199.010.0.26200.0, x643033.469 GiB677.88 MiB549.09 MiBand208.36 MiBPayload-level duplication
A streaming scan extracted only actual
data:image/<mime>;base64,<payload>values, hashed each payload with SHA-256, and retained only counts. For the three largest affected rollouts:This independently confirms that identical Base64 image payloads are physically persisted multiple times in session JSONL. The strongest of these three files contains more than five stored occurrences per unique payload on average.
The currently active resumed thread also contains eight Base64 image payload occurrences but only three unique SHA-256 hashes (five duplicates; one payload appears four times). Two payload occurrences are in
compactedrecords. The affected rollouts span multiple app versions, so these measurements prove the persisted duplication pattern and current retained impact, but do not claim that package26.730.8199.0originally created every historical duplicate.Expected safeguards
compacted.payload.replacement_history.No raw JSONL, screenshots, prompts, file paths, usernames, session IDs, or image hashes are included because even hashes and metadata can unnecessarily fingerprint private material.
Talalkerbag commentedon Aug 11, 2026
Independent Windows reproduction from Codex Desktop. I am adding this here rather than opening a duplicate.
Environment
0.147.0-alpha.6.6Storage impact
Before cleanup:
%USERPROFILE%\.codex: 534.6 GiB (574,060,093,440 bytes)sessions: 511.3 GiBarchived_sessions: 21.6 GiBA sampled 14+ GiB rollout had ordinary small JSONL records at its beginning, but sampled 1 MiB blocks from roughly 1% through 99% of the file contained no newline. That suggests at least one enormous persisted JSONL record, consistent with a compacted/history payload containing duplicated inline data.
The machine's free space fell to about 160.1 GiB. After closing obsolete tasks and deleting 406 obsolete rollout histories while preserving the three active tasks and all configuration/authentication/plugin/state-database data:
.codexfell to 18.21 GiBUser impact
There was no visible storage warning, quota, rotation, or supported cleanup workflow before Codex consumed more than half a terabyte. Cleanup required sacrificing historical task resumability and carefully preserving active-task/state files.
Requested safeguards
Privacy note: no raw rollout JSONL, prompts, tool inputs/outputs, screenshots, local paths, usernames, session IDs, tokens, or payload hashes are attached. Sanitized structural measurements can be provided if maintainers need more detail.
getoverroot commentedon Aug 15, 2026
For Windows users looking for a temporary cleanup workaround, I published codex-clean-subagents, an unofficial and experimental Codex skill.
It performs a read-only audit, limits deletion to closed leaf subagents under explicitly selected main threads, requires a verified canary before batch cleanup, and uses the installed codex delete --force command. It does not directly modify SQLite or rollout files and excludes main conversations, open subagents, caches, and unrelated data.
This is not a fix for the underlying storage-growth bug. Deleted child histories cannot be recovered, so the audit output should be reviewed carefully before approval.
martinmclee commentedon Aug 21, 2026
Confirming this issue still occurs with Codex runtime 0.149.0 on Windows.
Archived task histories grew beyond 100 GB within four days, with many individual history files several GB each. This happened after an earlier local archive cleanup, and disk usage resumed growing rapidly. No task contents, filenames, local paths, or device-identifying diagnostics are attached.
The observed growth is consistent with image/compaction/subagent history amplification rather than normal transcript size. Please add bounded storage quotas, payload deduplication, log rotation, disk-space warnings, and a supported emergency-pruning mechanism.