Insane Codex Disk Usage from Subagents

[jezell]

What version of Codex CLI is running?

0.144.6

What subscription do you have?

Pro

Which model were you using?

gpt-5.6

What platform is your computer?

macos

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

Subagents are eating my hard drive alive with session logs

What steps can reproduce the bug?

Codex CLI subagent session logs consumed ~755 GiB and nearly exhausted a 1.8 TiB disk

Summary

Codex CLI persisted approximately 755 GiB of JSONL session data under $HOME/.codex/sessions. Approximately 731.5 GiB of the logical file size is attributable to 2,393 subagent session files spawned from a single resumed parent thread.

The problem is not primarily one malformed or unusually large JSON record. Representative sessions show either extremely high event volume or repeated retention of large compaction/tool-output records:

• One child session ran for 3 minutes 19 seconds and wrote 483,714,063 bytes across 353,255 valid JSONL records—approximately 2.31 MiB/sec and 1,770 records/sec.
• Another session grew to 925,599,939 bytes; in that file, 175 compacted records accounted for 571,600,883 bytes and 27,848 custom_tool_call_output records accounted for 211,681,025 bytes.
• July contained approximately 2,931 session files, including 797 files larger than 400 MiB.

This nearly exhausted the system's APFS Data volume. During diagnosis, df reported only 10–32 GiB available and 99–100% capacity used.

Severity and impact

Suggested severity: Critical / P1 for affected users

• The Codex session store grew to approximately 760 GiB total, with session JSONL files accounting for approximately 755 GiB.
• The user's entire home directory occupied approximately 1.46 TiB; Codex session data alone accounted for roughly half of it.
• The 1.8 TiB Data volume reached 99–100% reported capacity.
• Continued logging risks failed builds, corrupted application state, OS instability, and data loss due to complete disk exhaustion.
• The affected processes were still actively holding session JSONL files open during diagnosis.
• Removing these files would likely make historical sessions unavailable to codex resume, so cleanup has a product-data-loss cost even though the files are not project source files.

Environment

Captured on 2026-07-18 in the America/Los_Angeles timezone.

Component	Value
Current Codex CLI	codex-cli 0.144.6
Versions recorded in affected July session metadata	0.142.4 through 0.144.6
Primary affected versions by file count	0.144.1 (1,138), 0.144.4 (819), 0.144.5 (461)
Originator	Mostly codex-tui (2,870 files); codex_exec (62 files)
OS	macOS 15.5 (24F74)
Architecture	arm64
Node.js	v26.0.0
Filesystem	APFS Data volume, 1.8 TiB
Working directory in representative session metadata	$HOME/office
History mode in representative session metadata	legacy
Explicit history/session persistence config	None found in $HOME/.codex/config.toml

Observed behavior

Disk usage

760G  $HOME/.codex
755G  $HOME/.codex/sessions
734G  $HOME/.codex/sessions/2026/07

July's growth accelerated sharply:

Date (2026)	Session files	Files >400 MiB	Allocated size (approx.)
Jul 10	50	0	2.8 GiB
Jul 11	473	0	109.1 GiB
Jul 12	506	0	149.2 GiB
Jul 13	291	1	50.6 GiB
Jul 14	313	4	88.4 GiB
Jul 15	340	265	108.6 GiB
Jul 16	355	263	109.0 GiB
Jul 17	300	189	81.7 GiB
Jul 18, partial day	137+	75+	33.5+ GiB

Counts for the partial day continued increasing during diagnosis.

Single-parent concentration

Parsing only the first session_meta record from each July file showed:

source: subagent
parent_thread_id: 019ee8d1-94c0-7090-a65a-faeeab8c626d
child session files: 2,393
combined logical size: 785,467,490,368 bytes (~731.5 GiB)

The parent was actively running as a resumed Codex TUI session:

codex resume 019ee8d1-94c0-7090-a65a-faeeab8c626d

At capture time, that resumed process had been running for approximately 23 hours. Another codex resume process had been running for approximately 22 hours and held open a separate 6.9 GiB session file.

Representative high-event-volume child session

Representative child session metadata:

session id: 019f76a8-32b1-77e3-854c-4fb405a58155
parent thread id: 019ee8d1-94c0-7090-a65a-faeeab8c626d
source: subagent/thread_spawn
depth: 1
originator: codex-tui
CLI version: 0.144.5
history mode: legacy
started: 2026-07-18T19:16:06.710Z
last record: 2026-07-18T19:19:26.008Z
duration represented: ~199.3 seconds
file size: 483,714,063 bytes
records: 353,255
JSON parse errors: 0

Largest record categories by aggregate bytes:

JSONL record category	Record count	Aggregate bytes	Largest record
event_msg/token_count	185,461	139,268,416	815
compacted	1,618	121,571,279	105,608
event_msg/patch_apply_end	36,295	110,668,600	521,129
event_msg/agent_message	104,653	41,623,387	2,780
response_item/message	9,947	34,412,319	34,584
world_state	607	18,638,285	34,723
turn_context	5,322	11,032,351	2,915
event_msg/task_complete	3,682	4,879,881	2,870
event_msg/task_started	3,718	866,294	233

