Codex Desktop: screenshots re-persisted in full on every compaction and inherited by subagent forks - ~/.codex/sessions reached ~165 GiB (95% base64 images)

Open 💬 14 comments Opened Jul 26, 2026 by viborc

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.721.41059

What subscription do you have?

Pro ($200)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

ChatGPT Desktop's bundled Codex persisted ~165 GiB of session JSONL under ~/.codex/sessions (Codex's own scan reported 176.7 billion bytes), driving my 460 GB Data volume to ~99% capacity and putting unrelated writes at risk.

There is no error message - the failure mode is silent. I got no warning, quota, retention policy, or UI surfacing of session storage exists. The only user-visible symptoms were the disk filling at a sustained ~21 GB/hour (four ~2.6 GiB rollouts in ~28 minutes, three of them within a single minute) and df approaching 100%.

I diagnosed the files with privacy-safe sampling (line-length histograms via awk, structure via jq on small samples - never loading full files).

Measured root cause:

1. The bytes are overwhelmingly repeated screenshots.

I'm sharing some representative 2.64 GiB rollout:

| Metric | Value |
|---|---|
| JSONL records | 35,826 |
| Lines < 1 KiB | 30,356 |
| Lines between 1 and 16 MiB | 184 |
| Largest single line | 16,711,982 bytes |
| Inline image occurrences | 6,412 |
| Unique images | 555 |
| Mean copies per unique image | ~11.6 |
| Total base64 characters | 2,703,184,704 |
| Share of file that is base64 image payload | 95.41% |

2. The duplication lives in compacted replacement history.

Here's the byte attribution by field path:

| Field path | Approx. characters |
|---|---|
| payload.replacement_history[].content[].image_url (in type: "compacted" records) | 2.55 × 10⁹ |
| payload.result.Ok._meta["codex/toolSurface"].screenshot.url | 1.37 × 10⁸ |
| payload.content[].image_url | 1.6 × 10⁷ |

Payloads are data:image/png;base64,… data URLs. My ~/.codex/computer-use/ directory is only 60 MB while transcripts are gigabytes - screenshots are inlined into the JSONL rather than stored once and referenced.

3. Each compaction appends another near-complete copy. Verified on the live root rollout: same inode (73927096) throughout, SHA-256 of the first 1 MiB unchanged, size grew 3,118,851,621 → 3,135,728,720 bytes with only the tail changing. So the file is physically append-only; the amplification is that every new compacted record can carry a near-full copy of the image-bearing replacement_history.

4. Subagent forks multiply the inflated context. Three subagents created within 60 seconds (23:34:16, 23:34:45, 23:35:16) each have distinct session IDs, thread_source: "subagent", and the same forked_from_id pointing at the giant parent - and each materialized its own ~2.6 GiB rollout (~7.8 GiB written by one fork action). Verified these were deliberate forks, not crash restarts: same continuously-running app-server writer, no process restart, no macOS crash report, no fatal/OOM/termination event in system logs.

5. Scale. The root session (created 2026-07-11) accumulated, through resumes and forks, a family of 329 sessions totaling ~164 GiB by 2026-07-26 - essentially the entire store.

Configuration ruled out: history.persistence unset (default save-all); history.max_bytes unset (and per docs applies to the prompt history file, not rollouts); RUST_LOG=warn; no OTel exporters; no screenshot-retention or verbose-logging options enabled. I found no documented setting that caps rollout size, strips/externalizes images during compaction, or imposes any quota or retention on ~/.codex/sessions.

Related: #24388 (closed), #24948 (closed), #34061 (open) - detailed comparison under Additional information. In short, this report shows the image-retention behavior of #24388 persisting in 0.145.0-alpha.18 on the Desktop surface (all prior reports are CLI/TUI), amplified by the subagent pattern of #34061.

What steps can reproduce the bug?

Observed workflow (this is not a minimal deterministic reproducer so keep that in mind):

In ChatGPT Desktop, run a long-lived Codex task that drives a browser / computer-use surface taking screenshots. ine was running for multiple days (longer WordPress to Hugo migration project)
Keep working in (resuming) that same thread until remote compaction has occurred many times.
Inspect the newest type: "compacted" records in the session rollout under ~/.codex/sessions/YYYY/MM/DD/: payload.replacement_history[].content[].image_url will contain repeated data:image/png;base64,… payloads.
Spawn subagents from this session with inherited context; each child rollout materializes at roughly the parent's inflated size.

