Codex session logs grow to 700MB-2GB from repeated compaction history and raw tool output

We've decided to eliminate the TUI logs entirely. They were largely redundant because we now log to a sqlite db, and those logs are properly rotated and pruned, whereas the TUI logs were append-only. This change will be in the next release.

i am not sure why this closed while its still an issue. The TUI also causing the issue. my codex sessions are in GB now.

Reopening because I misinterpreted the original bug report. I thought you were referring to logs (as indicated in the title), but upon closer read, you were talking about session rollout files. These rollout files are designed to record the full session details, so this isn't a bug. It's unusual for sessions to be so large that they consume hundreds of MB, but this is certainly possible if you use the same session repeatedly or use /goal to drive the agent to work for long periods of time.

We are looking to add compression to reduce the disk footprint. We're also going to add a delete command if you want to remove specific session rollouts completely.

Adding a cross-link because this issue covers large rollout JSONL growth generally, and the more specific mechanism is tracked in #23257.

We inspected an affected local rollout that reached about 11.36 GiB. The detailed sanitized breakdown is here: https://github.com/openai/codex/issues/23257#issuecomment-4767499090

Short version:

• 287 compacted records contributed about 10.68 GiB of the 11.36 GiB rollout.
• The compacted records were structured JSON, not opaque blobs: each had payload.replacement_history containing response items.
• The largest compacted record was about 52.1 MiB.
• Across all compacted records, 43 unique input_image payloads totaling about 51.3 MiB were copied as 9,173 image parts across compaction snapshots.
• Those repeated input_image.image_url copies accounted for about 10.66 GiB on disk, roughly ~213x amplification of the unique image payload footprint.

So this is not only "long session produces a large transcript". At least for this sample, append-only rollout persistence plus full replacement_history snapshots turns retained inline image payloads into runaway disk growth.

The latest version of the CLI (0.141.0) includes a codex delete <session ID> command that you can use if you want to delete specific sessions that have grown really large. I realize that's only part of the solution here, but I wanted to mention it in case it's of help to anyone who wants to free up some disk space.

note that you can also just ask codex to salvage these sessions. my 11.36gb session is now 700mb with all the images moved to the last compaction row.

@banteg I've done that, but with long-running /goal sessions, the session data keeps accumulating and both the JSONL logs and SQLite db continue to grow over time. I just have a cron job which prunes every few days..

Following up with data specific to the /goal angle @etraut-openai flagged back in June ("if you use... /goal to drive the agent to work for long periods of time").

• Confirmed reproducible on my end: one /goal thread ran continuously for 14 days without ever rotating, growing to 613,100 lines / 202MB, with 126,748 exec_command calls. Cross-checking ~/.codex/goals_1.sqlite (thread_goals table), that single thread burned 559,871,882 tokens before hitting usage_limited. Checking all my goal threads: 6 of 12 have independently hit usage_limited, totaling 929M of ~1.05B cumulative tokens. This isn't an edge case - it looks like the default outcome for any /goal run left unattended for more than a few days.

• One structural detail that might matter for a fix: thread_goals uses thread_id as its primary key, so a goal is permanently 1:1 bound to a single rollout/thread. There's no supported way to continue a goal in a fresh (compact) thread - only start an entirely new goal, losing continuity. If goal-driven work is meant to run long, it probably needs a goal_id-keyed continuation path that survives a thread rotation, not just better compression of the existing one.

• In the meantime I built a stopgap using the new PostToolUse/PreCompact/PostCompact hooks -- PostToolUse truncates+archives large exec output before it's ever recorded so it can't be resent on later turns, PreCompact warns inside the session when a goal thread's already deep in goals_1.sqlite token debt...

Reopening because I misinterpreted the original bug report. I thought you were referring to logs (as indicated in the title), but upon closer read, you were talking about session rollout files. These rollout files are designed to record the full session details, so this isn't a bug. It's unusual for sessions to be so large that they consume hundreds of MB, but this is certainly possible if you use the same session repeatedly or use /goal to drive the agent to work for long periods of time. We are looking to add compression to reduce the disk footprint. We're also going to add a delete command if you want to remove specific session rollouts completely.

