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-*.jsonl files grow to hundreds of MiB.
-
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.
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 filesA representative 268.4 MiB rollout file contains 234.6 MiB of
image_urldata (87.4% of the file) and 208 image references.The largest 359.3 MiB rollout file contains 77
compactedrecords totaling approximately 239.992 MiB. Inspection ofreplacement_historyshows 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-5fcc14f80edbLargest affected session ID:
019f49cf-e6c7-7aa0-b8eb-ead797461965The 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.