The controlling variables are compaction count × image count, not session length.

I'm sharing two sessions from the same evening, same version, same workload type:

| | Control (22:26) | Failure case (23:07) |
|---|---|---|
| File size | 48.4 MiB | 2.64 GiB |
| Base64 share | 96.54% | 95.42% |
| Unique images | 38 | 543 |
| compacted records | 3 | 232 |

A 54× size difference within 40 minutes with the storage format unchanged. Context-window usage: the failure-case session repeatedly hit the context limit - 232 remote compactions - and each compaction persisted another near-complete copy of the image-keeping history.

Session IDs (most files since deleted via the supported codex delete path to recover the disk; IDs provided for correlation with any server-side logs):

Root / parent thread: 019f5098-3b7d-7a23-bd3a-7027dd7eef7b (created 2026-07-11T11:53Z)
Failure-case rollout sampled above: 019f9b33-43fd-7321-bdf0-a579840349d5 (2.64 GiB)
Sibling subagent forks (~2.6 GiB each, same forked_from_id): 019f9b33-b6f4-7ef1-9791-01c7fc82215a, 019f9b34-300b-7e01-a4c9-14bbdbbd1de6
Earlier same-evening 2.6 GiB session: 019f9b1a-e255-7df2-8635-73368e0bcf5d
Preserved control sample (48.4 MiB, retained as evidence): 019f9af4-fd7d-71c1-8f82-095825e66f48

Privacy-safe inspection commands (report sizes/structure without printing content):

# Overall usage and large files
du -sh ~/.codex ~/.codex/sessions
find ~/.codex/sessions -type f -size +500M -exec ls -lh {} \;

# Line-length histogram of a rollout (finds the multi-MiB lines)
awk '{ n=length($0); if (n>1048576) big++; else small++; if (n>max) max=n }
     END { print small" lines <1MiB, "big" lines >1MiB, largest "max" bytes" }' path/to/rollout.jsonl

# Record types on a sample, no payload content
head -50 path/to/rollout.jsonl | jq -r '.type' | sort | uniq -c

# Confirm image data URLs inside compacted replacement history (prints only counts)
grep -c '"type":"compacted"' path/to/rollout.jsonl
grep -o 'data:image/png;base64' path/to/rollout.jsonl | wc -l

What is the expected behavior?

Compaction should not re-persist raw historical image payloads in full on every compacted record. Binary payloads should be stored once (content-addressed, or as files under e.g. computer-use/) and referenced from the transcript.
Subagent forks should not inherit and re-serialize the parent's full binary history; a bounded or text-only handoff should be the default - I had to limit the number of agents working in parallel to keep this manageable
Session storage should be bounded: per-session and global quotas, retention/rotation, and a user-visible warning before storage becomes critical.
A screenshot-heavy session of ordinary length should not be able to silently consume hundreds of gigabytes, and ~/.codex/sessions growth should be visible to the user somewhere in the product.

Additional information

Relationship to existing issues. #24388 (closed) documents the same data shape and field path - input_image data URLs preserved in compacted replacement_history - with a remote-compaction context deadlock as the symptom; this report shows the same retention behavior present in 0.145.0-alpha.18 with disk exhaustion as the failure mode.

There's also #24948 (closed) documents repeated persistence of large compacted records (text/tool-output variant, 91 GB store). #34061 (open) documents subagent fan-out consuming 755 GiB via event amplification on CLI 0.144.x.

Howwver, I decided to file this as a new issue because
(a) the affected surface is the Desktop app, which none of the above cover,
(b) the image-retention behavior persists after #24388's closure, and
(c) the byte-level quantification of image duplication is new. Happy to have this merged wherever the team prefers.

What I can provide: redacted structural statistics, field paths, record-type histograms, and before/after hashes for the affected files; the preserved 48 MiB control rollout's redacted structural data. I will not attach raw rollouts - the embedded screenshots capture private on-screen content from real work sessions.

Impact timeline: the store reached ~165 GiB and the 460 GB volume peaked around 99% used before intervention; the store grew a further ~16 GiB during the diagnostic session alone. That was a little crazy but necessary :D