Makes sense since I have 14GB of Codex session history since using GPT Pro 20x 5.6 Sol (X-high/Ultra) in Goal Mode; that means in the last 2 days I had 14 GB of memory eaten (yes, this was token-heavy work, I used 4 resets and ~1.5B tokens in one day alone).

<img width="768" height="173" alt="Image" src="https://github.com/user-attachments/assets/6eb074c6-7070-468a-a45b-8466947f49fa" />

and temporarily solved with a symlink to an external drive

<img width="747" height="495" alt="Image" src="https://github.com/user-attachments/assets/85f014e4-1789-44b5-b7b8-780e1b246cce" />

Additional sanitized reproduction from macOS 26.4 (25E246), arm64.

Current installed binary is codex-cli 0.144.5. Most of the affected rollout files were authored by codex-tui 0.144.0-alpha.4, with smaller amounts from 0.144.0 through 0.145.0-alpha.16.

Snapshot of ~/.codex/sessions:

• total on disk: about 12.3 GiB
• 377 subagent rollout files account for about 11.9 GiB
• 297 subagent files authored by 0.144.0-alpha.4 alone account for about 11.7 GiB
• non-subagent CLI/Desktop rollout files are only a few hundred MiB combined

A representative subagent rollout is 101,184,191 bytes (96.5 MiB). Serialized-record breakdown:

60 compacted records                    77.3 MiB
12,378 event_msg/token_count records     8.4 MiB
89 event_msg/mcp_tool_call_end records   3.1 MiB
1,121 event_msg/patch_apply_end records  2.9 MiB
138 response_item/message records         1.9 MiB

Its session metadata identifies the source as source.subagent.thread_spawn. This suggests an additional amplification path beyond a single long-running root thread: subagent rollouts inherit substantial parent context, then repeatedly persist that context in compacted.payload.replacement_history. In this sample, compacted records alone are roughly 80% of the file.

No inline images dominate this particular sample. The dominant data is repeated compaction history. This remains observable in rollout files from the 0.144.x line, not only the 0.118.0 version in the original report.

I investigated this on a real, privacy-sensitive workload and have a small, tested compression patch ready. I am posting the analysis first, per the invitation-only contribution policy, and would appreciate maintainer alignment/invitation before opening a PR.

Impact

On Codex 0.144.2, ~/.codex/sessions reached 75,412,910,173 bytes (70.23 GiB) across 644 rollouts after roughly one to two months of heavy use:

• 65.07 GiB was in subagent rollouts.
• One parent thread had 365 child rollouts totaling 62.62 GiB; the parent itself was 1.22 GiB.
• July 17 alone accounted for 29.15 GiB, and July 18 already accounted for 27.42 GiB at the time of the audit.

The audit is content-private: it reports sizes, JSON paths, counts, and hashes, and never prints message/tool contents.

What is being duplicated

I recursively analyzed a representative 760,247,640-byte (725 MiB) child rollout:

• compacted records: 652.06 MiB / 89.936% of the file.
• data: URLs: 659.78 MiB.
• payload.replacement_history[].content[].image_url: 632.39 MiB.
• repeated strings of at least 256 bytes within the file: 651.49 MiB.
• one 977,978-byte image string occurred 138 times (about 134 MiB attributable to that value alone).

Exact-line deduplication would save only about 1.10 MiB because timestamps and surrounding metadata differ. This is content/history-level duplication, consistent with #23257.

There is also substantial parent/child duplication. Comparing strings of at least 256 bytes by SHA-256, the child contained 705.39 MiB of large strings and 704.50 MiB already existed in its parent: 99.874% overlap by bytes (98.434% by unique values).

Source trace

At current main (56395bddaf26eb2829387ca6a417bf9128e5b239 when tested):