This implies severe event amplification. The file does not depend on a single giant line; many categories are being emitted thousands to hundreds of thousands of times during a short-lived subagent task.

Representative large-payload session

A second file, 925,599,939 bytes, showed a different but related persistence pattern:

JSONL record category	Record count	Aggregate bytes	Largest record
compacted	175	571,600,883	5,986,172
response_item/custom_tool_call_output	27,848	211,681,025	5,586,220
response_item/reasoning	27,400	50,952,588	5,164
response_item/custom_tool_call	27,841	31,213,363	35,226
event_msg/token_count	31,379	22,580,057	755
event_msg/patch_apply_end	5,137	14,546,399	33,282

This suggests that both event frequency and repeated retention of large compacted/tool-output payloads contribute to growth.

Expected behavior

• Session persistence should remain bounded relative to actual user-visible conversation and tool activity.
• A subagent lasting about three minutes should not persist hundreds of megabytes or hundreds of thousands of events under normal use.
• Repeated subagent spawning should not replicate parent state, compaction payloads, tool outputs, or event streams into every child log without bounds.
• Codex should protect the host from disk exhaustion through quotas, rotation, deduplication, compression, backpressure, or a clear warning before storage becomes critical.
• codex resume should not allow a long-running thread to generate hundreds of gigabytes of local history silently.

Actual behavior

• A single resumed parent thread produced 2,393 child JSONL logs totaling approximately 731.5 GiB.
• Hundreds of child session files were created per day.
• Many individual child sessions grew to approximately 400–500 MiB within minutes.
• At least one historical session file reached 6.9 GiB and remained open for writing by a resumed Codex process.
• No storage warning, retention limit, or automatic pruning was observed before the Data volume reached 99–100% capacity.

Reproduction / observed workflow

This is an observed reproduction rather than a minimal deterministic reproducer:

1. Start Codex TUI in a local project.
2. Work in a thread that uses collaboration/subagent spawning.
3. Resume the long-running parent thread with codex resume <thread-id>.
4. Allow the resumed process to run for many hours and continue spawning depth-1 subagents.
5. Monitor $HOME/.codex/sessions/YYYY/MM/DD.
6. Observe hundreds of new child JSONL files per day, many hundreds of MiB each.
7. Aggregate session_meta.source.subagent.thread_spawn.parent_thread_id; most affected files resolve to the same parent.

The exact prompt/task content has intentionally not been included. The issue is visible from metadata, event counts, byte counts, and process/file-handle information alone.

Suspected failure modes

These are hypotheses based on the persisted metadata and should be verified by the Codex team:

1. Child event fan-out: parent or sibling events may be replicated into each subagent's JSONL stream.
2. Unbounded task/event loop: task_started, task_complete, agent_message, patch_apply_end, and token_count events are emitted at implausibly high rates.
3. Compaction persistence amplification: compacted state may be repeatedly stored in full instead of referenced, deduplicated, or replaced.
4. Tool-output replay: custom tool outputs may be retained repeatedly across compactions or child sessions.
5. Legacy history interaction: representative sessions report history_mode: legacy; no explicit user history configuration was found.
6. Resume lifecycle leak: long-running resumed sessions may keep spawning or persisting child state after user-visible work has completed.

Requested investigation

Please investigate:

• Why one parent thread spawned 2,393 persisted child sessions totaling ~731.5 GiB.
• Whether parent/child/sibling events are being copied into multiple JSONL files.
• Whether compacted records retain repeated full snapshots or previously persisted tool output.
• Why a three-minute child task emits ~353,000 records, including ~185,000 token-count events and ~36,000 patch-apply completion events.
• Whether completed subagent sessions continue receiving or retaining events.
• Whether history_mode: legacy is expected for these versions and whether it changes persistence behavior.
• Whether the resume path leaks task/event subscriptions across subagent generations.

Recommended safeguards

Independent of the root-cause fix, consider:

• A configurable per-session and global session-store quota.
• Automatic rotation/compression and an age/size-based retention policy.
• Deduplication or content-addressing for compaction snapshots and tool outputs.
• Rate limiting or coalescing high-frequency telemetry-like events such as token counts.
• A warning and pause when Codex storage exceeds a threshold or the disk approaches exhaustion.
• A built-in command to report and safely prune session storage while explaining the impact on resumability.
• Detection of anomalous event rates or session growth, with a diagnostic bundle users can attach to reports.

Privacy-safe diagnostic commands

These commands report sizes and metadata without printing prompts, messages, tool arguments, or tool outputs.

# Overall usage
du -sh "$HOME/.codex" "$HOME/.codex/sessions"
df -h /System/Volumes/Data

# Counts and large files
find "$HOME/.codex/sessions" -type f | wc -l
find "$HOME/.codex/sessions" -type f -size +400M | wc -l

# Size by day
du -k -d 3 "$HOME/.codex/sessions" 2>/dev/null | sort -n | tail -30

# Open session files and their writer processes
lsof +D "$HOME/.codex/sessions/2026/07/18" 2>/dev/null