Workarounds that contained it for me (for other affected users until a fix ships):

Keep screenshot-heavy browser/computer-use work in short-lived tasks; start a fresh task per phase instead of resuming one thread for weeks.
Give subagents a short text brief instead of full inherited context.
[agents] max_concurrent_threads_per_session = 1 in config.toml caps the fork multiplier (does not fix in-session duplication).
Monitor with du -sh ~/.codex/sessions and find ~/.codex/sessions -type f -size +500M.
Clean up only after every Codex writer has exited (deleting open files does not free space), preferably via codex delete <session-id>.

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 1 month ago

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

#34268
#34863

Powered by Codex Action

deat4 · 1 month ago

Additional Windows reproduction: #35470 reports the same compaction × subagent-fork amplification on Codex CLI 0.145.0.

Reported measurements:

57 images totaling approximately 3.5 MiB
1,052 context compactions
483,017 persisted image-data entries in one rollout
169 subagents
the earliest image duplicated approximately 150,000 times
more than 400 GiB consumed under .codex/sessions

This corroborates that the issue is cross-platform and is not limited to macOS/Desktop. The same two storage mechanisms are visible: inline image payloads are re-persisted in compacted replacement histories, then the inflated history is materialized again in child rollouts.

The structural fix should keep image bytes out of JSONL: store each image once as a content-addressed blob and persist stable references in normal events, compaction records, and subagent forks. A per-session/global storage warning or quota would also limit damage while that migration is implemented.

Cross-reference: #35470.

viborc · 1 month ago

Hopefully this gets picked up and fixed by the @codex team soon!

rahul-tuladhar · 29 days ago

Independent macOS/Desktop reproduction on 2026-07-29, at substantially larger scale.

Environment

macOS 26.6 (25G72), arm64
ChatGPT app 26.721.81911
Bundled Codex runtime recorded in affected rollout session_meta: 0.146.0-alpha.3
Installed standalone CLI: codex-cli 0.145.0

Storage impact

~/.codex/sessions: approximately 489 GiB
July 23 alone: approximately 375 GiB across 129 rollout files
July 22: approximately 49 GiB
July 24: approximately 36 GiB
The exact emergency-cleanup set for July 22–24 was 162 JSONL rollouts totaling 494,055,051,341 bytes (460.12 GiB)
Data volume before cleanup: 807 GiB used / 98 GiB available (90% used)
After removing that validated set: 346 GiB used / 558 GiB available (39% used)

Several sibling rollouts were 5.5–8.0 GB each; the largest remaining parent rollout was approximately 15.0 GB.

Representative affected subagent rollout

One rollout was 8,018,607,062 bytes and contained:

26,964 JSONL records
19,391 occurrences each of data:image and image_url
2,528 screenshot markers
644 compacted markers
thread_source: "subagent"
forked_from_id / parent_thread_id pointing to the same long-lived parent thread

The first session_meta record confirmed this was a deliberate subagent fork. Many sibling forks created around the same period had similarly multi-gigabyte sizes. This independently matches the reported amplification mechanism: image-heavy replacement history grows through repeated compaction, then each inherited subagent fork materializes another enormous rollout.

Recovery observations

Because the disk was under pressure, I first created a metadata-only TSV manifest (size, timestamp, rollout ID, parent ID, agent path, nickname, original path), validated the candidate set contained only JSONL files, and removed the 162 exact rollouts. Running the supported codex delete --force <session-id> afterward cleaned most stale session-index rows. codex doctor correctly detected the remaining file/DB parity inconsistencies.

A built-in storage/repair flow would be valuable in addition to fixing the persistence format: identify oversized rollouts, export a privacy-safe text/metadata summary, delete through the supported session path, and reconcile the state DB. Raw rollouts cannot safely be attached because they contain embedded private screenshots, prompts, and tool output.

lancelot1989jf · 29 days ago

Independent reproduction on a newer Desktop/CLI build

I can independently reproduce this issue on a newer build:

ChatGPT Desktop: 26.721.81911 (build 5973)
Bundled Codex CLI: 0.146.0-alpha.3.1
macOS: 26.4 (25E246), arm64
Model/mode: gpt-5.6-sol, Ultra, proactive multi-agent

