The MacBook in anthropics/claude-code Issue #18869 had a 1 TB drive and still hit a low-disk wall. The owner wrote: "My Apple M1 Max with a 1TB drive failed to update macOS last night due to low diskspace, which surprised me." DaisyDisk eventually traced 472 GB to two Claude CLI paths. That number is not typical, but it sets the ceiling for the question this post answers. What does the AI coding tools disk footprint on a Mac look like in 2026, where does it live, and why is none of it visible from the macOS Storage pane?
What changed in 2026 that made this a problem?
AI coding tools in 2024 were chat boxes. You typed, they replied, the on-disk state was a small SQLite of message history. Three things stacked since then that turned that footprint into a category of its own.
The first is agents. A modern Claude Code or Codex CLI session is not a chat. It is a long-running loop that writes session state, tmp worktrees, rollout snapshots, and a verbose debug transcript for every step. A single agent run can produce tens of MB of disk writes before it finishes.
The second is MCP. Each Model Context Protocol server you wire up to Claude Code captures its own stdout and stderr in ~/Library/Caches/claude-cli-nodejs/<project>/--mcp-logs-<server>/. Five projects with three MCP servers each means fifteen independent log streams growing per session. Nothing rotates them by default.
The third is checkpoints. Cline saves a file-level snapshot per turn so the agent can roll back. A refactor session over a 200-file repo writes multi-GB per hour because every file gets a new copy in ~/Library/Application Support/cline/checkpoints/<project>/.
None of these three behaviours existed at scale two years ago. All of them are on by default in 2026.
What categories does the footprint break into?
A useful taxonomy turns "my Mac is full" into "category X grew Y GB last month." Every AI coding tool on Mac in 2026 fits into one or more of these five rows.
| Category | What it stores | Typical tools | Growth driver | Safe to clear? |
|---|---|---|---|---|
| Session transcripts | Per-turn user and model messages, verbose debug logs | Claude Code, Codex CLI, Gemini CLI | One run per debug session | Yes, regenerated on next run |
| MCP server logs | stdout/stderr of every MCP server per project | Claude Code primarily | Per server, per project, per session | Yes, diagnostic only |
| Workspace packfiles | Git-style packfiles for workspace state and embeddings | Cursor, Windsurf, Continue | Per-workspace, accumulates per edit | Yes, regenerated on workspace open |
| Per-turn checkpoints | File-level snapshots before each agent edit | Cline | Per turn, per file in scope | Yes, but breaks rollback to that turn |
| Embeddings indexes | Vector indexes for repo context retrieval | Continue, Cursor, Cline | Per workspace, per re-index | Yes, re-built on next index pass |
The first four are pure exhaust. The fifth, embeddings, has a small recompute cost. None of them are auth tokens, settings, or project memory, which is what people actually fear losing.
Where does each category actually live on disk?
The paths below are the canonical 2026 layouts. Anything under ~/Library and any dotfile in $HOME lands inside macOS's System Data bucket, which is why nothing here shows in the per-app Storage table.
# Session transcripts (Claude, Codex, Gemini)
~/.claude/debug/
~/.codex/sessions/
~/.codex/logs/
~/.gemini/sessions/
# MCP server logs (Claude Code)
~/Library/Caches/claude-cli-nodejs/<project>/--mcp-logs-<server>/
# Workspace packfiles
~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/
~/Library/Application Support/Windsurf/User/workspaceStorage/<hash>/
~/Library/Application Support/factory/
# Per-turn checkpoints
~/Library/Application Support/cline/checkpoints/<project>/
# Embeddings indexes
~/.continue/index/
~/Library/Application Support/Cursor/User/globalStorage/
Every hash in the table is the result of an MD5 over a workspace path, so the directory names are unreadable until you map them. The how-to for the Cursor mapping is in the Cursor .pack files disk space guide. The Claude paths are the focus of the cleaning Claude Code disk usage playbook.
How big does this get per developer profile?
The footprint is not uniform. It scales with how many tools you run, how many projects you touch, and whether you wire MCP servers in. The three profiles below cover most of the working developer population in 2026.
| Profile | Tools used daily | MCP servers | Active projects | Typical footprint | Risk of low-disk event |
|---|---|---|---|---|---|
| Light | One assistant (Cursor or Claude Code), no MCP | 0 | 1 to 3 | 5 to 15 GB | Low |
| Mixed | Cursor plus Claude Code, occasional Cline | 1 to 2 | 4 to 8 | 25 to 60 GB | Moderate over 6 months |
| Heavy | Claude Code plus Cursor plus Cline plus Codex, heavy MCP | 3 to 6 per project | 8+ | 80 to 250 GB | High within 4 months |
| Bug-triggered | Any profile under Claude file-history or debug bug | irrelevant | irrelevant | 300 to 472 GB | Immediate |
The bug-triggered row is the one to take seriously even on a light profile. The Claude Code 472 GB postmortem shows that a single watcher or log loop can wipe out a 1 TB drive without a single agent run. The companion guide which AI coding tool uses the most disk space ranks the tools by worst-case size so you know which path to check first when the warning appears.
Why doesn't macOS show this in Storage?
macOS has been quietly folding anything outside its own labels into System Data since Ventura. Apple's per-category bars cover apps, documents, photos, mail, messages, music, podcasts, TV, and a few others. Everything else, including every byte your AI tools write, lands in the gray bar with no detail.
The structural reason is that Apple's categories key off file metadata and well-known app data paths. A .log file inside ~/Library/Caches/claude-cli-nodejs/some-project/--mcp-logs-some-server/ does not match any of Apple's heuristics for a specific category, so it falls through to the catch-all. There is no setting that opens the box. The only way to see what is inside is to run du against the dotfile and Library paths yourself.
The longer treatment is in what is System Data on a Mac and system data vs other storage on Mac. For this post the takeaway is one line: AI coding tool exhaust is the fastest-growing slice of System Data in 2026, and it is invisible by design.
How do I run a read-only audit right now?
The script below is read-only. It touches nothing, prints sizes only. Run it once a month or before a low-disk event.
# Read-only AI coding tools footprint audit on macOS.
# No deletion, no Trash, no settings touched.
{
echo "=== Sessions and transcripts ==="
du -sh ~/.claude/debug 2>/dev/null
du -sh ~/.codex/sessions ~/.codex/logs 2>/dev/null
du -sh ~/.gemini/sessions 2>/dev/null
echo "=== MCP server logs ==="
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null
echo "=== Workspace packfiles ==="
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage 2>/dev/null
du -sh ~/Library/Application\ Support/Windsurf/User/workspaceStorage 2>/dev/null
du -sh ~/Library/Application\ Support/factory 2>/dev/null
echo "=== Per-turn checkpoints ==="
du -sh ~/Library/Application\ Support/cline/checkpoints 2>/dev/null
echo "=== Embeddings indexes ==="
du -sh ~/.continue/index 2>/dev/null
du -sh ~/Library/Application\ Support/Cursor/User/globalStorage 2>/dev/null
echo "=== Tool-state totals (for reference) ==="
du -sh ~/.claude ~/.codex ~/.gemini ~/.continue 2>/dev/null
} | tee ~/Documents/ai-tools-footprint-$(date +%Y-%m-%d).txt
The tee writes a dated copy under ~/Documents/. Two months of these is enough to draw the staircase. The first run usually surprises. The second run tells you which tool is the actual growth driver in your setup, not the one the bug reports made famous.
A real audit from the wild: the 200 GB cleanup writeup at brtkwr.com traced a 487 GB used disk down to 274 GB, with Docker as the biggest single category at 108 GB and AI tool caches close behind. The same script structure applies, the path set just widens.
Why does this matter for CleanMyDev?
The audit script tells you the size. It does not tell you which subpath is disposable, which one is auth, which one breaks the project you are shipping next week. That mapping is what a developer-aware cleaner has to encode. Knowing that ~/.claude/debug is safe to drop but ~/.claude/projects is not. Knowing that cline/checkpoints/<old-project>/ is fine to remove but the embeddings index for an active workspace will cost you an hour of re-index. Knowing that ~/.codex/auth.json stays and ~/.codex/sessions/ goes.
CleanMyDev runs the same five-category 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 audit costs nothing in read-only mode if you only want the receipts.