Last week my Mac started nagging me that storage was almost full. Twelve gigabytes left on a 460 GB drive, which is the kind of number that makes you close every app and start deleting old screenshots. I had just finished a WordPress migration for a branding project, so I blamed the thing I'd touched most recently.
I was wrong, and finding out how wrong took the rest of the afternoon. The entire project, database dump included, was 584 MB. The actual culprit was one file written by my AI coding assistant, and it was 91.5 GiB. ✦
🔍 Stop guessing, ask the disk
The mistake I almost made was cleaning up the thing I suspected instead of measuring first. Deleting a WordPress backup would have bought me maybe 600 MB and a false sense of progress. So I started at my home folder and let the numbers point the way:
# biggest things in your home folder, hidden ones included
du -sh ~/* ~/.[!.]* 2>/dev/null | sort -hr | head -20The line that stopped me was 93G ~/.codex. That's the local data folder for Codex, OpenAI's CLI coding agent. Ninety three gigabytes of it. So I went one level deeper and asked which session files were the fat ones:
find ~/.codex/sessions -name "*.jsonl" -type f -exec ls -la {} + \
| sort -k5 -n -r | head -5And there it was, a single line accounting for nearly all of it:
98277570375 rollout-2026-08-18T20-16-19-01a01797-....jsonl98,277,570,375 bytes. One file. A .jsonl, which is to say a plain text file with one JSON object per line.
🧾 What was actually in it
Codex keeps a rollout file per session: an append-only transcript of every message and every tool result, so it can restore context if you resume. Normally these are tiny. Mine was a four day design session that started on August 18 and was still going on the 22nd. Moodboards, a branding book, a lot of PDF generation and review, which means a lot of images going back and forth.
Every one of those images got written into the transcript as a full base64 payload:
{"type":"message","role":"user","content":[
{"type":"input_image","image_url":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..."}
]}Base64 is roughly 33% bigger than the binary it encodes, so a 4 MB PNG lands as about 5.5 MB of text. Individual records in my file ran 5 to 8 MB each. Now multiply that by four days of iterating on visuals, in a session that never restarted, in a format that only ever appends. Nothing dramatic happened. It just grew, quietly, in a folder I had no reason to look at.
The part that bugs me is that it's completely invisible while it happens. There's no warning, no size cap, no note in the UI that the session you're in has written 90 GB to your laptop. You find out when your operating system runs out of room.
🧹 The cleanup
Before deleting anything I checked that nothing was holding the file open, because deleting a file a running process still has a handle on doesn't give you the space back:
lsof ~/.codex/sessions/2026/08/18/rollout-2026-08-18T20-16-19-*.jsonlEmpty output, so nothing was writing to it. I deleted that one rollout and nothing else. No project files, no WordPress files, no git operations of any kind. That's worth saying out loud: when you're low on disk and frustrated, the temptation is to sweep. Don't sweep. Delete the one thing you've confirmed is the problem, then re-measure.
The result:
- Free space went from about 13 GB to about 105 GB.
~/.codexwent from 93 GB to 1.9 GB.- My current Codex session is 3.4 MB, which is what normal looks like.
🐛 Reporting it
I filed it as openai/codex#40111 and OpenAI Support has it logged too. For anyone who lands here from a search, the exact setup was:
- Codex CLI 0.148.0
- Model
gpt-5.6-sol - macOS on Apple silicon
- Running inside Orca's integrated terminal (1.4.186)
There's a 0.149.0 out now. I don't know yet whether it changes any of this, and I'd rather say that than guess.
💛 I still like the tool, which is sort of the point
This was my first week using Codex and I want to be fair about it, because the reason that session got so long is that the work was going well.
Its image generation is genuinely good, and the thing that won me over is that it reads my DESIGN.md and actually respects it. I can ask for a set of assets and get back things that use my palette, my type scale, my corner radii, instead of the generic gradient blobs every image model wants to give you by default. For someone who writes a design system in markdown before writing any UI, that's a big deal. It's why I kept feeding it images for four days straight.
So the bug isn't a reason to stop. It's a reminder that these tools write things to your machine that you never see, and "the AI is handling it" is not the same as "someone is watching it."
📋 What I do differently now
Five habits, all cheap:
- Check the agent's folder before blaming the project. When disk gets tight,
~/.codex,~/.claude, and friends get measured first. My instinct sent me to the wrong place and cost me an afternoon. - Start a fresh session for image-heavy work. A new rollout resets the file to zero. Long visual sessions are exactly the ones that balloon.
- Don't keep a visual session alive for days. Four days of moodboards in one transcript is how you get to 91 GB.
- Glance at the session folder size occasionally.
du -sh ~/.codex/sessionstakes a second and would have caught this on day two. - Confirm with
lsofbefore deleting. Then delete one file, not a category of files.
If you're doing image or PDF heavy work with any coding agent, go run du -sh ~/.codex ~/.claude right now. It takes a second, and I'd bet a few of you are sitting on something bigger than you'd expect.