The local Codex store grew from approximately 3 GiB at migration time on July 13 to 34 GiB on July 30. The current ~/.codex/sessions directory is approximately 31 GiB.

Privacy-safe structural analysis of the July rollout files produced these results:

| Metric | Result |
|---|---:|
| July rollout files | 1,481 |
| July rollout size | 29.76 GiB |
| Files identified as subagent sessions | 1,441 |
| Size attributed to subagent sessions | 27.26 GiB |
| Classifiable inherited prefix data | 24.97 GiB |
| Inherited share of classifiable subagent files | 92.4% |
| Inherited share of depth-1 subagent files | 95.8% |
| compacted records | 62,088 |
| Bytes stored in compacted records | 11.53 GiB |
| Inline image occurrences | 63,733 |
| Unique inline images by content hash | 770 |
| Total inline-image Base64 stored | 3.54 GiB |
| Unique inline-image Base64 | 0.21 GiB |
| Duplicate inline-image Base64 | 3.33 GiB |
| Inline-image duplication factor | approximately 17x |
| Inline-image Base64 inside compacted records | 2.49 GiB |
| Inline-image Base64 inside subagent rollouts | 2.99 GiB |

The first record of affected child rollouts identifies thread_source: "subagent" and a parent thread. In depth-1 children, the new session_meta is followed by an almost complete serialized prefix of the parent rollout before the child-agent instructions. Parent calls also show fork_turns: "all".

This supports the same amplification chain reported here and in #34268:

Long-lived parent history accumulates append-only events and compaction checkpoints.
compacted.payload.replacement_history retains inline data:image/...;base64,... payloads.
Ultra proactively spawns many subagents.
Full-history forks serialize the inflated parent history into each child rollout.
Later compactions and descendants repeat the already persisted history.

The important point in this reproduction is that actual child-specific work accounts for only a small minority of the child rollout bytes. The storage growth is dominated by inherited persisted context rather than unusually large subagent output.

Expected behavior:

Store binary image content once and reference it by content hash or file path.
Omit or replace historical inline image payloads during compaction.
Use a bounded/text-only handoff for proactive subagents instead of full append-only rollout inheritance.
Avoid persisting historical compaction checkpoints and event streams repeatedly in every child.
Add per-session/global storage limits and a visible warning before disk usage becomes critical.

I am not attaching raw rollout files because they contain private conversations and screenshots. I can provide additional redacted structural counts, record-size distributions, and parent/child metadata if useful.

fringehush-gif · 28 days ago

Windows corroboration from Codex Desktop 26.721.4979.0, reported without attaching or sharing the private session:

One long-lived rollout is ~1.83 GiB and contains 420 JSONL records/lines with data:image markers and 227 with structured input_image markers.
A second long-lived rollout is ~2.67 GiB with 734 and 624 corresponding marker-bearing records/lines.
A live read-only process snapshot showed ~3.61 GiB grouped private resident memory: renderers ~1.47 GiB, app-server ~1.38 GiB, Electron main ~0.57 GiB, while active MCP processes were only ~48 MiB.
The parent repeatedly carried ~170–180k input tokens, mostly cached history.
A bounded V2 subagent spawned with omitted history scope inherited the large parent history; the same class of audit explicitly spawned with fork_turns: "none" began at ~27k input tokens.

These are structural counts, not claims that every marker is a unique image or that every rollout byte is resident. They do reinforce the issue's two mechanisms on Windows: image-heavy persisted history amplifies Desktop RAM/disk use, and default full-history subagent forks multiply avoidable context.

A fresh task is not an adequate product remedy for users who deliberately keep long-lived evidence-bearing conversations. The missing recovery/control surface is a supported, previewable, atomic in-place dehydration operation that externalizes/deduplicates old images and bulky tool output while preserving the visible conversation and compact semantic evidence. Full-history subagent inheritance should also be explicit, with none, summary-only, or last-N as safer defaults plus a pre-spawn inherited-token/byte estimate.

I am withholding session IDs, paths, images, and raw transcripts because the affected history contains private work.

##Non-AI update that Codex/ChatGPT (or whatever we call it as of late july) was to polite to add:

There are several corroborating and reproducible issues and symptoms that in different ways have this issue and related ones nailed down, and after reading up a bit it seems to be both cross-platform, have several underlying causes, consume not only local resources but also my precious tokens. There are seemingly also several solutions that users have reported. Or there were anyway, at some point in time...

