The provided document details a critical performance bug (#34061) in the Codex CLI (v0.144.6) where subagent session logs caused near-total disk exhaustion on macOS. The issue involves the uncontrolled generation and persistence of JSONL session files, which consumed approximately 755 GiB of storage across 2,393 subagent files spawned from a single resumed parent thread.

Core Issues and Technical Observations

The investigation identified an "event amplification" phenomenon where high-frequency telemetry and state snapshots were stored in an unoptimized, unbounded manner. Diagnostic analysis revealed several specific technical failure modes:

• Excessive Event Frequency: A single child session running for ~199 seconds generated 353,255 JSONL records. This included 185,461 event_msg/token_count records and 36,295 event_msg/patch_apply_end records, indicating a lack of rate-limiting or coalescing for high-frequency internal events.
• Compaction and Payload Bloat: The persistence mechanism failed to implement deduplication. Large compacted records (snapshots of state) and custom_tool_call_output data were stored in full within each individual session file rather than being referenced or content-addressed. One representative session reached ~925 MiB, with 175 compacted records accounting for over 571 MiB.
• Resume Lifecycle Leak: The codex resume command appears to trigger a leak where long-running parent threads continuously spawn new subagent logs. This effectively "replicates" parent-level state into every child session, leading to exponential growth in local metadata storage.
• Resource Exhaustion: Because these processes held file handles open for the duration of the execution, the system was unable to reclaim space, leading to a state where the APFS Data volume reached 99–100% capacity.

Quantitative Metadata Analysis

The data illustrates a pattern of runaway persistence. Analysis of the affected files shows a sharp acceleration in storage growth over nine days in July 2026. A single parent thread ID (019ee8d1-...) was linked to 731.5 GiB of log data. The intensity of the logging can be expressed as:
$$R_{total} = \sum_{i=1}^{n} \left( \frac{\Delta B_i}{\Delta t_i} \right)$$
Where $\Delta B$ represents the byte accumulation and $\Delta t$ the duration. In the observed cases, this reached approximately $2.31 \text{ MiB/s}$ per child process, with event throughputs exceeding $1,770 \text{ records/s}$.

Recommended Remediation and Safeguards

The reporter proposes several technical mitigations to enforce bounded resource usage:

1. Quota Management: Implementation of configurable global and per-session storage quotas.
2. Deduplication: Transitioning to content-addressing for state snapshots to prevent redundant storage of compacted or tool_output records.
3. Telemetry Coalescing: Replacing high-frequency token_count events with summarized or throttled data points.
4. Automatic Rotation: Integration of age or size-based retention policies to prevent historical logs from exhausting the primary filesystem.
5. Diagnostic Feedback: The introduction of "Codex doctor" commands to safely identify and prune sessions, providing the user with visibility into disk usage before the system reaches critical capacity.