The MacBook in anthropics/claude-code Issue #18869 had a 1 TB drive. It still ran out. The user opened DaisyDisk and wrote: "I used DaisyDisk to dig into the issue and discovered folders taking up 472GB, both related to Claude CLI." One tool. One bug. Half a terabyte of debug logs and MCP traces. That number is the high-water mark for the question this post answers. Which AI coding tool uses the most disk space on a Mac, and what is the honest order behind it.
What does "disk space" actually mean for an AI coding tool?
A tool footprint on a Mac has three components and a comparison only makes sense if you separate them.
- The install. The
.appbundle ornpmglobal package. Usually 200 MB to 1 GB. Boring and stable. - The state. Auth tokens, settings, project memory, conversation history. Small, valuable, do not delete.
- The exhaust. Session logs, debug transcripts, packfiles, checkpoints, MCP server stdout, rollout snapshots, tmp worktrees. Big, fast-growing, and almost entirely disposable.
Every tool below has all three. The ranking is about category 3. That is where the 472 GB number lives. That is also where every safe reclaim happens, because deleting exhaust forces a regeneration on the next run rather than a re-auth or a project memory wipe.
Which AI coding tools are we comparing?
The eight tools below cover the majority share of AI coding usage on Mac as of mid-2026. The footprint numbers are drawn from public bug reports, the pain points roster, and a local 16-month audit on a working developer Mac, anonymised.
| Tool | Form | Headline paths | Typical heavy-user footprint | Worst-case bug |
|---|---|---|---|---|
| Claude Code | npm CLI | ~/.claude/, ~/Library/Caches/claude-cli-nodejs/ |
20 to 90 GB | 472 GB (Issue #18869) |
| Cursor | Electron app | ~/Library/Application Support/Cursor/, workspaceStorage .pack |
8 to 40 GB | 72 packfiles > 1 GB each |
| Codex CLI | npm CLI | ~/.codex/ (sessions, worktrees, logs, tmp) |
1 to 8 GB | tens of GB unannounced |
| Cline | VS Code ext | ~/Library/Application Support/cline/checkpoints/ |
4 to 30 GB | per-turn checkpoint blow-up |
| Windsurf | Electron app | ~/Library/Application Support/Windsurf/ |
3 to 15 GB | workspace storage growth |
| Factory AI | Electron app | ~/Library/Application Support/factory/ |
2 to 10 GB | cached droids and assets |
| Gemini CLI | npm CLI | ~/.gemini/ |
0.5 to 4 GB | session and tmp accumulation |
| Continue | VS Code ext | ~/.continue/, workspace storage |
1 to 6 GB | embeddings index growth |
The order is the realistic one for a developer who uses two or three of these tools daily. Claude Code is the outlier because its two disposable paths grow without any default cap. Everything else has a slower curve but the same shape.
Why is Claude Code the heaviest by a wide margin?
The two paths to know are ~/.claude/debug/ and ~/Library/Caches/claude-cli-nodejs/<project>/--mcp-logs-<server>/. The first is the CLI's own verbose log of each session. The second is the captured stdout and stderr of every MCP server spawned during each session, kept per project. Neither is garbage-collected unless you set cleanupPeriodDays in ~/.claude/settings.json.
For one project a week with no MCP servers, neither path matters. For five projects a day with three MCP servers each, you are writing fifteen independent log streams plus the base debug folder, every session. After four months of heavy use this is the 472 GB hole. The two related issues that confirm the pattern are Issue #10107 (300 GB file-history loop) and Issue #24207 (unbounded growth wipes auth at 0 bytes free).
The fix is small. The pattern is documented in the Claude Code 472 GB debug bug howto and in Cleaning Claude Code disk usage. For this comparison the takeaway is one number: Claude Code is the AI coding tool that uses the most disk space on a Mac, and the gap to the next tool is at least one order of magnitude under load.
Where does Cursor's footprint actually live?
Cursor is an Electron app, so it inherits the VS Code layout. The base install is around 600 MB. The footprint that grows over time is in three folders.
~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/holds per-workspace caches, embeddings, and.packfiles. The forum thread documenting this is forum.cursor.com on.packfiles eating disk space, where one user reported 72.packfiles over 1 GB plus 306 more in the 500 MB to 1 GB band.~/Library/Application Support/Cursor/CachedData/holds extension and language server caches that survive updates.~/Library/Application Support/Cursor/logs/holds renderer and extension logs.
A later Cursor update added a size limit to packfiles but the legacy data from earlier installs sticks around. The cleanup pattern is in the Cursor .pack files disk space guide. The headline number for this comparison: a heavy Cursor user with two years of workspaces sits at 20 to 40 GB across the three folders before a single byte of model output.
How big do Codex, Cline, Windsurf, and the rest get?
The mid-tier tools share a pattern. Each has one disposable folder that grows linearly with use and is rarely audited. None of them currently ship a retention cap on by default.
| Tool | Path | What it stores | Audit command |
|---|---|---|---|
| Codex CLI | ~/.codex/sessions/, worktrees/, tmp/, logs/ |
rollout snapshots, scratch repos, log streams | du -sh ~/.codex/* |
| Cline | ~/Library/Application Support/cline/checkpoints/ |
per-turn file checkpoints | du -sh ~/Library/Application Support/cline/ |
| Windsurf | ~/Library/Application Support/Windsurf/User/workspaceStorage/ |
workspace caches, embeddings | du -sh ~/Library/Application Support/Windsurf/ |
| Factory AI | ~/Library/Application Support/factory/ |
cached droids, build assets | du -sh ~/Library/Application Support/factory/ |
| Gemini CLI | ~/.gemini/ |
sessions, tmp | du -sh ~/.gemini/ |
| Continue | ~/.continue/ |
embeddings index, history | du -sh ~/.continue/ |
The Codex CLI numbers are from a real audit captured in openai/codex Issue #20864, which catalogued 380 MB of logs, 165 MB of worktrees, 98 MB of tmp data, and 81 MB of sessions on a single developer Mac after a few months of use. The Cline number is the one most likely to surprise: a refactor session over a large repo can write multi-GB per hour of checkpoints, so a power user blows past Cursor within weeks.
How do I audit all of them in one pass?
The script below is read-only. It runs across every path above and prints a size per row. Nothing is deleted. Run it once a month or before a low-disk event.
# Read-only audit of AI coding tool disk footprint on Mac.
# No deletion, no Trash, no settings change. Just numbers.
{
echo "=== Claude Code ==="
du -sh ~/.claude/debug 2>/dev/null
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null
du -sh ~/.claude 2>/dev/null
echo "=== Cursor ==="
du -sh ~/Library/Application\ Support/Cursor 2>/dev/null
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage 2>/dev/null
echo "=== Codex CLI ==="
du -sh ~/.codex 2>/dev/null
du -sh ~/.codex/sessions ~/.codex/worktrees ~/.codex/tmp ~/.codex/logs 2>/dev/null
echo "=== Cline ==="
du -sh ~/Library/Application\ Support/cline 2>/dev/null
echo "=== Windsurf ==="
du -sh ~/Library/Application\ Support/Windsurf 2>/dev/null
echo "=== Factory AI ==="
du -sh ~/Library/Application\ Support/factory 2>/dev/null
echo "=== Gemini CLI ==="
du -sh ~/.gemini 2>/dev/null
echo "=== Continue ==="
du -sh ~/.continue 2>/dev/null
} | tee /tmp/ai-tools-audit.txt
The tee writes a copy to /tmp/ai-tools-audit.txt so the audit can be diffed month over month. Two months of these snapshots is enough to draw the staircase that turns into a low-disk warning if nobody intervenes.
What is the safe order to reclaim space?
A safe reclaim sweep moves the disposable subpaths to Trash, leaves the state paths alone, and caps future growth with one settings change per tool that supports it. The order below is from highest reclaim per minute to lowest.
- Claude Code. Move
~/.claude/debugand~/Library/Caches/claude-cli-nodejsto Trash. Add"cleanupPeriodDays": 4to~/.claude/settings.json. Typical reclaim: 10 to 400 GB. - Cursor. Move
~/Library/Application Support/Cursor/User/workspaceStorageto Trash for workspaces you no longer open. Keep the recent ones. Typical reclaim: 5 to 30 GB. - Cline. Move
~/Library/Application Support/cline/checkpoints/<old-project>/to Trash for projects that are done shipping. Typical reclaim: 4 to 20 GB. - Codex CLI. Move
~/.codex/sessions/,worktrees/,tmp/,logs/to Trash. State (~/.codex/auth.json,config.toml) stays. Typical reclaim: 1 to 8 GB. - Windsurf and Factory AI. Move
User/workspaceStorage/and old cached droids. Typical reclaim: 1 to 5 GB. - Gemini CLI and Continue. The smallest tier. Move
~/.gemini/sessions/and~/.continue/index/if you switched assistants. Typical reclaim: under 2 GB.
Every step uses mv to ~/.Trash/ rather than rm -rf, so a Monday surprise is one drag away from rollback. The reasoning is in Move to Trash vs rm -rf.
Why does CleanMyDev exist for this?
The audit script above takes ten seconds. The reclaim decisions take longer because they are per-tool, per-subpath, per-project. Knowing that ~/.claude/debug is disposable but ~/.claude/projects is not, that cline/checkpoints/<old-project> is fine to drop but the embeddings index for the project you are shipping next week is not, is what a cleaner has to encode if it wants to do this safely.
CleanMyDev runs the same audit, shows the per-subpath sizes with a last-modified date and owning tool, and routes the ticked rows to Trash with a seven-day rollback window. No admin password, no subscription, no telemetry. CleanMyDev is $9.99 lifetime and the same audit costs nothing as a read-only mode if you want to see the receipts before you decide.