›_ Codex Issues
Codex Issues / #33735

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

Open 💬 4 comments Opened Jul 17, 2026 by xiaxiangfeng
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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\

  1. Observe that individual rollout-*.jsonl files grow to hundreds of MiB.
  2. 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33493

Powered by Codex Action

shrishmanglik · 1 month ago

Corroborating with byte-level measurements from our machine (Codex app 26.715.8383.0 / cli 0.145.0-alpha.27) — compaction is measurably the dominant amplifier in our data:

  • In a single 1.02GB session JSONL, type="compacted" records were 90.25% of all bytes; the 5 largest lines (~20.7MB each) were all payload.replacement_history snapshots retaining input_image items as inline data:image/...;base64.
  • Across a full day (15.4GB): images inside compaction snapshots = 90.4% of all image bytes and 97.6% of all compacted bytes. 82 compaction snapshots in one file were distinct-but-overlapping (evolving full-history persistence, not identical replays).
  • Dedup math: 1,219 inline-image occurrences resolved to only 241 unique payloads (45MB) — content-addressed image references would collapse ~13.8GB → 45MB for our day.

Full attribution packet (methodology + numbers): https://github.com/openai/codex/issues/34061#issuecomment-5051837565

Coldain · 1 month ago

macOS Codex Desktop corroboration with a slightly different byte distribution that may help scope the fix. Privacy-safe structural inspection only; no payload values or conversation content are included.

Environment: Desktop 26.721.41059; affected rollout metadata codex-cli 0.145.0-alpha.18; depth-1 subagent; history_mode: legacy.

A representative 597,936,910-byte rollout contained:

  • event_msg/image_generation_end: 406.3 MiB across 102 records
  • response_item/custom_tool_call_output: 114.4 MiB across 362 records
  • compacted: 18.1 MiB across 54 records
  • 130 JSONL records larger than 1 MiB
  • largest record: 18.7 MB
  • largest observed strings: payload.result around 4.6–5.4 MB and payload.output.*.image_url around 6.7–6.8 MB

The full local session store is 122.2 GiB. This suggests the durable fix should not cover only compacted.payload.replacement_history; image-generation completion events and custom tool outputs also need bounded/content-addressed artifact references, and descendant sessions should inherit references rather than re-materializing the bytes.

shleder · 6 days ago

The 87.4% image_url ratio and the replacement_history re-serialization you found is the key detail — compaction is re-emitting previously-inlined images into every compacted record instead of referencing them, and descendant sessions copy the whole image-laden history. That's a compaction invariant violation, not just "big files."

For anyone hitting this, the first step is characterizing the rollout before touching it: per-record byte breakdown, how much is image_url vs actual transcript, and how many compacted records re-contain the same image payloads. That tells you whether a salvage can strip the redundant image data while keeping the durable transcript.

Full disclosure: I maintain codex-rescue (https://github.com/shleder/codex-rescue). codex-rescue storage profiles exactly this — large payloads, media anomalies, and per-record byte distribution across the store — read-only, so it won't touch the 24 GB of source. It's a quick way to confirm the image-redundancy ratio on your own session and quantify how much is recoverable. The compaction-side fix (dedupe image payloads across replacement_history) is the real solution, but this at least gives you the numbers to file against.