• session::replace_compacted_history persists replacement_history: Some(items.clone()); local/remote/v2 compaction paths all create full replacement histories.
• paginated subagents call LiveThread::create_with_inherited_model_context; SessionMeta.history_base exists, but the observed legacy rollouts still physically contain inherited context and the common creation/extraction paths leave it unset.
• transparent .jsonl.zst reading/materialization and a cold-compression worker already exist in rollout/src/compression.rs, but LocalThreadStoreCompression is under-development/default-off, waits seven days, and uses zstd level 3 with its default match window.

The current compression infrastructure is a good base, but default zstd cannot see repeated blocks separated by tens/hundreds of MiB. Also, a fixed seven-day delay does not help a workload that generated more than 50 GiB in two days.

Real-file compression benchmark

All rows use the same 760,247,640-byte rollout; full round trips were byte-identical by SHA-256.

| Encoding | Compressed bytes | Ratio | Representative resource result |
|---|---:|---:|---|
| gzip -6 | 498.3 MB | 1.53x | 20.62 s |
| zstd -3 default | 463,794,252 | 1.64x | 0.43 s, about 101.8 MiB RSS |
| zstd -3, long=23 | 108,474,356 | 7.01x | |
| zstd -3, long=24 | 72,554,649 | 10.48x | |
| zstd -3, long=25 | 52,901,838 | 14.37x | compress about 0.32 s / 58.3 MiB RSS; decompress about 0.20 s / 37.9 MiB RSS |
| zstd -3, long=27 | 32,856,569 | 23.14x | compress about 0.34 s / 166 MiB RSS; decompress about 0.19 s / 138.8 MiB RSS |

I selected a 32 MiB maximum window (windowLog 25) rather than the best ratio. It gives most of the storage benefit while keeping encoder/decoder memory far below long=27 and is appropriate for two background jobs.

Focused patch ready

The local topic branch changes only codex-rollout (55 inserted lines across two files):

• set pledged source size and include a frame checksum;
• for rollouts >= 8 MiB, enable long-distance matching;
• choose windowLog = ceil(log2(source_size)), clamped to 23..25;
• add a deterministic worker test using one incompressible 4 MiB block repeated three times; assert the result is less than half the source and decodes exactly.

Validation:

• just test -p codex-rollout: 100/100 passed;
• just fix -p codex-rollout: passed;
• just fmt: passed;
• git diff --check: clean.

I also verified the installed 0.144.2 app-server can thread/read both a synthetic and a real compressed rollout without materializing it. A guarded local migration compressed 194 closed rollouts, verified every frame and decompressed SHA-256, skipped six files observed open, and explicitly saved 53.78 GiB. The session directory fell from 70.23 GiB to about 19.3 GiB while preserving logical JSONL bytes. These were cold candidates and no integrity failures were observed, but lsof double checks cannot theoretically close an open-after-check race. A general migration should stop Codex writers, and the automatic worker should resolve the representation/append coordination called out in #25089 before default enablement.

Release compatibility follow-up

I downloaded official macOS arm64 release binaries, verified each asset against the SHA-256 digest in GitHub Release metadata, and ran the same isolated app-server probe through both thread/read and thread/resume:

| Stable release | Read .jsonl.zst | Resume/materialize plain JSONL |
|---|---|---|
| 0.135.0 | No; treats the frame as ordinary UTF-8 JSONL | No |
| 0.136.0 | No; treats the frame as ordinary UTF-8 JSONL | No |
| 0.137.0 | Yes | Yes |
| 0.141.0 | Yes | Yes |
| 0.144.2 | Yes | Yes |
| 0.144.6 | Yes | Yes |

So 0.137.0 is the earliest tested downgrade-compatible stable release; merge/release timing alone would have incorrectly suggested 0.136.0. The local migration tool now requires an actual supplied Codex binary and refuses to modify storage unless its isolated read-and-resume probe passes.

Proposed sequencing

