Rollout files store each command's output four times; a 12-day session grew to 1.4 GB

Version: codex-cli 0.150.0 (macOS, arm64)

A single rollout file under ~/.codex/sessions reached 1,446 MB. It was one session kept alive for twelve days (2026-08-20 to 2026-09-01) that ran 25,280 shell commands. Measured contents:

• 238,755 JSONL records.
• For every command, the output text is written once in the response_item / custom_tool_call_output record and then three more times inside the event_msg / item_completed record, in the fields stdout, aggregated_output, and formatted_output. In 24,120 of 25,280 commands aggregated_output is byte-for-byte identical to stdout. Across the file: 257 MB stdout + 257 MB aggregated_output + 169 MB formatted_output + 289 MB in the response_item copies.
• 365 compacted records averaging 527 KB each (188 MB), one per context compaction, each re-embedding the summarised history.
• 455 screenshots stored inline as base64 PNG text (105 MB).
• The per-command output cap appears to be 1,048,607 bytes; 24 commands hit it.

Across all sessions on this machine the directory is 39 GB (1,267 files), 38 GB of it from August.

Requests:

1. Do not persist stdout / aggregated_output / formatted_output copies in item_completed when the same text is already in the custom_tool_call_output record (or reference it by id).
2. Store screenshots as files next to the rollout rather than base64 inside it.
3. Store compaction snapshots as deltas or keep only the latest.
4. Expose a configuration option for a rollout size or retention policy.

I can supply a per-record-type byte histogram script if useful.

No file or test paths are named. Start by locating the rollout serializer and the code emitting response_item/custom_tool_call_output and event_msg/item_completed records, then inspect persistence for compaction snapshots and screenshots. Done means avoiding duplicate command output, reducing inline screenshot and compaction storage, and exposing rollout size or retention controls.