35.1% less space. The same 135 Codex turns.
Codex keeps each conversation as a file in ~/.codex/sessions, or in ~/.codex/archived_sessions once archived. Screenshots are written into that file, so a long conversation can reach hundreds of MB, and deleting it deletes its history. On October 15, 2026, Optimize in public Mint 1.0.99 made eight archived conversations take 35.1% less space; Codex read the same 135 turns, and after Undo the text and pictures matched.
TL;DR
- Where it is. Codex keeps conversations in ~/.codex/sessions and archived ones in ~/.codex/archived_sessions, with screenshots written into each file.
- Public Mint, October 15, 2026. Optimize made eight archived conversations take 35.1% less storage, 29.18 MB saved each on average. Codex read the same 135 turns, and 8/8 Undo content checks matched.
- Development build, September 26, 2026. A different, file-level compression method saved 1.29 GB on three conversations. 4/4 files were byte-identical and Codex read back the same 1,598 turns. Not re-run on the public version.
- Scope. One developer’s Mac. The two results come from separate tests: they are not added together, and neither predicts what your Mac will save.
How much space do your Codex conversations take?
Check your own Mac first:
du -sh ~/.codex/sessions ~/.codex/archived_sessions 2>/dev/null
Newer Codex (measured with codex-cli 0.155.1) rewrites a conversation idle for seven days as a .jsonl.zst file. Public Mint 1.0.99 does not list these conversations yet; the Direct version that supports them is waiting for release.
October 15, public Mint 1.0.99: before, after and Undo
Average net saving = (666,017,792 − 432,566,272) ÷ 8 = 29,181,440 bytes, or 29.18 MB per conversation. The 35.1% figure is the reduction of the sample’s total storage, not the average of eight individual percentage reductions.
All eight selected conversations changed; none failed or were skipped. The operation took 25.02 seconds on this Mac. The net allocated reduction was 233,451,520 bytes (35.0518%). A larger logical-size reduction is not the number we use as the storage result.
The Mac remained in use. Whole-volume free space fell by 19.05 MB between the recorded baseline and post-operation readings, while the measured file allocation fell by 233.45 MB. Concurrent activity, filesystem metadata and snapshots prevent attributing that whole-volume change to Mint. Research copies also used extra space; this experiment did not clean the owner’s live conversations.
| Measurement | Before | After Optimize | After Undo |
|---|---|---|---|
| Average allocated storage per conversation, including overhead | 83.252 MB | 54.071 MB | 62.085 MB |
| Conversation files: logical size | 666.002 MB | 428.685 MB | 496.612 MB |
| Conversation files: allocated storage | 666.018 MB | 432.468 MB | 496.628 MB |
| Recovery records: allocated storage | 0 MB | 0.045 MB | 0 MB |
| Test profile: allocated storage | 0 MB | 0.053 MB | 0.053 MB |
| Total allocated storage in the measured scope | 666.018 MB | 432.566 MB | 496.681 MB |
Download the exact measurements and validation results (JSON)
By October 15, this Mac had already been optimized
This working Mac had already undergone multiple storage optimizations. One completed operation in its local Mint history, recorded on October 10, 2026 (UTC), reported 15.45 GB freed across 4,801 items without deletion. The earlier operation covered a broader set of files. Its app-reported result is historical context, not a newly verified Codex benchmark, and is excluded from this experiment’s savings.
For the October 15 experiment we measured how much the eligible Codex conversations could still shrink, then checked that Codex could read them, prepare a continuation and restore their content. The 29.18 MB average describes this sample on a regularly maintained Mac. We have not established whether these eight conversations themselves were optimized before.
See the historical record and the separate experiment measurements
October 15: reading and continuation requests
We reopened separate original, optimized and restored copies through Codex’s own app-server and read every page of turns. Each set contained the same eight threads, 135 turns and 257 items, with no read errors. All eight normalized turn-content comparisons matched. Resuming a conversation left its existing content intact.
We also asked Codex to build a continuation request for every copy. A local HTTP stand-in captured each request and stopped it before any model call. Optimized and restored requests matched the original in 8/8 cases. A second unchanged-original control also matched 8/8. The comparison normalizes changing IDs, timestamps, home paths and client metadata; images are compared by dimensions, RGBA pixels and ICC color profile.
This checks what Codex reads and prepares to send. It does not test the quality of a future model answer or constitute a visual check of the desktop interface.
What exactly did Undo restore?
Undo succeeded for all eight conversations. Outside recognized image data URLs, the restored bytes matched the original. Every decoded image matched in dimensions, RGBA pixels and ICC color profile.
Zero of the eight complete files were byte-identical after Undo: pictures were stored in a smaller lossless format, and Undo keeps that smaller encoding. That is why the restored files still take less space. The test supports restoration of the checked text and picture content, not reconstruction of the original picture encoding.
These results apply to Optimize. Remove media and Delete are different, permanent actions. Undo also depends on the required originals and recovery history still being available.
How the October 15 test was run
The Mint team ran this owner-operated study on October 15, 2026, using an Apple M1 Max MacBook Pro, macOS 27.0.1 and Codex CLI 0.155.1. We verified the public Mint Direct 1.0.99 (114) installer and executable, then ran the same executable under an isolated QA identity and private profile. The real app and live conversations were not changed.
The local catalog contained 413 session files. We screened 39 archived, top-level files between 2 and 320 MB, idle for at least 24 hours, with no dependency on or from other conversations. We randomized their inspection order with seed 7 and checked all 39 for more than 100 kB of repeated screenshot data in earlier compactions. All eight eligible files were included, below the predeclared maximum of ten. Selection happened before Optimize, without choosing by achieved savings. The inspection order was randomized; the sample represents eligible files on this Mac, not a random sample of all conversations or users.
- Write independent byte copies, without APFS clones or hard links. Record hashes and modification times of the live sources.
- Measure allocated blocks and logical bytes separately. Include every regular file in the selected corpus, Mint recovery directory and isolated profile.
- Run the same selected-conversation Optimize workflow used by the app. Record completion, failures, elapsed time and storage before creating verification copies.
- Keep the recovery records, test Undo, then compare original, optimized and restored copies using Codex’s reader and a local continuation-request capture.
- Recheck source hashes and modification times. Publish aggregate results; keep conversation text, pictures, paths and thread IDs private.
Read-only helper for measuring copies and checking content after Undo (Python)
September 26, development build: 3.13 GB of real Codex files
Long-running conversations can span more than one file. In this September 26 experiment, four large files belonged to three real conversations; the original record lists them as 540 MB, 564 MB, 877 MB and 1.15 GB. Mint compressed independent copies, leaving the live originals unchanged. This development build used a different, file-level compression method that keeps the bytes applications read exactly the same.
The measured reduction was 1.29 GB, averaging 428.42 MB per conversation, or 321.31 MB per compressed file. The original note rounded the input total to 3.13 GB, so the approximately 41% figure is a rounded comparison to that input, not a precise allocation percentage or a minimum saving.
| Measurement | Recorded result |
|---|---|
| Input recorded in the experiment | 3.13 GB (rounded) |
| Allocated storage saved | 1,285,251,072 bytes · 1.29 GB |
| Average saved per conversation | 428.42 MB · 3 conversations |
| Average saved per compressed file | 321.31 MB · 4 files |
| Compression and complete byte read-back | 12.6 seconds |
| Files identical by SHA-256 | 4 / 4 |
| Codex reopened the same content | 1,598 turns · 2,381 items |
Read the historical measurements and their provenance (JSON)
Could Codex still use those large conversations?
Yes in this reader check: Codex’s own app-server reopened all three threads exactly as it reopened the uncompressed copies, with 1,598 turns and 2,381 items. All four compressed files were identical by SHA-256. Resuming the conversations left their original content intact. Two of the compressed files belonged to one thread; its additional 44 MB first file was supplied for reading, but was not a fifth compressed file.
The recorded file-block reduction and volume-free-space increase agree within 4 KiB. The original note calls them equal, but converting its recorded units reveals that small difference; we retain both figures in the evidence. This result comes from a dated development-build experiment that ran Mint’s compression directly, without the app’s interface. It was not rerun on the current public version, and it did not test the Optimize drawer, Undo or a new model response. The source excerpt documents the result; the private conversations and original raw run logs are not part of the public record.
The October 15 checks above cover a different operation, screenshot optimization, on eight other files. They do not validate this experiment, and the two savings are not added together.
What this case does not establish
Both experiments used real private data on one developer’s Mac. The September 26 files were deliberately selected for their size; they were not a random sample. Neither result is a minimum or a prediction for every user, and the two savings figures must not be added together.
It is eight eligible archived conversations from one developer’s Mac. Active conversations, conversations linked to others, other AI tools and other Mint editions were not tested. The 35.1% result should not be extrapolated to your entire disk or all Codex installations.
We have not measured 24-hour regrowth or continued daily use after this operation. The private source conversations cannot be independently audited from the public page; the published measurements, comparison method and helper let others repeat the checks on their own data. No customer quote, star rating or independent endorsement is implied.
Frequently asked questions
Will my Codex conversations take 35.1% less space?
It depends on the files and the operation. 35.1% is the allocated-storage reduction of eight archived conversations with public Mint 1.0.99 on October 15. About 41% comes from a separate September 26 development-build test of a different, file-level compression method, comparing its exact reduction to a rounded 3.13 GB input. Scan your own Mac and measure the selected operation.
Were the files byte-identical, or only their content?
In the October 15 screenshot-optimization test, Undo preserved the checked text and decoded pictures in all eight files, but kept the smaller lossless picture encoding rather than reconstructing the original picture bytes. In the separate September 26 file-level compression experiment, all four files returned identical bytes.
Did the October 15 continuation test send private conversations to a model?
No. The continuation test used a local HTTP stand-in and stopped before model inference. Only anonymous aggregate measurements are published.
Find the opportunity on your own Mac
Start with a free scan. Review one supported Optimize action, then check the result and reopen what matters to you.