# Read only selected, non-content session metadata from the first record
head -1 path/to/session.jsonl | jq '{
  timestamp,
  type,
  payload: {
    id: .payload.id,
    cli_version: .payload.cli_version,
    originator: .payload.originator,
    source: .payload.source,
    history_mode: .payload.history_mode
  }
}'

Suggested attachments

Safe to attach after review:

• Output of the size/count commands above.
• The redacted session_meta line for the parent and one representative child.
• Record-type count/byte aggregations that do not include payload content.
• lsof output showing active writers, with username/path redacted.
• Codex version and macOS version output.

Do not attach the full JSONL files without reviewing them. They contain conversation history, instructions, tool inputs/outputs, filesystem paths, and other potentially sensitive content.

Cleanup caveat

The session JSONL files appear to support session history and codex resume. Before deleting them:

1. Stop the processes actively writing the affected sessions.
2. Preserve a small, redacted diagnostic sample if the Codex team requests it.
3. Assume deleted sessions may no longer be resumable or visible in local history.
4. Verify that disk space is actually released after the writers exit.

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.

• Rapid ~/.codex growth from retained CLI session rollouts and active SQLite logging #33644

Powered by Codex Action

[jezell]

Seems to be what you get when you combine long running sessions like this:

with subagents.

[jezell]

Asked whether subagents are forking the context.

• Yes—in your affected run, Codex copied a large filtered snapshot of the parent context into almost every forked child.

It is conditional, not universal:

• MultiAgent V1: fork_context=true creates a full-history fork; default is false.
• MultiAgent V2: omitting fork_turns defaults to "all", which creates a full-history fork.
• fork_turns:"none" starts without parent conversation history.
• fork_turns:"N" copies only the last N turns.

The Rust path is:

1. spawn_agent maps "all" or fork_context=true to SpawnAgentForkMode::FullHistory. V2 spawn handler (https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs), V1 spawn
   handler (https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/handlers/multi_agents/spawn.rs)

2. It flushes the parent rollout to disk.

3. It loads the parent’s model context. With your history_mode: legacy, this uses include_history: true.

4. Unless LastNTurns was requested, it does not truncate the history.

5. It constructs the child with InitialHistory::Forked(forked_rollout_items). Fork implementation (https://github.com/openai/codex/blob/main/codex-rs/core/src/agent/control/spawn.rs)

“Full history” is filtered, but still very broad. It retains:

• System, developer, and user messages
• Final assistant messages
• Compaction records
• All EventMsg records in legacy mode
• Session metadata
• Turn context and world state

It removes most raw tool-call/output and reasoning records, although those may remain embedded in compaction snapshots. Paginated history has an additional filter for token-count and several other event types;
legacy history does not.

On your machine, the affected parent rollout contains 2,322 detectable spawn_agent calls:

Setting Calls
━━━━━━━━━━━━━━━━━━━━ ━━━━━━━
fork_context=true 1,932
──────────────────── ───────
Setting omitted 234
──────────────────── ───────
fork_context=false 156

That matches the 2,393 child logs totaling approximately 731.5 GiB. A representative child JSONL contains both the child and parent session_meta, confirming inherited history was serialized into the child file.

This also corrects part of the earlier bug report: the 353,255 records in a three-minute child were probably copied during initialization, not all newly generated during those three minutes. The core bug is
primarily repeated full-history materialization, compounded by legacy mode retaining event records.

There is already an upstream issue describing this exact large-parent snapshot risk: openai/codex#14981 (#14981).

The immediate workaround is to use fork_context:false on V1 or fork_turns:"none"—or a small bounded number—on V2.

[jezell]

Subagent session cleanup script (python) if anyone runs into this and needs to free up the space:

https://gist.github.com/jezell/6ad849791fc64d61d1ef1e66ad788eb5

[georgfranz]

I can independently reproduce this on Codex CLI 0.144.5 on Linux x86_64 with gpt-5.6-sol, ultra effort, MultiAgent V2, and legacy history.

One child rollout contained:

• 53,897 valid JSONL records
• 118,285,692 bytes
• child session_meta at line 1
• embedded parent session_meta at line 2
• first inter_agent_communication_metadata record with trigger_turn: true at line 53,749

The persisted prefix before the child’s first actual turn therefore contained 53,748 records and 117,949,758 bytes: 99.72% of both the records and bytes in the child file.

Reproduction

1. Build up or resume a sizeable parent thread using history_mode: legacy.
2. Spawn a V2 subagent with fork_turns: "all" or omit it, since all is the default.
3. Inspect the child rollout JSONL.
4. Observe that almost the complete parent history is serialized before the child’s first turn.

Expected behavior

Inherited context should be referenced, content-addressed, paginated, or otherwise bounded. The child rollout should primarily contain child-owned records.

Actual behavior

Legacy full-history forks physically materialize the parent rollout into every child file. Repeated spawning therefore causes multiplicative disk growth.

Downstream consumers also require special replay detection to avoid interpreting the copied prefix as new events.

Suggested improvement

The current source contains special handling for paginated subagents, but existing local sessions remain in legacy mode.

Could paginated or reference-based storage become the default, with a size guard or warning for legacy full-history forks?