Your Coding Agent Is Eating Your Disk

A coding agent is the least legible program most of us run. It writes files we did not open, spawns work we did not schedule, and keeps a history we never read. When it eats 50 GB of disk, the honest answer to *what is in there* is usually a shrug. So we opened it. On one developer's Mac, AI tools were holding **72.6 GiB**. Codex alone was 53.7 GiB across 21,613 files. Claude Desktop 11.8 GiB, of which 10.1 GiB was virtual-machine bundles. Cursor 5.4 GiB. Claude Code 1.5 GiB. Gemini CLI 0.2 GiB. :::agent-product-shot That total is not the interesting part. Every developer we have shown this to has a number like it. The interesting part is what the bytes *are* — because it is not what almost anyone guesses, including us. ### It is not the conversations The intuition is that a long-running agent writes a lot of text, and text adds up. It does not. Text is tiny. We streamed the 50 largest active session files — 10.9 GB — and hashed every embedded payload on device. Images accounted for **8.43 GB of the 10.9 GB**. Seventy-seven percent of a "conversation history" is pixels: screenshots the agent took, images it generated, visual tool output it read once. Then the number that actually matters. Of those 8.43 GB of images, only 5.17 GB were unique. **3.26 GB — 39% — were copies of something already stored in the same file.** 17,643 embedded images; 11,790 distinct ones; 5,853 repeats. :::agent-composition ### A summary that photocopies Here is the mechanism, and it is almost elegant in how it goes wrong. A long session eventually runs out of context. To keep going, the agent compacts its history: it summarises what happened so far and continues from the summary. Sensible. Necessary, even. But an image inside these sessions is not a path pointing at a file on disk. It is the whole image, inlined into the record as a data URL. And when a compaction record is written, some of them re-embed the image payload they just summarised rather than referring back to it. So round one carries the original. Round two carries the original plus round one's copy. Round three carries all of that again. The history does not shrink when it is compacted — it grows, linearly, in the size of everything visual that came before. :::agent-duplication-anatomy In the largest single session file we examined — 14 GiB, one conversation — there were 359 compaction events and 13.6 GiB of embedded image data. The unique image content in that file was **155 MiB**. Ninety-nine percent of it was the same pictures, over and over. Five particular images appeared between 45 and 136 times each. A summary that re-embeds what it summarised is not a summary. It is a photocopier with a filing cabinet attached. ### The part almost everyone gets wrong There is a popular explanation for agent disk bloat going around right now, and it is a good story: agents spawn subagents, subagents inherit the parent's history, each branch copies the payload again, and the tree multiplies until your disk is gone. More agents, more copies. We believed it too. Then we checked, because the machine could tell us. Codex keeps its own thread database, including a table of spawn edges — which thread was created by which. We attributed every rollout file on disk to its thread and asked where the 50.4 GiB actually sat. :::agent-attribution Root sessions started in the editor: **32.9 GiB, 65.4%**. Spawned subagent threads: 15.1 GiB, 30.0%. Command-line sessions: 2.1 GiB. Two thirds of the bytes never involved a subagent at all. This matters more than it looks. If fan-out were the cause, the fix would be an org-chart fix: run fewer agents, cap the concurrency, be more disciplined about delegation. Useful advice — but on this machine it would have recovered a third of the problem at most. The cause is the re-embedding, and re-embedding does not need a subagent. It needs a long conversation with pictures in it. Subagents multiply the problem; they do not create it. Fix the multiplication and you still have the problem. Fix the duplication and both get better at once. ### "Archive" does not free anything One more thing worth knowing, because it wastes people's afternoons: archiving a conversation in the agent moves the file from one directory to another. On the Mac we measured, 1,174 archived conversations held 16.1 GiB — every byte still there. Archiving is a tidiness feature, not a storage one. Nothing is reclaimed until something is actually deleted. ### Reading 14 GB without killing the machine A short engineering aside, because it nearly ended this investigation. Our first analyzer streamed those session files with Foundation's `FileHandle.read(upToCount:)` in a background loop. Every call returns an autoreleased buffer, nothing drains the pool until the loop ends, and the process simply keeps everything. Reading 1.15 GB put 1,097 MB resident. Pointed at a 14 GB file, the Mac ran out of application memory. The rewrite uses POSIX `open`/`pread` into one reusable buffer: the same 1.15 GB read holds 14 MB. Today the full inventory pass covers 72.6 GiB in 8.6 seconds at 28 MB resident, and the deep hashing pass streams 10.9 GB at 42 MB. There is a runtime assertion guarding it — if resident growth for a single streamed file crosses 256 MB, the pass stops itself rather than taking the machine down. We mention it because it is the whole reason a tool can look inside these files at all. An analysis that needs 18 GB of RAM to run is not an analysis anyone can ship. ### The fix is not deletion Once you know the bytes are duplicates, the right move stops being a judgement call. Deleting a conversation destroys work — you lose the reasoning, the diffs, the reason a decision was made. Nobody should be nudged into that to reclaim disk. But de-duplicating *inside* a conversation loses nothing: the first occurrence of every image stays exactly where it is, and each later duplicate becomes a small marker pointing back to it. :::agent-the-fix The conversation still opens in the agent. The screenshots are still visible. And because the first copy never left the file, the change reverses byte-for-byte from the file itself — no vault, no external state to lose. That is the shape we shipped in Mint: **Optimize** (reversible, de-duplicate in place), **Archive** (through the agent's own protocol, so its index stays consistent), and **Delete** (whole conversations, permanent, nothing pre-selected, and always through the agent's own delete path rather than behind its back). Nothing is pre-ticked. Every run shows the plan before it touches a file, and every action lands in a journal you can undo from. ### What we actually learned The reason agent storage feels like a black box is not that it is complicated. It is that nobody looks. The files are plain text on your own disk. The thread database is a SQLite file you can read. The duplication is measurable with a hash function and an afternoon. We went in expecting to write "agents generate a lot of data, here is a cleaner." We came out with something more specific and more useful: **most of it is not data, it is the same data.** And you can tell which is which — precisely, per file, on your own machine, without uploading anything. That distinction is the entire difference between a cleaner that asks you to trust it and a tool that can show you why. Mint does not delete your agent's memory to save space. It notices that the memory was written down eight times, keeps the first one, and gives you back the difference. --- *Every number here was measured with Mint's own scan hooks on one developer Mac in August 2026. The scans are read-only, run entirely on device, and you can reproduce them on yours.*