Codex Desktop subagent session logs grow to 145GiB from repeated compacted replacement_history

Codex Desktop subagent session logs grow to 145GiB due to repeated compacted replacement_history

Summary

Codex Desktop appears to persist full compacted.replacement_history snapshots repeatedly inside subagent rollout JSONL files. In one long parent thread with many subagents, this produced about 145.76GiB of subagent session logs while user/main session history for the same period was only about 5.5MiB.

This looks like a session-retention / compaction logging bug rather than useful work output growth.

Product / area

• Product: Codex Desktop app
• Platform: macOS
• Observed local CLI version: codex-cli 0.142.5
• Area: session storage, subagents, context compaction, retention policy
• Data sensitivity: raw session files may contain private user/project content; this report only includes aggregate/redacted evidence.

Duplicate check

Searched existing openai/codex issues for:

• replacement_history subagent session logs
• session logs disk subagent

I found related session/performance issues, but not a direct duplicate for repeated compacted.replacement_history persistence in subagent rollout JSONL files.

Impact

• ~/.codex/sessions grew to roughly 190G.
• July sessions alone used about 146G.
• The disk reached about 99% usage and left only about 10GiB free.
• This blocks normal development/test workflows that need release builds, native UI verification, and longer runs.
• The large raw logs are still registered as active/unarchived session files, so manual deletion is risky.

Observed evidence

Read-only inventory of <HOME>/.codex/sessions/2026/07:

• Total indexed JSONL files: 641.
• thread_source=subagent: 636 files, about 145.759GiB.
• thread_source=user: 2 files, about 0.005GiB.
• thread_source=automation: 6 files, about 0.002GiB.
• Large subagent JSONL files >=1GiB: 71, total about 145.450GiB.
• Current-day/open files were not modified or touched.

Representative largest subagent JSONL:

• Raw file size: about 2.24GiB.
• Lines: 156,005.
• Top-level compacted records: 811.
• context_compacted markers: 811.
• compacted/replacement_history payload dominates storage.

Representative type breakdown:

type                            count   bytes_mib   pct
compacted                         811    2127.71   92.96
event_msg.token_count           73663      51.91    2.27
event_msg.thread_goal_updated   18278      36.97    1.62
event_msg.patch_apply_end        9153      22.01    0.96
event_msg.agent_message         46144      21.68    0.95
response_item                    2779      11.97    0.52
session_meta                      284       7.38    0.32
turn_context                     1672       2.46    0.11

Bounded scan of only the last 16MiB of each of the 71 large files:

• task_complete seen in 69/71 files.
• Evidence/tool/final-output refs are present, but tiny compared to repeated compaction payloads.

Expected behavior

Codex should not repeatedly persist full inherited replacement_history blobs per subagent/per compaction.

Expected alternatives:

• Store only the current compacted summary state.
• Store a digest/reference/backlink to an already persisted replacement history.
• Store a delta instead of the whole inherited history.
• Apply a retention policy that differentiates user/main chat history from subagent raw logs.

Actual behavior

Each large subagent rollout appears to persist full compacted.replacement_history snapshots repeatedly. In a long parent thread with many spawned subagents, this causes disk growth roughly proportional to:

number_of_subagents * number_of_compactions * replacement_history_size

This generated about 145.76GiB of subagent session logs from one parent-thread workflow.

Reproduction pattern

1. Use a long Codex Desktop parent thread that has already gone through context compaction.
2. Spawn many subagents from that parent thread.
3. Let subagents continue far enough to compact context or persist inherited compacted context.
4. Inspect <HOME>/.codex/sessions/<year>/<month>/<day>/rollout-*.jsonl.
5. Compare thread_source=subagent file sizes and count top-level compacted records / replacement_history payload size.

Read-only checks used

The investigation only used read-only commands such as:

du -sh ~/.codex/sessions/2026/07
find ~/.codex/sessions/2026/07 -type f -name '*.jsonl'
stat -f%z <file>
head -n 1 <file>
rg -a -c '"type":"compacted"' <file>
rg -a -c '"replacement_history"' <file>
sqlite3 -readonly ~/.codex/state_5.sqlite 'select thread_source, archived, count(*) from threads ...'
lsof +D ~/.codex/sessions/2026/07

Raw session files were not deleted, moved, edited, or attached.

Safety note

Please do not request raw .codex/sessions files unless there is a private upload channel. They contain private project/user content. A redacted ledger with aggregate counts can be provided.

Suggested fix direction

• Deduplicate compacted.replacement_history across subagent rollouts.
• Avoid storing full inherited replacement histories inside every child rollout.
• Add a bounded retention policy for subagent raw JSONL.
• Add a storage guard/alert when session logs exceed a threshold or when compacted payload dominates a rollout file.
• Make app-level archive/export handle subagent logs safely without breaking thread resume.