Agent sessions take a lot of disk space because every session is stored as a full, append-only transcript, and an agent turn is much heavier than a chat turn. On a real Mac we checked on October 23, 2026, ~/.codex was 26 GB, ~/.claude was 1.3 GB, and the single biggest Codex session file was 574 MB. Nothing was broken. This is what the formats are designed to do.
If you run coding agents all day, you will hit this. This post shows what we measured, why the files grow, what you can safely remove, and how to stop it coming back.
What did we actually measure?
We ran read-only du and find on one developer machine that uses both Codex and Claude Code daily. We did not open the transcripts, so the numbers below are sizes and counts, not content.
| Location | Size | What it holds |
|---|---|---|
~/.codex (total) | 26 GB | Everything Codex keeps locally |
~/.codex/sessions | 11 GB | 839 rollout .jsonl files, one per session |
~/.codex/packages | 7.6 GB | Downloaded runtime and tool packages |
~/.codex/thread_history_1.sqlite | 4.1 GB | Thread history database |
~/.codex/generated_images | 3.0 GB | Images the agent produced |
~/.claude (total) | 1.3 GB | Everything Claude Code keeps locally |
~/.claude/projects | 1.1 GB | 216 session .jsonl files |
Two facts stand out. First, only about 42% of the Codex folder is session transcripts. The rest is packages, a database and images, so "delete old sessions" alone will not fix a 26 GB folder. Second, the session distribution is heavy-tailed: 90 of the 839 Codex session files are over 50 MB, and the largest is 574 MB.
Why is a session file so big?
A chat app stores text you typed and text it answered. An agent harness stores the whole working state of a run. That includes several things that chat never has.
Tool outputs are stored in full. When the agent runs grep, reads a 2,000-line file, or prints a test log, that output enters the transcript so the model can see it on the next turn. The harness writes it to disk as part of the same record. One noisy build log can be larger than every message you typed in a week.
The same content is written again and again. Agents re-read files after editing them. Each read is a new record. A refactor that touches one file twenty times can store that file twenty times.
Sessions are append-only. Appending is the safe, fast way to write a log that must survive a crash. It also means the file only grows. Nothing rewrites it smaller when the context window is compacted. Compaction shrinks what the model sees, not what the log stores. For the context side of this, see Apple's SelfCompact research on self-compacting agents.
Long autonomous runs have no natural end. A goal-style or loop-style run can go for hours. The more turns, the more tool calls, and the file grows with the number of steps, not with the number of things you asked. If you use that style, read loop engineering for coding agents and expect larger transcripts.
Images and binary data get encoded as text. Screenshots and generated images are often base64 inside a JSON line, which inflates them by roughly a third compared with the raw file. Codex also keeps a separate generated_images folder, which was 3 GB here.
We have not profiled which of these dominates in our 574 MB file, and we are not going to guess. If you want a number for your own machine, the commands below will give you file-level sizes, and a short script that sums bytes per record type will tell you the rest.
Why is Codex so much larger than Claude Code?
Mostly volume and what each tool keeps. The Codex folder here is about 20 times the Claude Code folder, but the two are not a like-for-like pair.
- The Codex folder includes 7.6 GB of packages and a 4.1 GB database. Those are not transcripts.
- The Codex sessions folder is 11 GB for 839 files. Claude Code's projects folder is 1.1 GB for 216 files. Per file, Codex sessions average about 13 MB and Claude Code sessions about 5 MB on this machine.
- Usage differs. This developer ran far more long Codex runs than Claude Code runs over the same period.
So do not read this as "Codex wastes space". Read it as "any harness that logs full tool state will grow with how much autonomy you give it". If you compare the two on features, our Claude Code vs Codex rate limit comparison covers the usage side.
How do you find what is using the space?
Run these read-only commands. They change nothing.
# Biggest folders under each harness
du -sh ~/.codex/* ~/.claude/* 2>/dev/null | sort -h | tail -10
# How many session files, and how many are over 50 MB
find ~/.codex/sessions -name '*.jsonl' | wc -l
find ~/.codex/sessions -name '*.jsonl' -size +50M | wc -l
# The 10 largest session files
find ~/.codex/sessions ~/.claude/projects -name '*.jsonl' -exec du -k {} + \
| sort -rn | head -10
On macOS, du -sh works as shown and sort -h is available. Look at the output before you decide anything. The top ten files usually hold a large share of the total.
What can you safely clean up?
Treat each category differently, because they have different costs if you lose them.
| Category | Safe to remove? | What you lose |
|---|---|---|
| Old session transcripts | Yes, after you archive | Resume and history search for those runs |
| Packages and caches | Usually yes | A re-download the next time the tool needs them |
| Thread-history database | Only with the tool closed and a backup | History lists and some resume metadata |
| Generated images | Yes if you have copied the ones you want | The image files, not the code |
| Config, auth, skills | No | Your login and setup |
A cautious workflow that we recommend:
- List before you touch.
find ~/.codex/sessions -name '*.jsonl' -mtime +60shows what is older than 60 days. - Archive, then delete. Compress with
tarorzstd, move the archive to external storage, and only then remove the originals. JSONL compresses well because tool output is highly repetitive. - Close the tool first. Do not delete files from a session that is still running.
- Keep recent sessions. Anything you may resume this month stays put.
- Leave the database alone unless the tool documents a supported cleanup command.
Do not paste a blanket rm -rf ~/.codex from a forum. That removes your auth and settings along with the transcripts.
How do you stop it growing back?
Three habits help more than any one cleanup.
- Start fresh sessions for new tasks. A new session starts a new small file. Continuing one session for a week builds one huge file that is also slow for the model to carry.
- Cap tool output. Pipe noisy commands through
tailorhead, or point the agent at a log file path instead of printing the whole log. Less output in means a smaller transcript. Tools that keep bulky output out of the context window, such as the approach in context-mode MCP sandbox for agent context, help here for the same reason. - Move memory out of the transcript. If you keep resuming old sessions only to recover facts, write those facts into a short notes file or skill instead. See agents do not need memory, they need documentation and what are agent skills.
If you run several agents side by side, a control plane that shows sessions across tools makes oversized ones easy to spot. We covered one in AgentPlane for Claude Code, Codex and Cursor.
What this means for people building agent tools
If you build tooling on top of these folders, assume the worst case, not the median. A session browser, backup job or cleanup script that works on a 20 MB test folder can stall on a 26 GB home directory with hundreds of files above 50 MB.
Stream JSONL line by line instead of loading a file into memory. Never assume a file fits in RAM, since one of ours was 574 MB. Skip image-heavy lines when you only need text. Cache directory listings, and make every destructive action opt-in and listed first. Test against a real, large history, not a fixture. Tests that pass on a tidy fixture folder tell you little about what happens when a real user has years of runs on disk.
What people are asking
Does the agent read all of this every time? No. The harness opens the session you resume. The size matters for disk, backups and tools that scan the folder, not for each prompt.
Is the data sensitive? Treat it as sensitive. Transcripts can contain file contents, command output and pasted secrets. Do not upload a session folder to a cloud backup you do not control, and scrub before sharing a transcript for a bug report.
Will the tool prune for me? On this machine, evidently not: files from months back were still present. Check your version's release notes, because retention settings may be added.
Can I put sessions on an external drive? You can archive them there. Moving the live folder and symlinking it is possible, but test resume afterward and do it with the tool closed.
Summary
Agent sessions are big because a session is a complete, append-only record of an autonomous run, including every tool output, repeated file read and encoded image. We measured 26 GB in ~/.codex, 11 GB of it in 839 session files, with 90 files over 50 MB and one at 574 MB, against 1.3 GB in ~/.claude. Measure first, archive before deleting, start new sessions for new tasks, and build your own tooling for large histories.
Related reading
- Apple SelfCompact: self-compacting language model agents
- Loop engineering for coding agents with Claude Code
- Claude Code vs Codex: rate limit boost compared
- Context-mode MCP sandbox for agent context
- Agents do not need memory, they need documentation
- What are agent skills: complete guide
- AgentPlane: local control plane for Claude Code, Codex and Cursor
- Claude Code commands: complete reference
Sizes were measured on one machine on October 23, 2026. Folder layouts and retention behavior can change between Codex and Claude Code versions, so check your own folders before you delete anything.