What was actually inside my Mac's 180 GB System Data autopsy?

A 180 GB System Data autopsy on a working developer Mac broke down to 64 GB of Xcode artifacts, 47 GB of Claude Code logs and MCP captures, 22 GB of orphaned Docker volumes, 14 GB of Ollama model weights, 11 GB across the three Hugging Face caches, 9 GB of Codex CLI session rollouts, 7 GB of Cursor `.pack` files, and a long tail of npm, pnpm, and Homebrew caches. macOS labels none of it. CleanMyDev runs the autopsy in one pass and prints the per-row receipt so you reduce System Data without nuking the auth tokens hiding three folders deeper.

What did the 180 GB gray bar actually contain?

You cannot ask Finder. Finder hides ~/Library and every dotfolder. macOS Storage shows the same gray bar with less detail. The only honest tool is the terminal, and the only honest commands are du -sh and a sort.

Here is the breakdown of what the gray bar was on my machine that morning, ordered by size.

Owner	Path	Size	Apple classifies as
Xcode	~/Library/Developer/Xcode/	64 GB	System Data
Claude Code	~/.claude/ plus ~/Library/Caches/claude-cli-nodejs/	47 GB	System Data
Docker	~/Library/Containers/com.docker.docker/Data/vms/0/	22 GB	System Data
Ollama	~/.ollama/models/	14 GB	System Data
Hugging Face	~/.cache/huggingface/{hub,datasets,transformers}	11 GB	System Data
Codex CLI	~/.codex/sessions/ plus worktrees/	9 GB	System Data
Cursor	~/.cursor/extensions/ plus user globalStorage	7 GB	System Data
Long tail	npm, pnpm, Homebrew, Playwright, Go, Yarn	6 GB	System Data
Total		180 GB	All gray bar

Every byte in that table lives in a directory Apple does not understand. None of those owners ships a storage dashboard. The gray bar is what happens when six tools write to hidden paths and one operating system refuses to aggregate them. This pattern is not just me. The brtkwr.com writeup of using Claude to free 200 GB from a full disk hit the same wall from the opposite direction: "Docker was the biggest culprit. The volumes were almost entirely unused, probably from old postgres/redis containers I'd stopped months ago." Different machine, same shape.

How do you produce the autopsy yourself?

The audit is read-only. Nothing here deletes a byte. Paste this in Terminal and you have your own version of the table within ninety seconds.

# 1. Top-level disk truth, ignore the gray bar
df -h /

# 2. Xcode artifacts: DerivedData, Archives, simulators, device support
du -sh ~/Library/Developer/Xcode 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator 2>/dev/null

# 3. Claude Code: debug, projects, MCP log captures
du -sh ~/.claude ~/.claude/debug ~/.claude/projects 2>/dev/null
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null

# 4. Docker: the raw disk image is the real footprint
du -sh ~/Library/Containers/com.docker.docker/Data/vms/0 2>/dev/null

# 5. Local LLM caches: models and triple-cache
du -sh ~/.ollama/models 2>/dev/null
du -sh ~/.cache/huggingface/hub \
       ~/.cache/huggingface/datasets \
       ~/.cache/huggingface/transformers 2>/dev/null

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

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

# 8. JS, Python, Go, Homebrew long tail
du -sh ~/.npm ~/Library/pnpm/store ~/.bun \
       ~/Library/Caches/Homebrew \
       ~/Library/Caches/ms-playwright 2>/dev/null

The whole script runs in under two minutes on a populated dev Mac. Save the output. That output is your autopsy.

Why is Xcode the single biggest line?

Xcode held 64 GB across four subfolders. DerivedData was 19 GB of cached build products. Simulator runtimes added 28 GB across three iOS major versions still on disk. iOS DeviceSupport was 11 GB of cached debug symbols for every iPhone that had ever plugged into the Mac. Archives was 6 GB of .xcarchive bundles from TestFlight builds I had already shipped.

None of this is junk. Each piece exists for a reason Xcode wrote it. The problem is that Xcode never expires any of it. There is no garbage collector that says "you have not built against iOS 16.4 in eight months, do you still need this 9 GB runtime." The decision belongs to you. The safe playbook is in how to reclaim disk from Xcode simulators.

Why is Claude Code the second biggest line?

47 GB of one CLI tool sounds like a bug. It is documented behaviour. Claude Code writes diagnostic logs to ~/.claude/debug, project transcripts to ~/.claude/projects/, and captures stdio from every MCP server into ~/Library/Caches/claude-cli-nodejs/<project>/--mcp-logs-*. None has a size cap unless you set one.

