Codex session rollout files duplicate full historical context on resume, causing multi-GB .jsonl and SQLite log growth

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.51431

What subscription do you have?

pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex session rollout files duplicate full historical context on resume, causing multi-GB .jsonl

What steps can reproduce the bug?

Original thread creation date: 2026-05-03
Resume/observation date: 2026-06-23
Phenomenon
I created a Codex thread on 2026-05-03 and kept using the same thread for iterative development over time. As the thread became long, the original session rollout file grew to more than 2GB.
When I later resumed the same old thread on 2026-06-23, Codex created new rollout files under the current date directory:
C:\Users\ch\.codex\sessions\2026\06\23
However, the new rollout files were already around 2GB immediately or very quickly after resuming. This suggests that Codex may be copying or replaying the full historical session into the new date-based rollout file instead of writing only incremental events for the resumed session.
Observed large session files:
2.65 GB 2026-06-23 09:47:09 C:\Users\ch\.codex\sessions\2026\05\03\rollout-2026-05-03T13-13-03-019dec41-1bc2-7ec3-9408-44683958ab28.jsonl

2.37 GB 2026-06-23 09:48:47 C:\Users\ch\.codex\sessions\2026\06\23\rollout-2026-06-23T09-45-44-019ef227-8db2-71b0-b8d8-5a9e6aba88c4.jsonl

2.36 GB 2026-06-23 09:48:02 C:\Users\ch\.codex\sessions\2026\06\23\rollout-2026-06-23T09-44-16-019ef226-36dc-7082-bc86-3ff442012b17.jsonl

2.33 GB 2026-06-22 22:26:04 C:\Users\ch\.codex\sessions\2026\06\22\rollout-2026-06-22T22-08-22-019eefa9-1b1a-7a90-8b28-56cbbef30a90.jsonl

2.32 GB 2026-06-22 22:27:25 C:\Users\ch\.codex\sessions\2026\06\22\rollout-2026-06-22T22-07-36-019eefa8-66f0-70b1-ac05-14ada1eff371.jsonl
There is also a very large local log database:
C:\Users\ch\.codex\logs_2.sqlite ~4.24 GB
C:\Users\ch\.codex\logs_2.sqlite-wal ~44 MB+
The SQLite files’ LastWriteTime continued changing during short interval checks, indicating ongoing writes or touches.

What is the expected behavior?

Expected Behavior
When resuming an old thread, Codex should not duplicate the entire historical rollout into a new date-based session file.
Expected behavior would be one of the following:
Only append new events after resume
Reference the previous rollout file instead of copying it
Compact or summarize old history before writing
Split session history safely with deduplication
Apply a reasonable maximum file size limit
Provide an automatic cleanup/compaction mechanism
Actual Behavior
Resuming a long-running old thread appears to create a new rollout file that contains a large amount of historical session data. As a result, every resume of a long thread may generate another multi-GB .jsonl file.
This causes:
Rapid disk usage growth
Multiple duplicated 2GB+ rollout files across date folders
Slow or heavy session persistence
Potentially degraded startup/resume performance
Difficult manual cleanup for users
Possible Cause
The session persistence/resume logic may be materializing the full historical thread state into each new rollout file when a thread is resumed, especially across date-based session directories.
In other words, the new file may not be an incremental log of only new events. It may be a full replay/copy of the prior rollout plus newly appended events.
This seems separate from logs_2.sqlite growth. Disabling analytics or clearing logs_2.sqlite may reduce SQLite log growth, but it likely does not fix the rollout .jsonl duplication problem.
Suggested Improvements

1. On thread resume, write only incremental events instead of copying full historical rollout content.

1. Store long-term thread history by reference rather than duplicating it into each new date-based rollout file.

1. Add automatic compaction/summarization for long-running threads.

1. Enforce a maximum size for individual rollout .jsonl files.

1. Add deduplication logic when creating new rollout files for resumed sessions.

1. Separate diagnostic logs from resumable session state, so disabling analytics/logging can actually reduce local disk writes.

1. Provide a built-in command or UI action to clean, compact, or archive old sessions safely.

1. Provide visibility into local storage usage, such as:

• session file count
• total session size
• largest rollout files
• log database size

1. Avoid creating multiple 2GB+ rollout files when the same historical thread is resumed multiple times.

Summary
A long-running Codex thread created on 2026-05-03 grew to a 2GB+ rollout file. When the same thread was resumed on later dates such as 2026-06-23, Codex created new date-based rollout files that were also immediately around 2GB. This strongly suggests that the resume/session persistence logic is duplicating full historical session content instead of writing only incremental events, causing severe local disk usage growth.

Additional information

_No response_