›_ Codex Issues
Codex Issues / #34061

Insane Codex Disk Usage from Subagents

Open 💬 5 comments Opened Jul 18, 2026 by 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_

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