Why does System Data keep growing on my Mac when I have not installed anything new?

Because the growth is not coming from new installs. On a developer Mac, System Data keeps growing from three background writers: APFS local snapshots that pin blocks after you delete files, Xcode and simulator caches that regenerate on every build, and AI tools like Claude Code, Cursor, and Codex that append session transcripts, MCP logs, and workspace snapshots on every request. None of them notify you.

I deleted 30 GB but System Data did not shrink. What happened?

APFS local snapshots. macOS holds up to 24 hours of local Time Machine snapshots that reference the blocks of files you deleted. Until every snapshot referencing those blocks expires, the space stays counted. Run `tmutil listlocalsnapshots /` to see them and `sudo tmutil deletelocalsnapshots ` to release the space early.

How much of the growth is macOS itself versus my tools?

On a stock Mac, macOS contributes maybe 15 to 25 GB to System Data and stays flat. On a developer Mac, tools add another 60 to 250 GB and keep climbing. The dev share is not part of macOS. It is Xcode, DerivedData, DeviceSupport, Docker.raw, AI tool caches, node_modules, and LLM model weights that macOS quietly files under System Data because they lack a documented category.

Is there a setting that stops System Data from growing?

There is no single macOS setting for it. There are per-tool caps. Xcode has a Locations setting for DerivedData. Claude Code takes `cleanupPeriodDays` in `~/.claude/settings.json`. Docker Desktop has a virtual disk limit. Ollama respects `OLLAMA_MODELS` for relocation. Each one has to be turned on individually. There is no master switch.

Should I trust a consumer cleaner to fix a growing System Data bar?

Only if it names the exact paths it wants to delete. Consumer cleaners marketed at general users tend to skip developer folders because deleting them can break active work. CleanMyDev shows every path, size, last-modified date, and owning tool before it moves anything, and it Moves to Trash so a mistake stays reversible for seven days.

How often should I audit System Data on a developer Mac?

Once a month is enough for most devs. Once a week if you use AI coding tools daily, because Claude Code, Cursor, and Codex can each add 5 to 30 GB in a heavy week. The audit is read-only, safe to run during a build, and takes about 90 seconds with `du -sh` on the 15 usual paths.

Why does System Data keep growing on my Mac even when I delete files?

You freed 40 GB from Downloads yesterday. You emptied Trash. You restarted. You open System Settings this morning and the gray System Data bar is 4 GB bigger than before you started. Not smaller. Bigger. If you searched for "system data keeps growing mac" and landed here, you are not imagining it. Apple's Storage bar is a residual, and on a developer Mac the writers that feed it never stop. This post names each one, explains why deletions do not shrink the bar immediately, and shows the exact commands to make the growth stop.

TL;DR

System Data keeps growing on Mac because three writers work in the background: APFS local snapshots that pin your deletions for up to 24 hours, developer toolchains (Xcode, DerivedData, Docker.raw, simulator runtimes) that regenerate caches on every build, and AI tools (Claude Code, Cursor, Codex, Ollama) that log every session. CleanMyDev audits all three in one read-only pass, shows receipts per folder, and Moves to Trash so you can reverse any call within a seven-day window.

Why does System Data grow at all when I did not install anything?

Apple computes System Data as a residual. macOS totals the six documented categories (macOS, Applications, Documents, Photos, Mail, Messages) and prints the leftover under System Data. That leftover is a real number of bytes, but Apple does not tell you which folder any of those bytes came from. So the "System Data" line is really "everything on this disk that Apple did not want to categorise for you."

On a developer Mac, the uncategorised bucket is where every tool you use dumps its state. Xcode files DerivedData under System Data. Docker Desktop's virtual disk lives there. Claude Code's ~/.claude/projects/ sits there. Ollama's model weights sit there. None of these tools are new files you consciously downloaded. They are the natural byproduct of using the tool at all.

Why does the bar not shrink after I delete files?

Three reasons, in order of frequency.

First, APFS local snapshots. macOS takes automatic Time Machine snapshots every hour and keeps them for up to 24 hours even without a Time Machine drive attached. A snapshot references the exact blocks that existed at snapshot time. When you delete a file, its blocks stay pinned by the snapshot until the snapshot expires. That is why a 30 GB Xcode DerivedData delete can free zero visible bytes for hours.

Second, background regeneration. You delete DerivedData at 09:00. You hit Cmd+B in Xcode at 09:05. Xcode rebuilds DerivedData and the folder is back to 12 GB before lunch. Same for ~/.cursor/, ~/.claude/projects/, ~/Library/Containers/com.docker.docker/. The tool refills what you emptied.

Third, spotlight lag. The Storage bar reads from the Spotlight index, not from a live filesystem walk. The index updates on a schedule. Terminal totals via du are always ahead of the bar by minutes to hours.

Sean Hyland's 200 GB reclaim writeup captured the pattern from the other side. He notes: Docker was the biggest culprit... The volumes were almost entirely unused, probably from old postgres and redis containers I had stopped months ago. The reason the volumes stayed is the same reason the bar does not shrink on your machine. Deletion is not the same as reclaim.

Which folders are actually growing on a dev Mac?

Here is the honest short list, ranked by how fast each one grows on a MacBook that ships iOS or uses AI tools daily.

