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

What version of Codex CLI is running?

codex-cli 0.144.5, official standalone Linux release.

What subscription do you have?

ChatGPT Pro 20X.

Which model were you using?

GPT-5.6-Sol Ultra.

I did not notice comparable storage growth while using GPT-5.5 xhigh. The problem became apparent during GPT-5.6-Sol Ultra use, although this is a correlation rather than proof that the model itself is the cause.

What platform is your computer?

Linux 7.0.10+deb14-amd64 x86_64 unknown

What terminal emulator and version are you using?

GNU Screen 5.0.1.

Codex doctor report

{
  "status": "not included",
  "reason": "Not relevant to this storage-retention report; direct filesystem and read-only database measurements are provided below."
}

What issue are you seeing?

Codex local state under ~/.codex grew to 15,826,554,880 allocated bytes—approximately 14.7 GiB—becoming the largest consumer on a 31 GiB root filesystem and leaving only about 230 MiB free.

Breakdown at inspection:

• ~/.codex/sessions: 10,927,050,752 allocated bytes across 1,572 JSONL files.
• logs_2.sqlite: 2,278,338,560 bytes.
• logs_2.sqlite-wal: 1,046,129,832 bytes.
• logs_2.sqlite-shm: 2,031,616 bytes.
• Four retained standalone Codex releases: approximately 1.19 GB.

Recent dated session cohorts currently contain:

• July 14: 250 files, 1.59 GB apparent size.
• July 15: 381 files, 3.26 GB.
• July 16 by approximately 16:27 UTC: 176 files, 2.43 GB.

These are current cohort totals rather than precise historical deltas. However, 188 session files modified on July 16 total 2.83 GB, including sessions stored under earlier dates.

This is aggregate accumulation across many files rather than one corrupt outlier. The largest session file is approximately 200 MB; the next largest are approximately 164, 145, 138, 116, 107, and 104 MB.

The SQLite database contains real retained data rather than free-page bloat:

• Approximately 991,000 retained log rows.
• Approximately 1.39 GB of estimated retained payload.
• Records spanning July 6 through July 16.
• Only 61 free pages out of approximately 556,000 pages.

During a read-only 10-second sample while running 0.144.5, the log table gained 241 IDs and 122,863 estimated payload bytes. Dominant current sources included streamed-event DEBUG, SSE TRACE, MCP connection TRACE, and outgoing-message TRACE. This narrow sample proves continuing writes under 0.144.5 but should not be extrapolated as a sustained rate.

The historical database accumulated across earlier CLI versions, so I am not claiming that 0.144.5 created the entire 3.3 GB SQLite footprint.

What steps can reproduce the bug?

A minimal single-prompt reproduction has not yet been isolated.

The observed workload was ordinary software development using GPT-5.6-Sol Ultra, including:

• Shell and PTY commands for Git, file searches, builds, formatting, linting, and tests.
• Reading and editing source files and applying patches.
• Package-manager and runtime commands.
• Browser and Playwright UI smoke tests, including screenshots.
• Bounded VM, sandbox, and QEMU smoke tests where relevant.
• HTTP, documentation, and GitHub lookups.
• Codex planning and subagent coordination.
• Long-running and resumed CLI sessions.

No deliberate high-volume output generator, storage stress test, or unbounded synthetic workload was being run.

To observe the problem:

1. Install and use the official standalone Codex CLI on Linux.
2. Select GPT-5.6-Sol Ultra.
3. Perform routine tool-using development work over several days, including long or resumed sessions.
4. Leave completed and active session history in the default ~/.codex location.
5. Periodically inspect:

``bash
du -x -B1 -s ~/.codex ~/.codex/sessions
stat -c '%s %n' ~/.codex/logs_2.sqlite*
find ~/.codex/sessions -type f -name '*.jsonl' | wc -l
``

1. Observe session JSONL files accumulating into multiple gigabytes while logs_2.sqlite and its WAL retain high-volume diagnostic records.

What is the expected behavior?

Codex local storage should remain bounded during sustained normal development use.

In particular:

• Diagnostic SQLite data should have effective retention, pruning, rotation, and WAL checkpointing.
• Completed session histories should not retain unbounded tool output or repeatedly duplicated history.
• Completed session JSONL files and rotated diagnostic logs should be transparently compressed.
• Archived SQLite log payloads should be compressed, or active records should be rotated into compressed archives.
• Compression should complement deduplication and bounded retention rather than merely preserving unlimited data in a smaller form.
• Codex should provide a supported global retention or cleanup mechanism.
• Codex should warn before its local state consumes enough space to threaten filesystem operation.

The session histories and diagnostic records are predominantly textual and contain repeated structured data, so compression should substantially reduce their storage footprint.

Additional information

A structural scan of the ten largest session files sampled 1.20 GB—approximately 11% of session storage—without reading or exposing prompt or tool-output content. All ten identified their source as CLI sessions.

By stored bytes in that sample:

• Tool outputs: 54.1%.
• Reasoning records: 16.0%.
• Compacted snapshots: 4.8%.
• Inline Base64 image data: 5.9%, overlapping other record categories.

Within compacted replacement_history records, 96.6% of embedded items exactly matched an earlier top-level response item. This demonstrates duplication, although compacted snapshots were secondary to retained tool outputs in this sample.

Filesystem inode usage was normal, and no deleted-but-still-open files were found. No session files or databases were deleted or modified during diagnosis.

Related reports:

• #28224: earlier excessive logging report closed as fixed.
• #28997: closest Linux WAL-growth report; its original extreme trigger involved a fork, whereas this report uses the official standalone CLI.
• #31142: continuing high-frequency SQLite logging, including reports on 0.144.5.
• #24948: broad session-rollout growth tracker.

No raw database, rollout JSONL, configuration, session ID, hostname, username, project path, or other private diagnostic data is attached.