Repository navigation
Codex App session JSONL files grow to 24 GB due to repeated inline image data during context compaction #33735
Description
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 GiBsessions: 25.312 GiBsessions\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?
-
Start a task in Codex Desktop on Windows.
-
Attach several images to the task.
-
Continue using the same task long enough for multiple context compactions.
-
Optionally spawn subagents or descendant tasks from the image-containing conversation.
-
Inspect the files under:
C:\Users\<username>\.codex\sessions\YYYY\MM\DD\ -
Observe that individual
rollout-*.jsonlfiles grow to hundreds of MiB. -
Inspecting JSON field lengths shows that the same inline
image_urldata is stored repeatedly insidecompacted.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.
Activity
github-actions commentedon Jul 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
shrishmanglik commentedon Jul 22, 2026
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:
type="compacted"records were 90.25% of all bytes; the 5 largest lines (~20.7MB each) were allpayload.replacement_historysnapshots retaininginput_imageitems as inlinedata:image/...;base64.Full attribution packet (methodology + numbers): #34061 (comment)
Coldain commentedon Jul 25, 2026
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 metadatacodex-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 recordsresponse_item/custom_tool_call_output: 114.4 MiB across 362 recordscompacted: 18.1 MiB across 54 recordspayload.resultaround 4.6–5.4 MB andpayload.output.*.image_urlaround 6.7–6.8 MBThe 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.moto-reloaded commentedon Oct 2, 2026
Additional read-only confirmation on Windows (2026-10-02 JST). This appears to be the same repeated inline-image retention during context compaction.
Environment: Windows NT 10.0.26200.0 x64. Current
codex --versioniscodex-cli 0.159.0-alpha.12.1. The affected rollout was last modified on 2026-09-03; the writer and desktop app versions at that time are unknown.One affected rollout measured 4,055,065,212 bytes (3.78 GiB). Its 125
compactedrecords occupied 3,551,301,611 bytes (3.31 GiB). There were 7,905 inline image occurrences, including 7,161 in compacted records. Those compacted image payloads occupied about 3.284 GiB, while SHA-256 comparison found only 658 distinct payloads totaling about 0.181 GiB. The largest compacted record was about 42.82 MiB. The full sessions directory measured about 14.79 GiB; the separate attachments directory contained 119,055 bytes.These measurements were collected without modifying the rollout. No session content, screenshots, identifying paths, or raw records are shared. The results support repeated serialization of historical images in
payload.replacement_history.