Why Do AI Coding CLIs Fill Your Disk And Never Clean Up?

In January 2026 a developer on an Apple M1 Max with a 1 TB drive tried to install a macOS security update. Five gigabytes free, install failed. They opened DaisyDisk and found 472 gigabytes of Claude Code debug logs and MCP cache under two folders they had never opened. Log files and cached tool output from an AI coding CLI. The tool that wrote 472 GB does not ship with a default cleanup policy, and neither do most of its competitors. Ai coding cli disk usage is a category macOS has no name for and the tools themselves refuse to bound.

Why do AI coding CLIs ship without a default disk cap?

Because they are optimised for the first ten minutes, not the first ten months. Every AI coding CLI has to solve the same shipping problem. Get a developer from install to a working chat in under three minutes on macOS, Linux, and Windows. Every second spent asking about log rotation, cache eviction, and disk budgets is a second the onboarding funnel loses. So the tools ship with the simplest possible default. Write everything to a hidden folder in the home directory and let the operating system deal with disk pressure later.

The problem is that macOS never surfaces the pressure until it is too late. The Storage bar files everything under ~/.claude/, ~/.codex/, ~/.cache/huggingface/, and ~/Library/Application Support/Cursor/ as System Data. By the time the developer notices, the folder is measured in tens or hundreds of gigabytes, and the fix is a chore that has nothing to do with what they were trying to build.

The second reason is that log data feels cheap when you write it and expensive when you delete it. If a bug report comes in and the debug log has been rotated, the tool cannot help. So the safe engineering default is to keep everything. That default is fine when a CLI has a few thousand users. It stops being fine when the CLI becomes a daily driver for hundreds of thousands of developers who each generate megabytes of tool output per session.

How much disk do these tools actually take on a working Mac?

Here is the observed range across the AI coding CLIs and IDEs a working developer is likely to have installed in mid 2026. Sources for the outlier numbers are in the code blocks below the table. The lower bound is a fresh install after one week. The upper bound is what shows up in issue trackers when a developer finally opens DaisyDisk.

The Ollama and Hugging Face rows are different in kind. Those are model weights the developer paid to download. They should not be deleted without a plan, they should be inventoried and relocated. The rest of the table is regenerable state. Every gigabyte in the top seven rows is a gigabyte a tool wrote without asking.

What would sane cleanup look like on a shipping AI coding CLI?

Three defaults, one command, and one documented separation. That is all it takes.

The three defaults are a dated log directory with a hard size cap, a per-session cleanup policy that ages out anything older than N days, and a max total footprint that logs an audible warning before it is exceeded. The one command is a --cleanup subcommand that runs read-only first, prints exactly what it will delete with size and last-modified date, and requires a second flag to actually delete. The one documented separation is a clear line in the docs between authentication files that must never be touched and cache files that are always safe to remove.

Here is what a read-only audit of the current state looks like on a developer Mac. Nothing here deletes. It is safe to run during an active session on any of these tools.

# Read-only audit of AI coding CLI disk usage.
# Safe to run while any tool is active. Nothing here deletes.

echo "== Claude Code =="
du -sh ~/.claude 2>/dev/null
du -sh ~/.claude/debug 2>/dev/null
du -sh ~/.claude/projects 2>/dev/null
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null

echo "== Codex CLI =="
du -sh ~/.codex 2>/dev/null
du -sh ~/.codex/sessions 2>/dev/null
du -sh ~/.codex/log 2>/dev/null

echo "== Cursor =="
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage 2>/dev/null
du -sh ~/Library/Application\ Support/Cursor/Cache 2>/dev/null

echo "== Cline, Windsurf, Factory, Gemini =="
du -sh ~/Library/Application\ Support/Code/User/globalStorage/saoudrizwan.claude-dev 2>/dev/null
du -sh ~/Library/Application\ Support/Windsurf 2>/dev/null
du -sh ~/.codeium 2>/dev/null
du -sh ~/.factory 2>/dev/null
du -sh ~/.gemini 2>/dev/null

echo "== Model weights (not junk, inventory only) =="
du -sh ~/.ollama/models 2>/dev/null
du -sh ~/.cache/huggingface 2>/dev/null

The numbers will surprise most developers. In the 200 GB reclaim writeup on brtkwr.com, the author noted:

"After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB."

The tail is always AI tool state. A read-only pass is the entire fix. What you cannot see, you cannot decide about.

The Claude Code team eventually added a cleanupPeriodDays setting after issue #18869. The fix is a single line in ~/.claude/settings.json.

# Cap Claude Code retention at 4 days.
mkdir -p ~/.claude
python3 -c 'import json,os,sys,pathlib
p=pathlib.Path.home()/".claude"/"settings.json"
d=json.loads(p.read_text()) if p.exists() else {}
d["cleanupPeriodDays"]=4
p.write_text(json.dumps(d,indent=2))'
cat ~/.claude/settings.json

That is the entire fix for one tool. Multiply it by every AI coding CLI on the machine and you have a chore that should have been the default.

Whose job is it to clean up an AI coding CLI's disk footprint?

This is where the argument gets uncomfortable. There are three parties who could take responsibility, and none of them currently do.

The first party is the tool vendor. They have the best information about which files are safe to delete because they wrote the file format. They also have the strongest incentive not to be the tool that broke a developer's laptop. So they ship without caps.

The second party is Apple. macOS already sets a low-disk warning threshold. It could easily surface a per-folder growth alert for the top ten fastest-growing folders in the home directory. It could label AI tool folders in the Storage bar instead of folding them into System Data. It does neither. See our post on why macOS Storage Recommendations skip every developer folder for the full argument.

The third party is the developer. Right now the entire burden is here. Read the release notes. Learn the paths. Write your own cron job or launchd plist. Or use a tool that does the audit for you.

How should a Mac cleaner treat AI coding tools?

Not the way consumer cleaners treat them. Consumer cleaners assume every cache is safe to purge and every folder in the home directory is fair game. That assumption breaks the second it touches ~/.claude/settings.json or ~/.codex/auth.json. A developer-honest cleaner has to know the difference between a cache subpath, a session subpath, and an auth file, and it has to show that difference on screen before it touches anything.

The receipt model matters here. Show path, size, last-modified date, owning tool, and a risk label per row. Let the developer decide row by row. Move to Trash by default so a wrong click is a seven-day mistake, not a permanent one. That is the argument in our receipts-first cleanup piece and it is exactly the shape a fix for ai coding cli disk usage needs.

This is where CleanMyDev fits. It maps ~/.claude, ~/.codex, ~/.cursor, ~/.cline, ~/.factory, ~/.gemini, and their sibling caches to one screen with per-tool totals. It never touches auth files. It never runs as root. It Moves to Trash. If you want a receipts-based audit of your AI coding tool footprint that takes one click and shows every path before anything moves, get CleanMyDev for $9.99 lifetime on the pricing page.

What changes if nothing changes?

Two things get worse. First, the average AI-tool footprint grows because feature velocity is high and cache formats keep evolving. Every new tool adds a new hidden folder. The set is already ten tools long and growing. Second, the failure mode shifts from a slow annoyance to a hard block. A failed OS update because of low disk is not a "clean it later" problem. It is a "the machine cannot install a security patch" problem. Every tool that ships without a disk cap is one issue tracker post away from being that story.

The right pressure point is release notes. When a tool team writes "improved default caching" or "reduced disk footprint by 60%" in a changelog, that is a signal the category is starting to police itself. Until then, the audit is on you.

Related reading

• Is it safe to delete ~/.claude? A skeptical audit
• Audit before delete: the default workflow of a developer Mac cleaner
• When not to clean a developer Mac