Codex App session JSONL files grow to 24 GB due to repeated inline image data during context compaction

Start by inspecting the representative rollout-*.jsonl files under .codex\sessions\YYYY\MM\DD, focusing on compacted.payload.replacement_history and repeated image_url data. Trace the context-compaction serialization path and verify that completed work stops embedding the same inline images in each snapshot and descendant session.

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

26.715.2305.0 (bundled Codex CLI: 0.145.0-alpha.18)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex App's local session storage has grown unexpectedly to 27.761 GiB on my C: drive.

Storage breakdown:

• C:\Users\<username>\.codex: 27.761 GiB
• sessions: 25.312 GiB
• sessions\2026\07: 24.365 GiB across 360 JSONL files
• July 13–17 alone: 23.521 GiB across 310 files

A representative 268.4 MiB rollout file contains 234.6 MiB of image_url data (87.4% of the file) and 208 image references.

The largest 359.3 MiB rollout file contains 77 compacted records totaling approximately 239.992 MiB. Inspection of replacement_history shows that previously attached inline images are serialized again in repeated context-compaction records.

Multi-agent or descendant sessions also appear to copy the image-containing history, further amplifying the disk usage.

There is no crash or visible error message. The symptom is rapid and unexpected growth of local session files.

What steps can reproduce the bug?

1. Start a task in Codex Desktop on Windows.

2. Attach several images to the task.

3. Continue using the same task long enough for multiple context compactions.

4. Optionally spawn subagents or descendant tasks from the image-containing conversation.

5. Inspect the files under:

   C:\Users\<username>\.codex\sessions\YYYY\MM\DD\

6. Observe that individual rollout-*.jsonl files grow to hundreds of MiB.

7. Inspecting JSON field lengths shows that the same inline image_url data is stored repeatedly inside compacted.payload.replacement_history.

In my case, July session files reached 24.365 GiB, while a representative 268.4 MiB session file contained 234.6 MiB of repeated image data.

What is the expected behavior?

Previously attached images should not be embedded again in every context-compaction snapshot.

Image attachments should ideally be stored once and referenced by file path, content hash, or attachment ID. Session storage should grow roughly in proportion to unique conversation content rather than multiplying with every compaction or descendant session.

Additional information

Representative affected session ID:

019f6df5-3051-7602-9310-5fcc14f80edb

Largest affected session ID:

019f49cf-e6c7-7aa0-b8eb-ead797461965

The analysis was performed using file sizes, record types, and JSON field lengths only. No session data was modified.

I have not attached the full JSONL files because they may contain private prompts, local file paths, tool output, and embedded images. I can provide a sanitized diagnostic summary if needed.