Multi-agent fan-out duplicates full parent context into every subagent rollout file - 22 files x 9.4 GB = 208 GiB; codex.exe reaches 14 GB working set

Prepared : 2026-08-18, revised 2026-08-19 with root-cause evidence and
mitigation-test results
Reporter : Codex Desktop user, Windows 11

--------------------------------------------------------------------------------

1. REVISION HISTORY (kept for honesty about what changed)

--------------------------------------------------------------------------------
Draft 1 described a memory spike with an unknown disk-I/O source.
Draft 2 identified the file being read and measured the session store.
This draft adds three things:
(a) the mechanism, measured from session_meta and record types:
multi-agent fan-out amplification of "compacted" context snapshots;
(b) results of quarantining the 22 oversized files, which removed the
symptoms entirely (before/after numbers in section 8);
(c) observed app behaviour when a session file is missing (clean failure).

--------------------------------------------------------------------------------

1. ENVIRONMENT

--------------------------------------------------------------------------------
App version : OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0 (Microsoft Store)
CLI/runner : codex-command-runner-0.148.0-alpha.15.exe
(session_meta reports cli_version 0.148.0-alpha.15)
OS : Windows 11 Home Single Language, 10.0.26200 Build 26200
CPU : AMD Ryzen AI 7 350 — 8 cores / 16 threads
RAM : 24 GB LPDDR5X-6400 (23.1 GB usable)
Disk : 975 GB volume

--------------------------------------------------------------------------------

1. SUMMARY

--------------------------------------------------------------------------------
Working in a multi-agent pattern (one orchestrator task spawning subagents),
Codex produced 22 rollout .jsonl files totalling 223,089,076,459 bytes
(207.77 GiB): one root session plus 21 depth-1 subagents, every subagent
carrying the same parent_thread_id.

Each subagent file is ~9.42 GiB REGARDLESS of how much work the subagent did.
A subagent that worked for ~2 minutes received the same record-set as its
parent — including 38 "compacted" records of ~31 MB each — written into its
rollout file within 3.5 seconds of spawn.

Consequences on this machine: codex.exe working set 8-14 GB while idle,
private bytes to 18.9 GB, system RAM 91-98%, one session file read at
200-270 MB/s with no user activity, whole machine unresponsive.

Quarantining the 22 files (move, not delete) removed every symptom;
numbers in section 8.

--------------------------------------------------------------------------------

1. MEASURED — THE SESSION STORE

--------------------------------------------------------------------------------
Directory: %USERPROFILE%\.codex\sessions (before quarantine)

Total 223,390,876,268 bytes (208 GiB), 73 files
>= 8 GiB 22 files — total 223,089,076,459 bytes, mean 9.44 GiB
100 MiB - 1 GiB 1 file
1 - 100 MiB 11 files
< 1 MiB 39 files

Structure of the root file (9.53 GiB, 15,703 lines):
longest line 47.46 MB
mean line 636 KB
10 MB - 1 GB lines 241 lines <- ~8.4 GB of the 9.5 GB total

Record types in the first 1.2 GB of the root file:
"compacted" records (full context snapshots) account for 96.2% of the bytes:
38 records averaging ~31 MB, largest 47.46 MB. The remainder is
response_item/message, turn_context, world_state, event_msg, token_count.

Only sizes, line lengths, record type names and counts were inspected.
No conversation content is included here.

--------------------------------------------------------------------------------

1. MEASURED — FAN-OUT STRUCTURE (from session_meta, first line of each file)

--------------------------------------------------------------------------------
Across the 22 oversized files:

1 root : parent_thread_id absent
21 subagents: all depth = 1, ALL sharing the same parent_thread_id
(019fdb5f-c7ff-7a13-85e4-c3dad47a51a2 — the root above)
agent_path examples: /root/arch_access_packet, /root/eng_access_packet,
/root/domain_access_packet, /root/architecture_collaboration_flow
sizes : root 9.53 GiB; subagents 9.416-9.46 GiB each — near-identical

Timing evidence from one subagent file: it received the same record counts as
the parent (38 compacted, 34 mcp_tool_call_end, 42 world_state,
177 turn_context, 598 token_count) with write timestamps spanning
06:21:38.298 -> 06:21:41.857 — i.e. ~9.4 GB written in 3.5 seconds at spawn,
for a subagent whose actual task lasted about two minutes.

Interpretation (this part is inference): at spawn, the parent's accumulated
context — dominated by repeated "compacted" snapshots — is serialised in full
into each child's rollout file. One oversized parent context is therefore
multiplied by the number of subagents: fan-out amplification.
21 x 9.4 GiB followed mechanically.

--------------------------------------------------------------------------------

1. MEASURED — RUNTIME SYMPTOMS (while the files existed)

--------------------------------------------------------------------------------
(a) Memory step change, local monitor, all rows PID 20568 (same process):

12:45:08 WS 179.5 MB Priv 129.3 MB <- last quiet sample
12:45:38 WS 9,660.2 MB Priv 9,671.3 MB <- +9,481 MB in <=30 s
12:47:08 WS 8,735.2 MB Priv 18,931.7 MB
12:48:38 WS 14,019.6 MB Priv 14,378.6 MB <- peak; system RAM 96.2%

Over 5.4 hours (641 samples): 27 separate episodes above 5 GB, alternating
with quiet periods at 0.6-0.7 GB / 0% CPU.