Folder	Owning tool	Typical size	Weekly growth	Safe to delete?
`~/Library/Developer/Xcode/DerivedData`	Xcode	15 to 90 GB	2 to 20 GB	Yes, rebuilds
`~/Library/Developer/CoreSimulator/Devices`	Simulator	20 to 120 GB	1 to 10 GB	Case by case
`~/Library/Developer/Xcode/iOS DeviceSupport`	Xcode	5 to 40 GB	1 to 4 GB	Yes, recacheable
`~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`	Docker	5 to 108 GB	3 to 25 GB	Prune first
`~/.claude/projects/` and `~/.claude/debug/`	Claude Code	2 to 472 GB	1 to 30 GB	Yes, cap it
`~/Library/Caches/claude-cli-nodejs/`	Claude Code MCP	1 to 200 GB	1 to 40 GB	Yes
`~/.cursor/workspaceStorage/*.pack`	Cursor	3 to 60 GB	0.5 to 8 GB	Yes
`~/.codex/sessions/` and `worktrees/`	Codex CLI	0.5 to 30 GB	0.5 to 5 GB	Yes
`~/.ollama/models/`	Ollama	5 to 300 GB	Spiky	Archive first
`~/.cache/huggingface/{hub,datasets}`	Hugging Face	2 to 80 GB	1 to 15 GB	Yes

That covers most of what makes "mac system data won't clear" a search query. The point of the table is not to tell you to delete everything. It is to show that the growth is coming from ten identifiable writers, not from macOS.

How do I see which writer is inflating the bar right now?

Run this in Terminal. It is read-only. It does not modify, move, or delete anything. It walks each path and prints a size. On a warm build machine it finishes in under a minute.

paths=(
  "$HOME/Library/Developer/Xcode/DerivedData"
  "$HOME/Library/Developer/CoreSimulator/Devices"
  "$HOME/Library/Developer/Xcode/iOS DeviceSupport"
  "$HOME/Library/Developer/Xcode/Archives"
  "$HOME/Library/Containers/com.docker.docker/Data/vms/0/data"
  "$HOME/.claude/projects"
  "$HOME/.claude/debug"
  "$HOME/Library/Caches/claude-cli-nodejs"
  "$HOME/.cursor/workspaceStorage"
  "$HOME/.codex/sessions"
  "$HOME/.codex/worktrees"
  "$HOME/.ollama/models"
  "$HOME/.cache/huggingface"
  "$HOME/Library/Caches/pip"
  "$HOME/Library/Caches/Homebrew"
)
for p in "${paths[@]}"; do
  [ -e "$p" ] && du -sh "$p" 2>/dev/null
done | sort -rh | tee ~/Desktop/system-data-audit.txt

The output prints one line per folder, sorted largest first, and dumps a copy to your Desktop so you can diff it against next week's run. If your top three add up to 60 percent of your used disk, you have found the growth. Now you need to stop the writer, not just delete the output.

How do I actually stop the growth without breaking my toolchain?

Deletion is a moment. Caps are a policy. You need caps.

For Claude Code, set a cleanup period in ~/.claude/settings.json:

{
  "cleanupPeriodDays": 4
}

That single line is documented on Anthropic's Claude Code Issue #18869, where a user found 472 GB of debug and MCP logs and asked why the CLI did not cap itself. Four days is a fair floor. Seven days is the strict maximum you should tolerate.

For Xcode, quit it, then let DerivedData clear on your next build. Set Xcode > Settings > Locations > Derived Data to a Custom path on an external SSD if your internal disk is under 512 GB. Do the same for Archives.

For Docker Desktop, open Settings > Resources > Advanced and reduce the virtual disk size cap. Then run docker system prune -a --volumes inside a maintenance window to actually shrink the file.

For Ollama, move the models folder to an external drive by exporting OLLAMA_MODELS=/Volumes/ExternalSSD/Ollama/models in your shell profile. The models stay, the internal disk breathes.

For APFS snapshots, list and drop them explicitly so a big delete lands the same day:

tmutil listlocalsnapshots /
# Copy a date string from the list, then:
sudo tmutil deletelocalsnapshots 2026-07-02-183042

None of these are destructive. All of them are reversible. All of them stop the growth without stopping the tool.

What about the Storage bar itself, why is it so slow to update?

The Storage bar reads a Spotlight-backed index that lags real filesystem state by minutes to hours. Terminal du is authoritative and always current. If the bar and Terminal disagree, believe Terminal. If you need to force a bar refresh, sudo mdutil -E / reindexes the volume, though this is heavy and you rarely need it. For a routine audit, treat the bar as a summary and Terminal as the truth.

When is it worth using a tool instead of the shell?

The shell is fine for one audit. It is annoying for ten in a row. If you are running the audit weekly, you want a tool that walks the paths, remembers what it saw last week, shows a per-folder receipt, and Moves to Trash so a mistake stays reversible.

That is why CleanMyDev exists. Every row shows the path, its size, when it last changed, which tool owns it, and a risk label. Nothing gets deleted without you clicking through. The Trash-first policy means anything you regret is recoverable for seven days. It is a $9.99 lifetime app, not a subscription. See the pricing on the CleanMyDev homepage if you want the one-click version of the audit above.