›_ Codex Issues
Codex Issues / #35470

Codex copied the image file 150,000 times, consuming 400 GiB of disk space

Open 💬 7 comments Opened Jul 26, 2026 by Glavo
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

<img width="1150" height="1179" alt="Image" src="https://github.com/user-attachments/assets/cb791449-7ddb-475d-b690-53100bb561d3" />

What steps can reproduce the bug?

  1. Open the Codex CLI/App.
  2. Send an image.
  3. Continue the session.
  4. Watch the .codex folder keep growing until it consumes the entire disk.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35458
  • #34268
  • #34863
  • #34337

Powered by Codex Action

maaoding · 28 days ago

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:

  • Windows 11 Pro 10.0.26200 (build 26200)
  • OpenAI.Codex package: 26.721.11231.0
  • Bundled CLI: 0.146.0-alpha.3.1

One historical JSONL session is currently 433,181,092 bytes. A streaming scan of actual data:image/<mime>;base64,<payload> values found:

  • 796 image payload occurrences
  • 600 unique payloads by SHA-256
  • 196 duplicate occurrences
  • 347,320,878 Base64 payload characters in total
  • approximately 260,489,831 decoded image bytes across all occurrences

The strongest individual example is a PNG payload with:

  • Base64 length: 2,556,192 characters
  • estimated decoded size: 1,917,142 bytes
  • total occurrences: 91
  • occurrences in response_item / message records: 2
  • occurrences inside compacted records: 89, spread across 46 compaction records

The 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 · 21 days ago

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

  • OpenAI.Codex package currently installed: 26.730.8199.0
  • Windows: 10.0.26200.0, x64
  • Session JSONL files: 303
  • Total session storage: 3.469 GiB
  • Largest rollout: 677.88 MiB
  • Next largest rollouts: 549.09 MiB and 208.36 MiB

Payload-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:

| Rollout size | Image payload occurrences | Unique payload hashes | Duplicate occurrences | Occurrence/unique ratio |
|---:|---:|---:|---:|---:|
| 677.88 MiB | 1,245 | 626 | 619 | 1.99x |
| 549.09 MiB | 805 | 159 | 646 | 5.06x |
| 208.36 MiB | 313 | 187 | 126 | 1.67x |

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 compacted records. The affected rollouts span multiple app versions, so these measurements prove the persisted duplication pattern and current retained impact, but do not claim that package 26.730.8199.0 originally created every historical duplicate.

Expected safeguards

  • Store binary image bytes once and reference them by content hash or attachment ID from normal events, compaction records, and subagent forks.
  • Do not re-embed full historical images in compacted.payload.replacement_history.
  • Avoid materializing full binary history into child/subagent rollouts.
  • Add visible per-session/global storage usage, warnings before disk pressure, and a supported resumability-preserving cleanup/dehydration path.

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 · 16 days ago

Independent Windows reproduction from Codex Desktop. I am adding this here rather than opening a duplicate.

Environment

  • Windows 11 Pro, build 26200, x64
  • Bundled Codex CLI: 0.147.0-alpha.6.6
  • Long-running, image/tool-heavy Desktop task using collaboration/subagents and repeated context compaction

Storage impact

Before cleanup:

  • %USERPROFILE%\.codex: 534.6 GiB (574,060,093,440 bytes)
  • sessions: 511.3 GiB
  • archived_sessions: 21.6 GiB
  • Everything outside those two history directories combined: about 1.8 GiB
  • One day of active session history: 173.6 GiB
  • Many rollout JSONL files were 7–14+ GiB each
  • Largest archived rollout: 21.57 GiB
  • One active rollout: 14.94 GiB

A 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:

  • .codex fell to 18.21 GiB
  • Free disk space rose to about 660.4 GiB

User 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

  • Deduplicate image/tool payloads across compaction records and subagent forks.
  • Store large binary payloads out of line and reference them by stable ID/hash.
  • Add per-task and global history quotas/rotation.
  • Warn before Codex storage or the host drive reaches a dangerous threshold.
  • Provide a supported storage report and resumability-aware cleanup/pruning UI.
  • Avoid copying full parent history into every subagent rollout.

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 · 12 days ago

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.

shleder · 11 days ago

The compaction/subagent amplification you measured is exactly the kind of oversized persisted-session case I want to test safely with codex-rescue. It’s an experimental local-first fsck/recovery tool; it won’t solve the upstream image duplication bug, and it never needs the raw rollout uploaded.

Because your session tree is enormous, please start only with discovery/diagnosis:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

I’m specifically interested in whether it stays bounded, avoids mutating the source JSONL, and reports useful evidence rather than choking on oversized payloads. Please do not run salvage on a 100s-of-GB tree just for this test unless diagnosis succeeds and you actually need recovery.

Sanitized output, runtime/OS versions and exit codes are enough. Please don’t post raw rollouts/SQLite, images/base64, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

martinmclee · 7 days ago

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.