Repository navigation
Codex Desktop: screenshots re-persisted in full on every compaction and inherited by subagent forks - ~/.codex/sessions reached ~165 GiB (95% base64 images) #35458
Description
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_urlwill contain repeateddata: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 -lWhat is the expected behavior?
- Compaction should not re-persist raw historical image payloads in full on every
compactedrecord. 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/sessionsgrowth 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 = 1inconfig.tomlcaps the fork multiplier (does not fix in-session duplication).- Monitor with
du -sh ~/.codex/sessionsandfind ~/.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>.
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
deat4 commentedon Jul 29, 2026
Additional Windows reproduction: #35470 reports the same compaction × subagent-fork amplification on Codex CLI 0.145.0.
Reported measurements:
.codex/sessionsThis 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 commentedon Jul 29, 2026
Hopefully this gets picked up and fixed by the @codex team soon!
rahul-tuladhar commentedon Jul 30, 2026
Independent macOS/Desktop reproduction on 2026-07-29, at substantially larger scale.
Environment
session_meta:0.146.0-alpha.3codex-cli 0.145.0Storage impact
~/.codex/sessions: approximately 489 GiBSeveral 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:
data:imageandimage_urlscreenshotmarkerscompactedmarkersthread_source: "subagent"forked_from_id/parent_thread_idpointing to the same long-lived parent threadThe first
session_metarecord 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 doctorcorrectly 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 commentedon Jul 30, 2026
Independent reproduction on a newer Desktop/CLI build
I can independently reproduce this issue on a newer build:
26.721.81911(build5973)0.146.0-alpha.3.126.4(25E246), arm64gpt-5.6-sol, Ultra, proactive multi-agentThe local Codex store grew from approximately 3 GiB at migration time on July 13 to 34 GiB on July 30. The current
~/.codex/sessionsdirectory is approximately 31 GiB.Privacy-safe structural analysis of the July rollout files produced these results:
compactedrecordscompactedrecordscompactedrecordsThe first record of affected child rollouts identifies
thread_source: "subagent"and a parent thread. In depth-1 children, the newsession_metais followed by an almost complete serialized prefix of the parent rollout before the child-agent instructions. Parent calls also showfork_turns: "all".This supports the same amplification chain reported here and in #34268:
compacted.payload.replacement_historyretains inlinedata:image/...;base64,...payloads.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:
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 commentedon Jul 30, 2026
Windows corroboration from Codex Desktop 26.721.4979.0, reported without attaching or sharing the private session:
data:imagemarkers and 227 with structuredinput_imagemarkers.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 commentedon Aug 3, 2026
Independent recurrence on a newer Desktop build (2026-08-02)
I hit the same failure class on a newer build than the original report:
26.727.51351(build6119)codex-cli 0.146.0-alpha.9.227.0(26A5388g), Apple SiliconDirect, content-free observations:
No space left on device.~/.codexwas203,239,756 KiB;~/.codex/sessionswas194,482,836 KiBacross 1,328 JSONL files.168,879,984,663bytes (157.28 GiB).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/ app26.727.51351is 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 commentedon Aug 3, 2026
Independent reproduction on a newer stable CLI build:
0.146.026.6 (25G72), arm64codex-tuiStorage impact
~/.codex: 80.94 GiB~/.codex/sessions: 77.02 GiB across 620 rolloutsgenerated_images: an additional 2.88 GiBAdditional payload path observed
A representative 717.29 MiB subagent rollout contained:
event_msg/image_generation_endrecords: 628.85 MiBimage_url: 79.31 MiBThis case is not limited to
compacted.payload.replacement_history:image_generation_end.payload.resultitself stores multi-megabyte image data. Three sibling subagent rollouts from the same parent each began with an identical 3,850,416-bytepayload.resultvalue (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 GiBgenerated_imageswere not removedNo raw rollouts, prompts, paths, or image data are being shared.
mik-0 commentedon Aug 18, 2026
Reproduced on Codex Desktop 26.810.52044, bundled codex-cli 0.148.0-alpha.9, macOS 26.2 arm64.
Our
~/.codex/sessionsreached 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: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.
RepressedAlliance commentedon Aug 23, 2026
Independent Windows recurrence on a newer Codex Desktop build:
26.818.5229.0(OpenAI.Codex_26.818.5229.0_x64)6,048,170,902bytes (5.6328 GiB), from a long-lived image-heavy localization/review threadA single three-subagent fan-out with full inherited history created three child rollouts almost immediately:
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:
835.81 GiB%USERPROFILE%\.codex: approximately304.41 GiBsessions: approximately222.56 GiBarchived_sessions: approximately17.08 GiBA 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:
romainsimon commentedon Aug 25, 2026
Additional real-world data point from long-running Codex Desktop usage on macOS (measured 2026-08-25):
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:
Project names and session contents are intentionally omitted.
edwardswhiskeyblues-alt commentedon Aug 26, 2026
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
10.0.26200(build26200)26.820.7780.0Ok237.18 GiBUser-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%USERPROFILE%\.codexprofile observed during the audit: approximately 24.68 GiBThe 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
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.
Adil2662 commentedon Sep 3, 2026
Whole-corpus measurement by requested fork mode on 0.153.0-alpha.5: full-history children median 377.65 MB vs 8.59 MB (recent N) vs 3.39 MB (none); one task family at 76 GB; copied bytes are the event stream, not the conversation
One long-lived Codex thread on my Mac, plus the subagents it spawned over four weeks, now holds 75.76 GB of JSONL under
~/.codex/sessions. The pattern is that every subagent spawned with full conversation history gets its own complete copy of the parent's history on disk, and the current desktop build still does this.Environment
history_mode: legacy, 945 MB todayObserved (read-only scan of 428 files, 9.66 million records, 0 invalid)
fork_turnsmode:allnonehistory_mode: legacy, with nohistory_baseor fork-ordinal field in their first record.Why it looks like inherited materialization. For one 541 MB child, 77.9% of its bytes are records (canonical hash, outer timestamp excluded) that already existed in the parent before the child's creation time. Files that could not have inherited from this parent match it at 0.2%, and
fork_turns: "none"children at 0.05%. The figure is a floor: inherited compaction records are reserialized on fork and cannot hash-match.What is actually being copied. Mostly the event stream, not model-facing history. The 541 MB child carries 804 of the parent's 810 world-state records, 39,052 of 39,384 token-count events, 6,065 of 6,184 screenshot-bearing MCP tool-completion events, and all 209 session-metadata records, but only 180 of 40,447 reasoning items. Across the directory, embedded image and audio strings are 31.8 GB (41.9% of all bytes) and MCP tool-completion events are 48.4 GB. The conversation is compacted; the diagnostics are duplicated wholesale.
Side finding. The parent serializes
permissions.approved_command_prefixes810 times, 89.5 MB in total, for two distinct arrays of 575 KB combined.Clue from the installed build. The desktop JavaScript selects legacy history unless the
codex_app_paginated_thread_history_v1experiment is on (default false), and the persistentthread/forkrequest carries no history-mode migration. The bundle shipsmigrate-rolloutsplus compression and lineage machinery, so this may be a rollout gate or an unconverted legacy root rather than missing code.Question. Is a legacy-mode root expected to keep producing fully materialized children on current builds, and is
migrate-rolloutsthe supported way to stop it?Not done, offered. No files were deleted and no migration was run. Happy to run the non-publishing
migrate-rollouts --jsoninspection on a copy of the directory and share the output, or raw logs through a private channel.Related. #35458 (three children of about 2.6 GiB each from one fork; same mechanism, smaller sample), #24948 and #34061 (sessions directory growth, requests for quotas and rotation), #38838 (request for
sessions prune), #20077 (spawn_agent defaults to a full-history fork, which is why 185 of this thread's 352 spawns wereall), #40890 (full-history forks after compaction), #38762 and #37673 (migrate-rollouts leaves subagent threads empty / drops records over 16 MiB, which is why I have not run it against the live directory). What this report adds to those: a whole-corpus measurement split by requested fork mode, the record-kind composition of the copied bytes, and proof that the current desktop bundle still does it.Evidence and scripts (sanitized: aggregate numbers only, no transcript text, thread IDs, paths, or hashes): https://gist.github.com/49c6106d0a974eb78e047bc3c7b9623b . It holds environment-evidence.json, temporal-check.json, evidence-summary.json (inventory, focus, scan totals, and the per-mode cohorts), and the read-only analyzer with its tests so anyone can rerun the measurement on their own store. Raw logs available through a private channel on request.
makhoulamal-del commentedon Oct 15, 2026
Urgent Windows Desktop incident report, submitted at the affected user's explicit request. Please escalate to the Desktop/runtime maintainers and engineering/product leadership. The user's work is stopped because of disk and memory pressure, and they need a supported way to prevent recurrence, not repeated manual cleanup.
Environment and impact (15 October 2026):
Content-free measurements:
Persistence/control gap:
Relationship to this issue:
This is additional Windows resource-pressure/storage-control evidence on a newer Desktop package. We have NOT independently quantified repeated image payloads or compaction/fork amplification in these particular files, so this is not a claim that the exact root cause in #35458 has been confirmed for this machine. Investigation must not itself produce more large local diagnostic archives or reproduction data on the affected disk.
Requested urgent response:
The problem remains unresolved. No private repository names, user-specific filesystem paths, session IDs, IP addresses, credentials, screenshots or raw logs are included in this report.