Gigantic inline files? Let's add a natural language prompt, a hook, a script to track and stop it, or maybe some sort of clean up after the fact. Check.
Your quite expensive token budget being consumed at an alarming rate? Hard to quantify without the proper metrics, so let's design something that tries to track and identify that. Pretend to know what is going on while we spam new threads and pay a bit more. Nice. I am so clever. Not silly at all.
Your perfectly adequate amount of storage or memory suddenly not being quite enough? Well, I'm sure there is a perfectly reasonable explanation, like you know, the new subagent system, previously constrained by me to use cheaper models and a small prompt, suddenly spawning the most expensive model and eating the whole conversation and, allegedly (In a semi-trope tone, but at the same time, who knows...), huge inline images and all. Nah, It's probably Crysis running silently in the background or something.

I like progress. I like the new models. I sort of like the new way agents cooperate. I like the fast moving pace. I do not like spending money diagnosing and fixing the product I am using with the money I already paid for the product, then only to have the rug pulled out from under me, forcing me to accept nonsense or burn even more tokens.

I expect a certain degree of changes occurring this early in a developing product and thus I, and obviously many others as well, have taken precautions to mitigate whatever slowdown and resource eating monstrosity we are currently faced with. Reasonable people accept mistakes and bugs even in normal software, not to mention in the middle of a cool cutting edge AI-fueled project or a weird experiment, and neither can be avoided. They can also be fixed.

In the system, our own or others, we expect and even plan for bugs. Bugs can be squashed. That we like. Monsters, meanwhile, live under the bed where they belong. Reasonable people know and expect this, and the two are inherently different and should not, and must not, be conflated.

Granted I probably should never have done this in the first place. I should have waited a few years instead of paying for a rolling experiment. I don't often complain openly or even officially, I'd rather thinker myself, but sometimes you just need to attach a punchline to your (hopefully) useful report.

I just want to build cool things, and I am not smart enough nor do I have the patience, to learn and do this myself. I would rather take up fishing. But since my dear agents are working away at the monstrosities I might as well complain a little. Fortunately the world have more than enough energy supply at the moment. And we of course have all the excess compute capacity we need. And my apartment is cold anyway, so I might as well crank the clock speeds to heat things up a bit. July 2026 is the perfect date really.

If you live under the bed.

Coldain · 25 days ago

Independent recurrence on a newer Desktop build (2026-08-02)

I hit the same failure class on a newer build than the original report:

ChatGPT macOS app 26.727.51351 (build 6119)
bundled codex-cli 0.146.0-alpha.9.2
macOS 27.0 (26A5388g), Apple Silicon

Direct, content-free observations:

The Data volume reached 99–100% capacity; an initial producer inspection failed with No space left on device.
~/.codex was 203,239,756 KiB; ~/.codex/sessions was 194,482,836 KiB across 1,328 JSONL files.
495 closed session files exceeded 100 MB and collectively occupied 168,879,984,663 bytes (157.28 GiB).
19 session files were still open, totaling about 9.88 GiB. One older open rollout grew by 34,502,809 bytes during the diagnostic window.
The Desktop app-server was observed near 120–124% CPU with roughly 6.5–8.5 GB RSS before cleanup.

Containment was deliberately narrow: I permanently removed only closed regular session JSONL files above 100 MB and preserved every open session, project, image, model cache, and raw source. Free space rose from 9.5 GiB to 171 GiB; the sessions directory fell to about 29 GiB. I did not inspect or attach rollout contents and am not sharing session IDs.

I have not independently attributed bytes to the screenshot/compaction fields described in the original report, so this is evidence of a newer-build recurrence of the storage/open-writer failure class, not a new root-cause claim. Since 0.146.0-alpha.9.2 / app 26.727.51351 is newer than the versions in the issue, could maintainers confirm whether the intended fix had shipped in this build?

Even with the amplification bug fixed, the incident suggests durable safeguards are still needed: per-session/global quotas, visible storage usage, a critical-disk warning/pause, stale-writer ownership/cancellation, and a supported safe-prune flow that explains resumability impact.

pioneer-genie · 24 days ago

Independent reproduction on a newer stable CLI build:

