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

[Glavo]

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?

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

[github-actions]

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

• Codex Desktop: screenshots re-persisted in full on every compaction and inherited by subagent forks - ~/.codex/sessions reached ~165 GiB (95% base64 images) #35458
• Multi-agent V2 full-history forks duplicate historical compaction snapshots and inline images, causing >100 GiB session storage growth #34268
• 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
• Codex CLI and Desktop session rollouts can silently consume tens to hundreds of GiB #34337

Powered by Codex Action

[maaoding]

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]

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.