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

[sriinnu]

What version of Codex CLI is running?

0.118.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

codex-tui

Codex doctor report

What issue are you seeing?

Codex CLI/TUI is creating extremely large session JSONL files under ~/.codex/sessions.

One affected session file is 732 MB:
~/.codex/sessions/2026/03/31/rollout-2026-03-31T22-18-46-019d458c-752d-76c0-bbfa-a29eafa0cbf0.jsonl

A quick breakdown shows the size is dominated by repeated compaction history and raw tool outputs:

• 337.8 MB from compacted records
• 230.8 MB from function_call_output
• 54.8 MB from reasoning
• 26.4 MB from token_count events
• 18.0 MB from turn_context

The file has 170,415 JSONL records. The largest single record is about 2.1 MB. My ~/.codex/sessions directory is now about 91 GB total, with 184 JSONL files over 100 MB
and the largest observed file around 1.95 GB.

This looks like unbounded session logging / repeated persistence of compaction history rather than expected transcript storage.

What steps can reproduce the bug?

1. Use Codex CLI/TUI for a long coding session with multiple tool calls.
2. Run broad search commands that can produce large outputs, for example rg across large repos or /tmp.
3. Continue the session long enough for context compaction to occur multiple times.
4. Inspect ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl.
5. Check file size and record composition with commands like du -h, wc -l, and jq.

Observed result:
The session JSONL grows to hundreds of MB or more. In one case, a single rollout file reached 732 MB with 170,415 records.

The biggest contributors were:

• repeated compacted records containing large replacement_history payloads
• raw function_call_output payloads
• reasoning and token count event records

What is the expected behavior?

Session logs should stay bounded and should not grow to hundreds of MB or multiple GB for a normal long coding session.

Expected behavior:

• Tool outputs should be truncated, summarized, deduplicated, or stored with a size cap.
• Context compaction should not repeatedly persist large prior history snapshots in replacement_history.
• Old session logs should be compressed or covered by a retention policy.
• A long tool-heavy session might produce a larger log, but it should remain within a reasonable size, not 700MB-2GB per JSONL file.

Additional information

Affected file:
~/.codex/sessions/2026/03/31/rollout-2026-03-31T22-18-46-019d458c-752d-76c0-bbfa-a29eafa0cbf0.jsonl

File stats:

• Size: 732 MB
• Lines: 170,415
• Largest single JSONL record: ~2.1 MB
• Average record size: ~4.5 KB

Breakdown by record type:

• compacted: 337.8 MB across 684 records
• response_item/function_call_output: 230.8 MB across 35,368 records
• response_item/reasoning: 54.8 MB across 23,659 records
• event_msg/token_count: 26.4 MB across 38,885 records
• turn_context: 18.0 MB across 955 records
• response_item/custom_tool_call: 16.3 MB
• response_item/function_call: 14.5 MB

Two large rg tool outputs in the affected session:

• ~1.9 MB output from an rg command across local repos
• ~1.3 MB output from an rg command across /tmp and a local repo

Broader local impact:

• ~/.codex/sessions total size: ~91 GB
• JSONL files over 100 MB: 184
• Largest observed session JSONL: ~1.95 GB

Session metadata:

• originator: codex-tui
• affected session cli_version: 0.118.0
• current installed CLI: codex-cli 0.134.0
• current binary path: /opt/homebrew/bin/codex
• affected session records model_provider: openai, but no concrete model ID is present

Please try reproducing with the affected CLI version 0.118.0 by downloading/installing that version, running a long tool-heavy Codex TUI session, and then inspecting the
generated ~/.codex/sessions/.../rollout-*.jsonl file size and record breakdown.

[etraut-openai]

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.