Codex CLI: 0.146.0
macOS: 26.6 (25G72), arm64
Originator: codex-tui

Storage impact

~/.codex: 80.94 GiB
~/.codex/sessions: 77.02 GiB across 620 rollouts
Subagent rollouts: 324 files / 64.13 GiB
77 rollouts were at least 500 MB; 8 were at least 1 GB
generated_images: an additional 2.88 GiB

Additional payload path observed

A representative 717.29 MiB subagent rollout contained:

204 event_msg/image_generation_end records: 628.85 MiB
20 records containing image_url: 79.31 MiB
Combined image-bearing share: 98.73%

This case is not limited to compacted.payload.replacement_history: image_generation_end.payload.result itself stores multi-megabyte image data. Three sibling subagent rollouts from the same parent each began with an identical 3,850,416-byte payload.result value (verified by SHA-256), confirming that the image result was materialized separately in every fork.

Cleanup result

After checking open writers, I removed all 317 closed subagent rollouts through the supported codex delete --force <session-id> path. Seven open subagent rollouts (4.21 GiB) were intentionally retained.

~/.codex: 80.94 → 21.02 GiB
~/.codex/sessions: 77.02 → 17.10 GiB
No deleted-but-open rollout inode remained
User sessions and generated_images were not removed

No raw rollouts, prompts, paths, or image data are being shared.

shleder · 14 days ago

A session store reaching ~165 GiB with screenshot data re-persisted through compaction and inherited by subagent forks is a strong real oversized-history pattern.

I’m testing Codex Rescue’s bounded local parser on cases like this. It does not externalize screenshots, compact the rollout, or alter fork history, and it cannot fix Codex’s storage amplification. The original files remain untouched; the useful result is a safe diagnosis from metadata and record boundaries only.

If one affected rollout is still retained, could you try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Please share only sanitized output—no raw rollout, images/base64, SQLite files, prompts, repository content, local paths, or secrets.

https://github.com/shleder/codex-rescue

mik-0 · 9 days ago

Reproduced on Codex Desktop 26.810.52044, bundled codex-cli 0.148.0-alpha.9, macOS 26.2 arm64.

Our ~/.codex/sessions reached 42.52 GiB, reducing free disk from 50+ GiB to 3.1 GiB and putting the Data volume at 100% capacity. A metadata-only audit found:

97 inactive subagent rollout files consumed 37.71 GiB
individual child rollouts ranged from roughly 0.4 to 2.21 GiB
three agents spawned in one batch produced 6.53 GiB that day
the session metadata identified these as subagent forks of the same enormous parent thread
the child rollouts were independently allocated files, not shared/deduplicated storage

No transcript contents were inspected. We recovered space only by deleting inactive subagent rollouts after excluding all currently open files and sessions from an unrelated protected workspace.

This needs a product-level safeguard, not user janitorial work: content-addressed/deduplicated inherited history and image payloads, bounded fork persistence, automatic GC for completed subagent rollouts, configurable retention/storage ceilings, and a warning before Codex silently fills the disk.

imnotsureyi-sys · 5 days ago

Independent Windows recurrence on a newer Codex Desktop build:

Codex Desktop package: 26.818.5229.0 (OpenAI.Codex_26.818.5229.0_x64)
OS: Windows x64
Model/mode: GPT-5.6 Ultra with proactive multi-agent
Parent rollout: 6,048,170,902 bytes (5.6328 GiB), from a long-lived image-heavy localization/review thread

A single three-subagent fan-out with full inherited history created three child rollouts almost immediately:

| Child | Bytes |
|---|---:|
| 1 | 3,718,030,939 |
| 2 | 3,718,068,201 |
| 3 | 3,718,018,234 |
| Total | 11,154,117,374 bytes (10.39 GiB) |

The timestamps were approximately one minute apart, and each file reached its multi-gigabyte size at creation rather than growing from child-specific work. The three children were read-only audit tasks; their own output was tiny. This directly indicates that inherited parent history was physically materialized into every child rollout.

At the larger incident scale on this machine:

System drive capacity: approximately 835.81 GiB
%USERPROFILE%\.codex: approximately 304.41 GiB
sessions: approximately 222.56 GiB
archived_sessions: approximately 17.08 GiB
The system drive reached zero free space and patch/build operations failed with insufficient-disk-space errors.