1. Land the bounded long-distance zstd change as a schema-neutral, independently reversible improvement.
2. Resolve writer/compressor coordination, then separately decide when to stabilize/default-enable local compression and whether large closed/subagent rollouts should use a size-aware cooldown rather than seven days.
3. Design the structural fix: immutable parent-history prefix references and/or a versioned content-addressed blob/chunk store for large payloads. That needs transactional writes, dual-read compatibility, reference-aware deletion, and generation/lease-based GC; I would not mix it into the first patch.

Would this focused compression change align with the maintainers' intended direction? If so, I would be happy to submit and own the PR; please explicitly invite it per docs/contributing.md. I can also provide the privacy-preserving audit tool and more benchmark details if useful.

Follow-up: I finished the writer/compressor coordination work and the default-activation experiments locally. I have kept them as separate, atomic commits so the representation safety fix does not depend on the policy decision.

The open-handle race is reproducible

The existing before/after metadata checks do not cover this ordering:

1. a recorder opens the plain JSONL for append but has not written yet;
2. the worker sees unchanged metadata, installs the zstd sibling, and unlinks the plain path;
3. the recorder appends to its unlinked inode;
4. the installed zstd frame lacks the new suffix.

I added a deterministic regression for exactly that sequence and implemented a schema-neutral coordination patch:

• every real append handle holds a shared file lock for its full JsonlWriter lifetime;
• the compressor holds an exclusive lock on the exact source handle through encode, verification, zstd installation, and plain-file removal;
• after waiting for a lock, writers compare their open handle with the current path using stable same-file identity and retry representation resolution if the inode changed;
• blocking open/lock acquisition runs in spawn_blocking;
• resume/metadata recovery opens no longer use create(true), so a missing/deleted session cannot be accidentally resurrected.

The regression now proves that the active recorder remains plain, an append after the worker scan succeeds, and compression after shutdown reloads all three items with zero parse errors. The stacked rollout suite is 103/103 passing. cargo check, the Bazel rollout unit target, Bazel lock checks, just fix, and formatting pass. A Rust 1.95 Windows MSVC minimal compile probe covering same-file::Handle and File locks also passes; the full Windows cross-check stops earlier in third-party aws-lc-sys / ring because this macOS host lacks MSVC SDK headers.

A seven-day, startup-only policy is too late

I also recomputed the current inventory using plain sizes plus the decompressed size recorded in existing zstd frames, so the earlier local migration does not hide the logical workload: 827 rollouts represent 79.67 GiB of JSONL.

• An 8 MiB minimum selects only 364 files but covers 79.09 GiB / 99.28% of logical bytes.
• Applying both 8 MiB and 30 minutes of inactivity covers 74.25 GiB.
• The same size threshold at seven days covers only 0.78 GiB (26 files).

I prepared a follow-up worker-policy commit that runs at startup and every 30 minutes, compresses only files >=8 MiB and >=30 minutes old, and relies on the shared/exclusive file lock to skip active writers. It distinguishes a six-hour in-progress lease from a 30-minute completed-run cooldown, so a slow worker is not mistaken for a stale one. skipped_too_small is separately observable.

An isolated app-server built from the stack, with no feature override, automatically compressed an old 9,437,746-byte synthetic rollout, skipped an old small rollout and a fresh large rollout, and read the compressed thread successfully. An explicit local_thread_store_compression = false kept the large rollout plain. An unwritable-destination fault injection preserved the source JSONL and created no compressed sibling. The synthetic fixture is only a lifecycle test; the real compression-ratio evidence remains the 725 MiB benchmark from the previous comment.

Compatibility boundary and proposed PR order

The file lock is cooperative. It protects new writers/compressors, but an old Codex writer does not hold the shared lock; Unix advisory locks cannot force such a process to participate. I therefore kept the two-line stable/default-on change separate and would like maintainer guidance on the support policy for mixed old/new binaries concurrently writing one CODEX_HOME.

Proposed review order:

1. bounded long-distance zstd improvement (already described above);
2. append-handle / representation coordination;
3. periodic size-aware worker policy;
4. stable/default-on toggle as a separate release decision.