(b) Disk: Resource Monitor attributed a continuous 200-270 MB/s read of ONE
rollout file (dated 2026-08-07, mtime 2026-08-18) to System PID 4 —
consistent with memory-mapped access. The +9.48 GB working-set step closely
matches that file's 9.53 GiB size. codex.exe disk writes were ~0 throughout.
This correlation is strong but I have not proven the mapping itself.

(A counter-measurement caveat from an earlier draft stands: PerfProc
IOReadBytesPersec is logical I/O and was NOT used for any claim here.)

--------------------------------------------------------------------------------

1. STEPS TO REPRODUCE (pattern, not one-click)

--------------------------------------------------------------------------------

1. Use a long-running orchestrator task whose context has grown large enough

to contain many multi-MB "compacted" snapshot records. (Ours followed an
AGENTS.md instructing agents to read a full set of project control
documents at startup — a setup that inflates context quickly.)

1. From that task, spawn subagents (we had 21 over several hours, spawned

3-5 minutes apart).

1. Observe: each spawn writes a near-copy of the parent's record-set into the

child rollout file within seconds. File sizes do not scale with the
subagent's actual work.

1. Reopening/continuing sessions in this state produces multi-GB memory steps

and sustained reads of rollout files with no user input.

Precondition that matters: an accumulation of large "compacted" records in
the parent. Any account in that state should reproduce the multiplication.

--------------------------------------------------------------------------------

1. OBSERVED — BEHAVIOUR WHEN SESSION FILES ARE REMOVED

--------------------------------------------------------------------------------
After quarantining (moving) the 22 files to another folder on the same disk:

• Selecting one of the affected chats shows:

"Failed to resume chat — failed to resolve rollout path \\?\C:\...\
rollout-2026-08-07T15-38-35-...jsonl: file does not exist"
The app fails CLEANLY: no crash, no re-creation of files, no fallback
scanning. The error re-appears on every interaction with that chat tab,
which is noisy but harmless.

• New chats, single-agent work and subagent spawns all function normally.

This answers our own earlier question about deletion safety in practice,
though an official statement on what else references these files
(indexes, state DBs) would still be valuable.

--------------------------------------------------------------------------------

1. MITIGATION TEST — BEFORE / AFTER QUARANTINE (same machine, same workload)

--------------------------------------------------------------------------------
WITH 22 files present AFTER quarantine
codex.exe idle (46 min) 8,000-14,000 MB 274-357 MB, CPU 0.0%
disk read while idle 200-270 MB/s sustained <= 3.85 MB/s momentary
single small task (not measurable safely) session file 7.34 MB,
peak WS 490 MB
spawn 1 subagent child file ~9,416 MB child file 0.18 MB
written in ~3.5 s root file 0.22 MB

The subagent file-size difference is roughly 50,000x for comparable spawns.
All 22 quarantined files are preserved intact (SHA-256-verified manifest)
and can be provided for analysis through a private channel if useful.

--------------------------------------------------------------------------------

1. IMPACT

--------------------------------------------------------------------------------

• 208 GiB of disk consumed by conversation logs (21% of the volume).
• A single process reaching 40-60% of total RAM; system at 91-98% memory;

every application degrades, not just Codex.

• Multi-agent workflows — a headline feature — are the trigger, and the

cost is invisible: no in-app indication of session-store size or growth.

--------------------------------------------------------------------------------

1. QUESTIONS

--------------------------------------------------------------------------------

1. Is writing the parent's full record-set (including every historical

"compacted" snapshot) into each subagent rollout intended? Could children
reference the parent's records instead of duplicating them?

1. Why do "compacted" snapshots accumulate in the log (38 copies of ~31 MB

in one session) rather than superseding one another?

1. Is there any rotation/retention/size-cap policy for

%USERPROFILE%\.codex\sessions? 208 GB with no cleanup looks unintended.

1. When an old session is touched, is the whole rollout mapped/loaded?

Could it be streamed instead?

1. Would you add a visible session-store size / memory indicator so users

notice at 5 GB rather than at 95% system RAM?

1. Is deleting quarantined rollout files safe with respect to other state

(sqlite/index)? Practical behaviour (section 7) suggests yes; we kept
everything pending your reply, plus a root+child sample either way.

--------------------------------------------------------------------------------

1. HOW THIS DATA WAS CAPTURED

--------------------------------------------------------------------------------
Process/memory series: local PowerShell monitor (Get-Process, Win32_
OperatingSystem, PerfDisk PhysicalDisk _Total, PerfOS Memory) sampling
10-30 s; notify-only; no file paths or contents recorded.
File-level read attribution: Windows Resource Monitor, Disk tab.
Session store: file sizes, line lengths, session_meta structural fields
(id / parent_thread_id / depth / agent_path) and record TYPE counts only.
No conversation content was read into this report.
Quarantine verification: per-file SHA-256 over first 1 MiB + last 1 MiB +
length, cross-checked by two independent implementations.

CSV series, manifest, and a redacted trace are available on request.
Raw rollout files contain project data, so those would need a private channel.

--------------------------------------------------------------------------------
ADDENDUM (2026-08-19, from extracted logs)
--------------------------------------------------------------------------------
The orchestrator room ran a ~5-minute heartbeat (regular automated messages).
Combined with per-event "compacted" snapshot writes this explains continuous
file growth during periods with no user input.