How did AI coding tools quietly fill 247 GB of my MacBook in 16 months?

The first time I noticed, my MacBook would not install a macOS point release. Available space said 6.2 GB. The installer wanted 18. I had bought a 1 TB drive specifically so I would never see that dialog. I ran DaisyDisk and stared at folders I did not remember creating. Sixteen months earlier I had installed Claude Code on a clean machine. The day I ran that audit, the AI coding tools on my Mac were holding 247 GB, and almost none of it was anything I had chosen to keep.

This is the receipts version. Where every gigabyte came from, which tool wrote it, and what the timeline looked like month by month. If you have been running Claude, Cursor, Codex, Cline, Ollama, or Hugging Face for more than a year, your numbers are probably within an order of magnitude of mine.

What did the first 16 months of AI tool installs actually look like?

The shape matters. February 2025 was Claude Code as my first AI CLI. By April I was using Cursor as my main editor. In July I added Codex CLI for parallel agent work. October was Ollama, to test offline coding. December was Hugging Face, because I started fine-tuning a small classifier. Cline arrived in February 2026 when I switched to a checkpoint workflow inside VS Code.

Six tools in sixteen months. Each install was a deliberate productivity decision. None of the installs was a decision to keep 47 GB of MCP logs or 18 GB of Hugging Face datasets I had loaded for one notebook. Those accumulated as a byproduct, in directories Finder hides by default. You do not feel a 200 GB problem land. You feel a 200 MB problem land sixty times.

Where did the 247 GB actually live?

Here is the audit I ran when DaisyDisk first showed me how bad it was. Every row is a real du -sh from my machine on the day I started cleaning.

A few rows deserve a sentence.

The Claude Code 64 GB was not catastrophic by the standards of anthropics/claude-code Issue #18869, where one user hit 472 GB on a 1 TB drive: "I used DaisyDisk to dig into the issue and discovered folders taking up 472GB, both related to Claude CLI." I was on the same path, earlier in the timeline.

The Cursor 28 GB was concentrated in .pack files inside extensions. The Cursor forum thread on .pack eating disk space reports one user with 72 .pack files over 1 GB. A later Cursor update added a size limit, but old .pack data did not retroactively shrink.

The Codex CLI 19 GB was rollout sessions and worktrees, tracked in openai/codex Issue #20864: 8.4 GB of session logs, 6.1 GB of forgotten worktrees, 3.2 GB of .tmp files.

The Ollama 98 GB was easiest to explain and hardest to delete. Models are not junk. They are expensive-to-download assets. The right move is inspect, archive the ones you might want, delete the rest. My 70B model was 40 GB of that 98 GB. I had run it twice.

How does an audit script look for your own Mac?

Here is the read-only audit I now run on the first Sunday of every month.

# Claude Code
du -sh ~/.claude ~/.claude/debug 2>/dev/null
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null

# Cursor
du -sh ~/.cursor 2>/dev/null
find ~/.cursor/extensions -name "*.pack" -size +100M 2>/dev/null

# Codex CLI
du -sh ~/.codex ~/.codex/sessions ~/.codex/worktrees 2>/dev/null

# Cline checkpoints
du -sh ~/Library/Application\ Support/Code/User/globalStorage/saoudrizwan.claude-dev 2>/dev/null

# Ollama models
du -sh ~/.ollama/models 2>/dev/null
ollama list

# Hugging Face triple cache
du -sh ~/.cache/huggingface/hub ~/.cache/huggingface/datasets ~/.cache/huggingface/transformers 2>/dev/null

I had been on this Mac for sixteen months before I wrote that script. None of these tools shows a disk dashboard, and macOS does not classify these paths in Storage settings. The audit only happens if you run one.

Why does macOS hide this under System Data?

Three reasons. Every one of those paths lives under ~/Library or a dotfolder like ~/.claude. Finder hides Library by default and dotfolders are invisible to the GUI entirely. Apple's Storage classifier was written before AI CLIs existed, so bytes filed under unknown directories show up as System Data with no breakdown, the wider write-up is in System Data vs Other storage on Mac. And none of these tools owns a surface where a user would expect a number, Claude Code is a CLI, Ollama is a daemon, Hugging Face is a Python library. There is no app icon to right-click for storage usage.

How does the per-tool curve grow over time?

A snapshot tells you where you are today. The curve tells you when you will hit the next OS update failure. Here is the month-over-month growth I saw across the 16 months.

The shape is staircase, not linear. Each new tool adds an install chunk, then slow log accretion until the next major version drops a new cache directory. Most developers notice the problem all at once instead of gradually.

The brtkwr writeup of using Claude to free 200 GB from a full disk found the same staircase from the opposite end: Docker at 108 GB, Library Application Support at 83 GB. A working developer Mac in 2026 carries a quarter terabyte of dev-tool overhead before opening a single project.

What does a safe cleanup pass actually look like?

The instinct after seeing 247 GB is rm -rf everything ending in .cache or .claude or .ollama. That is the wrong instinct. Each folder mixes diagnostic output you can delete with auth tokens and project memory you cannot. The wrong delete wipes your Claude auth at zero bytes free, the cascade documented in Claude Code Issue #24207.

The right pass is per-tool, per-subpath. For Claude, target only ~/.claude/debug and the MCP logs cache, see cleaning Claude Code disk usage. For Cursor, target old .pack files, see Cursor .pack files and disk space. For Codex, target old session rollouts. For Cline, target checkpoints from archived projects. For Ollama, list models and decide one at a time. For Hugging Face, sweep the datasets cache hardest because it costs nothing to redownload.

Every pass uses mv to ~/.Trash first. Empty Trash later, after you have rebooted and confirmed nothing broke. That discipline turns a 247 GB cleanup into a reversible operation.

What does this mean for the next 16 months?

Three takeaways.

One, the AI tools disk footprint is a regular operational cost of being a developer on macOS. Treat it like your node_modules graveyard, your Docker volumes, and your DerivedData. Audit monthly.

Two, every new AI tool starts at zero and grows on a staircase. The cost is not the binary, it is the year of background log and cache accretion that follows. Bookmark the data directories the day you install, not the day macOS refuses to update.

Three, no single tool is the villain. Each one does the engineering-correct thing inside its own scope. The bug is at the system level, where six tools write to hidden paths and macOS does not aggregate them into a number you can act on. That aggregate is the gap CleanMyDev was built into.

If you would rather not run the audit script by hand every month, CleanMyDev runs the full AI tools disk footprint scan in one click for $9.99 once. Claude, Cursor, Codex, Cline, Ollama, Hugging Face, all sized, labeled, and queued for Move-to-Trash with risky paths flagged in red. Never sudo, never silent, receipts before deletion.

Related reading

• Claude Code 472 GB postmortem: where the disk space went
• Docker had 108 GB of forgotten volumes on my Mac
• System Data autopsy: how 180 GB of my Mac was developer leftovers