If this split aligns with the intended direction, please explicitly invite the PR(s) per docs/contributing.md; I am ready to submit and own the review/CI follow-through.

Independent reproduction + tested fix ready

Short version: After roughly one to two months of heavy Codex use, my ~/.codex/sessions reached 70.23 GiB (75.41 GB). A source-built implementation reduced a complete 79.61 GiB logical JSONL workload to 7.85 GiB physical storage (10.14x) while preserving 660/660 rollouts byte-for-byte. The work is split into reviewable commits, and I am asking for an explicit invitation to submit and own the fix.

What users would experience

• Active sessions stay ordinary appendable .jsonl files.
• At startup and every 30 minutes, a background worker compresses only files that are at least 8 MiB and have been untouched for 30 minutes.
• Reopening a cold session transparently materializes the exact JSONL before appending; after it becomes cold again, it can be recompressed.
• Debuggers can still stream or rebuild the original text byte-for-byte with a small companion tool.

This keeps the current logical rollout format and Codex read/archive/unarchive/resume behavior. It does not introduce content-addressed references or another on-disk schema in the first stage.

Measured result

| Check | Result |
|---|---:|
| Initial real user directory | 70.23 GiB physical after about 1–2 months |
| Complete product-path shadow | 79.613474 GiB logical -> 7.849757 GiB physical (10.1422x) |
| Preservation | 660/660 byte-exact; 0 missing, added, or mismatched |
| Eligible files | 156/156 compressed |
| One-time backlog worker | 24.399 s in the background |
| Foreground thread/list p50/p95 | 23.871/26.386 ms during worker vs 24.258/26.007 ms afterward |
| Steady no-candidate pass | no rollout writes; 0.5 s; 3.172 MiB peak RSS |
| Largest current cold resume | 3.544552 GiB materialized byte-exact in 2.598 s at 37.438 MiB peak RSS |

The live sessions tree and source state DB were never modified: the full-store tests used APFS clonefile shadows and an online SQLite snapshot.

The user-impact numbers use strict units and semantics. 70.23 GiB is physical storage, equivalent to 75.41 GB; it is bytes, so there is no divide-by-eight conversion. A separate mtime snapshot found four plain rollouts modified on 2026-07-19 totaling 5.34 GiB, including one 3.48 GiB file. Session path dates are start-date cohorts, not calendar-day net growth.

<details>
<summary><strong>Maintainer / review-agent details</strong></summary>

Why the files grow

The local audit found large payloads repeated across compaction replacement_history snapshots and inherited parent history copied into many child/subagent rollouts. Exact-line deduplication helps little because surrounding JSON records differ. In the largest 379-child parent group, a privacy-safe exact-string audit found 63.206185 GiB of repeated strings at least 64 KiB inside 72.600540 GiB of logical JSONL; this structural result is not multiplied by the zstd ratio and remains a separate future format/lifecycle decision.

Patch boundaries

This extends the existing upstream design rather than introducing a parallel storage architecture. The original #25089 worker PR explicitly left writer/compressor coordination unresolved and named a shared representation/append lock as a possible production-readiness requirement. The active-session follow-up #28338 received the same live-recorder race concern. The local coordination layer now provides a deterministic red-before-fix reproduction and closes both writer orderings.

The local series is deliberately staged:

1. bounded 8–32 MiB zstd long-distance matching plus frame checksum;
2. shared append-handle / exclusive compressor coordination;
3. 8 MiB, 30-minute recurring policy;
4. stable run-marker ownership across the complete scan;
5. crash-durable representation install/retirement and dual-sibling recovery;
6. materialization install-window validation plus the exact-installed-inode fast path;
7. an independently revertible stable/default-on switch with public API lifecycle tests.

The first patch is a schema-neutral 55-line codec change with no activation, reader, retention, or model-context behavior change. I can submit the series in whatever staged shape maintainers prefer.