I am on the smaller end of this curve. The catastrophic case is anthropics/claude-code Issue #18869, where one developer's M1 Max with a 1 TB drive could not install macOS updates because the same two folders had reached 472 GB:

"My Apple M1 Max with a 1TB drive failed to update macOS last night due to low diskspace, which surprised me. I used DaisyDisk to dig into the issue and discovered folders taking up 472GB, both related to Claude CLI."

The mitigation Anthropic added is one line in ~/.claude/settings.json: "cleanupPeriodDays": 4. Most users will never know to set it. The full surgical pattern is in the Claude Code 472 GB debug bug fix.

Which lines are pure waste and which are not?

A System Data autopsy is only useful if you can sort what to delete from what to keep. Almost none of this is pure waste. Most of it is cached state with real value the day you re-open the project. The cleanup question is not "is this junk" but "is the value of keeping this higher than the value of the disk space."

Line	Cost to redownload	Safe to delete
Xcode DerivedData	Minutes per project	Yes, it rebuilds
Simulator runtimes	2 to 4 GB each, slow	Only versions you do not build against
iOS DeviceSupport	Free, on next device connect	Yes, regenerates
Xcode Archives	Cannot redownload, ship-history loss	Only after dSYM upload
Claude ~/.claude/debug	Zero, diagnostic only	Yes, no functional impact
Claude MCP log cache	Zero, captures only	Yes
Claude projects/	Loss of transcript history	Per-project decision
Docker volumes	Recreatable from images	Only stopped containers you confirm
Ollama models	Tens of GB per model, slow	Only models you actively chose to remove
Hugging Face datasets	Slow, often gated	Yes if you can re-pull
Codex sessions	Loss of agent history	Per-session decision
Cursor old .pack files	Free, IDE reseeds	Yes
npm cache	Free, lazy	Yes

The diff between "safe" and "unsafe" is rarely a whole folder. It is almost always a per-subpath judgement. This is why a one-button cleaner that nukes everything tagged "cache" is dangerous, and why a per-row receipt is the only safe shape.

What did the cleanup actually look like?

I ran the cleanup in three passes over an afternoon. Every pass used mv to ~/.Trash rather than rm -rf, on the principle that APFS-backed Trash is the cheapest rollback window I will ever get; the argument is in Move to Trash vs rm -rf for a developer Mac.

Pass one was the obviously safe deletes: Claude debug logs, Claude MCP captures, old DerivedData per project, expired iOS simulators, npm cache, Homebrew cache. 71 GB in twenty minutes, zero judgement calls. Pass two was per-item decisions: Docker volumes confirmed dead, Ollama models I had not used in two months, Hugging Face datasets pulled for a one-off notebook, Cursor .pack files older than 90 days. Another 41 GB in about an hour. Pass three was the long tail: pnpm store prune, dead node_modules in archived side projects, Playwright browser binaries from versions I no longer used, Archives I had already resymbolicated. Another 17 GB.

Total reclaim: 129 GB. macOS Storage took about forty minutes to update the gray bar; df -h / showed the truth instantly. The Storage tab eventually caught up and went from 178.6 GB to 49.8 GB without any other action on my part.

Why does this keep happening?

The developer toolchain on macOS in 2026 is dozens of independent tools writing to hidden paths with no shared garbage collector. Apple's Storage classifier was written before AI coding CLIs, container runtimes shipping 64 GB raw disk images, or local LLM model managers, so anything in a directory macOS does not recognize falls through to System Data. The tooltip on the gray bar says "caches, logs, and other data used by the system." On a developer Mac, "the system" is twelve tools none of which Apple wrote. The wider read is in System Data vs Other storage on Mac.

What is the standing maintenance routine?

After the autopsy I now run a shorter version of the same script on the first Sunday of every month, plus a pnpm store prune, plus a docker system prune --volumes after confirming which volumes are dead. The point is not to keep System Data at zero. The point is to keep it at a number I understand. A 60 GB gray bar I can name is fine. A 180 GB gray bar I cannot is the bug.

If the routine sounds like work, it is. The reason CleanMyDev exists is that this should be one click with a receipt at the end, not ninety minutes of du -sh and four hours of Trash-and-confirm. CleanMyDev runs the full System Data autopsy and queues every reducible line for Move-to-Trash for $9.99 once. Per-row size, last-modified date, owning tool, risk label. No subscription, no scareware, no sudo, no silent deletes.

Related reading

• How AI coding tools quietly filled 247 GB of my MacBook in 16 months
• Claude Code 472 GB postmortem: where the disk space went
• Docker had 108 GB of forgotten volumes on my Mac