A metadata-only cleanup found many completed subagent rollouts containing inherited image history. Removing only validated inactive child rollouts recovered more than 200 GiB. The active parent conversation, project files, state DB, and unrelated sessions were retained.

No raw rollout is attached because it contains private screenshots, prompts, and local paths. The measurements above were collected from file metadata only.

This newer-build recurrence reinforces the need for:

content-addressed storage for images and other binary payloads;
parent-history references or a bounded summary handoff instead of copying full rollout bytes into every child;
automatic GC/retention controls for completed subagent sessions; and
a visible storage warning or hard safety ceiling before Codex fills the system drive.

romainsimon · 3 days ago

Additional real-world data point from long-running Codex Desktop usage on macOS (measured 2026-08-25):

| Local Codex session storage | Size |
|---|---:|
| Active sessions (854 files) | 29.7 GiB |
| Archived sessions (517 files) | 26.2 GiB |
| Total session history | 55.9 GiB |

The largest active rollout was 4.35 GiB and the largest archived rollout was 3.11 GiB. Archiving sessions did not reclaim disk space. The machine reached approximately 3.7 GiB free before manual investigation.

I have not yet verified whether repeated inline Base64 screenshots are the cause in these particular rollouts, so I am reporting the measured storage impact rather than claiming the same root cause.

It would help to have:

per-task and global session-storage limits or rotation;
deduplication/external references for binary payloads;
a storage dashboard showing active and archived usage;
safe cleanup controls and a warning before free disk space becomes critical.

Project names and session contents are intentionally omitted.

edwardswhiskeyblues-alt · 2 days ago

Independent Windows recurrence on a newer Codex Desktop build. This is a metadata-only report: no rollout contents, prompts, local paths, project names, raw logs, or account identifiers are included.

Environment

Windows 11 Pro x64, version 10.0.26200 (build 26200)
Codex Desktop package 26.820.7780.0
AppX package status: Ok
System drive capacity: 237.18 GiB

User-visible incident

On 2026-08-26, while no user-initiated Codex turn appeared active and the device was running on battery, disk active time rose abruptly to 100%. The system experienced blocked/stalled processes, a recurring busy cursor at roughly one-second intervals, and sustained fan/thermal activity. Codex then failed to start normally and had to be uninstalled and reinstalled from the shell. The intermittent busy cursor and elevated background activity remained visible for some time after reinstall.

This symptom overlaps the Windows idle/stutter reports in #38719. I am not claiming that the session store has been proven to cause the 100% disk event; the storage measurements below were discovered during the subsequent read-only investigation and may be a cause, amplifier, or separate retention problem.

Local session-storage measurements

%USERPROFILE%\.codex\sessions: 104 JSONL rollouts totaling 23.426 GiB
85 rollouts not modified since 2026-08-24: 21.88 GiB
Eight largest rollouts: 6.58, 4.19, 2.17, 1.43, 1.42, 1.19, 0.97, and 0.73 GiB
Total %USERPROFILE%\.codex profile observed during the audit: approximately 24.68 GiB
The current incident-reporting thread itself was only approximately 17.1 MiB

The large rollouts were not opened or structurally inspected, so this report does not assert that repeated inline screenshots are their specific byte-level cause. It does independently confirm that a relatively small number of Codex Desktop session files can silently consume tens of gigabytes on Windows, including on build 26.820.7780.0.

Product impact and requested safeguards

Surface active and archived session-storage usage in the UI.
Add per-session and global storage warnings/limits before the system drive is pressured.
Provide a supported, history-preserving compaction/export/cleanup workflow.
Avoid eager loading, migration, replay, or indexing of multi-gigabyte completed rollouts during startup, update, or idle operation.
Rate-limit and expose progress for any background session maintenance.
Deduplicate or externalize repeated binary payloads where the mechanism described in this issue applies.

A private in-app feedback report containing the relevant Codex session/app logs was submitted separately. Its identifier is intentionally omitted from this public comment but can be provided to OpenAI maintainers if required.

shleder · 1 day ago

For people measuring tens of GiB in this thread: before any bulk deletion, vetto rescue --json scan produces a bounded per-session byte inventory straight from disk (read-only). That separates genuinely oversized rollouts from index noise when deciding what to archive.