The final change-size audit split recovery into 411-line and 159-line semantic commits, both below the repository's 500-line guidance for complex logic. The split activation and integration heads are Git-tree identical to the previously validated heads; this improves review and rollback boundaries without changing runtime behavior or invalidating the measurements below.

Safety findings closed before submission

• Deterministic tests cover writer-open-before-compress and compress-between-resolution-and-open data-loss windows.
• On Unix/macOS, the new representation and parent directory are synced before the old representation is retired, followed by another parent sync. Windows keeps the repository's existing directory-sync no-op boundary; I am not claiming a verified Windows power-loss guarantee.
• Plain/zstd dual siblings converge only after proving decoded zstd is identical to or a prefix of plain. Divergence returns InvalidData and preserves both files.
• A final audit found an install-window race: an older writer could replace plain after materialization installed its candidate but before zstd retirement. The fix locks the installed path and requires full prefix validation or exact successful-install inode proof before deleting zstd. The regression failed before the fix and now preserves both divergent representations byte-for-byte.
• The inode proof avoids an unconditional second multi-GiB decode: 2.598 s versus 3.739 s on the current largest file, a 30.516% latency reduction. Pre-existing, copy-fallback, or replaced destinations still receive full validation.

Validation and compatibility

• current activation stack: codex-rollout 115/115, 0 skipped;
• independent codec branch: 100/100, 0 skipped;
• focused legacy + paginated public lifecycle: 2/2;
• nine deterministic durability/recovery regressions;
• previous complete integration tree: 114/114; the current rebased composition was release-built after its independently passing components, with tests intentionally not rerun after the repository-required fix/format sequence;
• official macOS arm64 releases 0.137.0, 0.141.0, 0.144.2, and 0.144.6 read and resume/materialize the compressed fixture; 0.135.0 and 0.136.0 require materialization before downgrade;
• local storage/audit/text-tool suite: 25/25.

</details>

Would a maintainer please invite me to submit the staged fix, beginning with the focused codec patch if that is the preferred review boundary? I am ready to own the PR through review, CI, follow-up changes, merge, and release validation.

@jif-oai — you authored the current rollout compression/materialization path (#25087, #25089, #28338), so I’m asking you specifically to confirm the first review boundary.

I have a two-file, 55-line codec-only PR ready: bounded zstd long-distance matching (8–32 MiB window) plus frame checksums, with no activation, reader, schema, retention, or model-context changes. On a real 725 MiB rollout it improved compression from 1.64x to 14.37x, byte-exact, and the independent codex-rollout suite passes 100/100.

If that scope aligns with the intended direction, would you please explicitly invite me to submit it per docs/contributing.md? I’ll own review, CI, follow-up changes, and release validation. The larger writer-coordination and policy work described above will remain separate.

@jif-oai — you authored the current rollout compression/materialization path (#25087, #25089, #28338), so I’m asking you specifically to confirm the first review boundary. I have a two-file, 55-line codec-only PR ready: bounded zstd long-distance matching (8–32 MiB window) plus frame checksums, with no activation, reader, schema, retention, or model-context changes. On a real 725 MiB rollout it improved compression from 1.64x to 14.37x, byte-exact, and the independent codex-rollout suite passes 100/100. If that scope aligns with the intended direction, would you please explicitly invite me to submit it per docs/contributing.md? I’ll own review, CI, follow-up changes, and release validation. The larger writer-coordination and policy work described above will remain separate.

@jif-oai !image

This fix is badly needed, I have a 1.5 TB ~/.codex/sessions folder, and growing, and had to symlink to a slow external drive. Horrible UX. I also can't just "throw away" the June, May, April etc. folders: The file system shows they were touched / written to so I am afraid to corrupt the JSONL tree beyond all repair.

As a small band-aid, Mac users can buy themselves some time with the applesauce Homebrew tool, its use is straightforward:

applesauce compress "~/.codex/sessions"

Ironically, Apple's file system compression (which is roughly the equivalent of the well-known NTFS in-place file compression), stops at 4 GB, so exactly the files that need it most, won't get compressed. 🤦‍♂️