read

I wrote about cleaning Mac storage last year. That covered the basics: WhatsApp media, Xcode simulators, documentation cache.

But my storage filled up again. This time, instead of manually poking around folders, I ran Claude Code and asked it to help me find what’s eating my disk, feeding it with my instructions from the earlier blog post.

Your mileage will vary, every Mac accumulates different junk depending on what you use. But some of these discoveries were new to me, and I’ve been doing this for years.

I’ll hand it over to Claude from here to walk through what it found.

---

Claude here. The approach is the same du command from the original post, drilling down level by level:

du -h -d 1 ~/Library/ | grep "G\t" | sort -h

Find the heavy directories, run the same command one level deeper. Repeat until you hit the actual files. I just do it faster because I don’t get bored 5 levels deep into a path.

49 GB in 2 log files

The biggest find. Inside ~/Library/Logs/CoreSimulator/, two files:

File	Size
CoreSimulator.prev.log	35 GB
CoreSimulator.log	14 GB

Forty-nine gigabytes of simulator debug logs. Just sitting there. They’re safe to delete and get recreated automatically.

rm ~/Library/Logs/CoreSimulator/CoreSimulator*.log

If you’re an iOS developer who uses the simulator daily, check this folder. It might be your biggest win.

15 GB of dead containers

One simulator device was 21 GB. The app installed on it was nowhere near that big. Something was off.

I dug 5 levels deep and found com.apple.containermanagerd/Dead holding 15 GB. Every time you build and reinstall an app on the simulator, the old app container gets moved to this “Dead” folder. It never gets cleaned up.

The path is long:

~/Library/Developer/CoreSimulator/Devices/<UUID>/data/Library/Caches/com.apple.containermanagerd/Dead

Completely safe to delete. It’s orphaned data from previous installs.

iOS DeviceSupport (~5 GB per old version)

~/Library/Developer/Xcode/iOS DeviceSupport/ stores debug symbol caches that Xcode downloads when you connect a physical device. Each iOS version creates a new ~5 GB folder.

If you’ve updated your iPhone a few times, the old versions are just dead weight. Xcode re-downloads them if you ever connect a device running that specific version again. You can delete them from Xcode > Settings > Platforms, or just remove the folders directly.

Chrome’s hidden 4 GB model (per profile)

This one was genuinely surprising.

Each Chrome profile downloads a folder called OptGuideOnDeviceModel that contains a single weights.bin file. It’s 4 GB. It’s a Gemini Nano model that Chrome bundles for on-device AI features.

If you have 2 Chrome profiles, that’s 8 GB. Three profiles, 12 GB.

The annoying part: you can’t disable it. There’s no toggle in Chrome’s AI settings. And if you delete the folder, Chrome silently re-downloads it. So this one’s a known tax on your disk. Not actionable, just infuriating.

DerivedData (55 GB)

The classic one. ~/Library/Developer/Xcode/DerivedData/ is where Xcode stores build caches for every project. It’s safe to delete and Xcode rebuilds on demand.

rm -rf ~/Library/Developer/Xcode/DerivedData/*

We chose not to this time because all the projects were still active, and rebuilding a large production app is painful. But if you have stale projects in there, it’s worth clearing them out once in a while. 55 GB is a lot of disk for build artifacts.

Other quick wins

Outside of ~/Library/, I also scanned the home directory and found:

• Ollama models (~/.ollama): 16 GB of local LLM models not touched in months. ollama list to check, ollama rm <name> to remove.
• npm cache (~/.npm): 6 GB. npm cache clean --force to clear.
• Homebrew cache: 3 GB. brew cleanup --prune=all to clear.

All safe. They re-download as needed.

What we chose NOT to delete

Knowing what not to delete is just as important.

SwiftPM cache (6 GB): Deleting means re-fetching every package dependency on next build.

Claude’s VM bundle (7.8 GB): The Linux VM that Claude desktop uses for code execution. Deleting just forces a re-download.

MacWhisper models (4.4 GB): Actively used speech models. If you only use one transcription backend, you could delete the other.

The Time Machine trap

After deleting ~90 GB of files, df -h showed basically no change in available space. Trash was already empty.

The culprit: Time Machine local snapshots.

macOS creates hourly snapshots of your disk as a safety net between backups. Normally they’re cheap (APFS copy-on-write). But when you delete a lot of files, the snapshots taken before those deletions still reference the old data. APFS can’t reclaim the blocks until the snapshots expire.

# See your snapshots
tmutil listlocalsnapshots /

# Delete them all (doesn't affect external backups)
tmutil deletelocalsnapshots /

After deleting the snapshots, available space jumped from 14 GB to 189 GB. If you’ve just done a big cleanup and the numbers don’t add up, this is probably why.

The scorecard

What	Freed
CoreSimulator logs	~49 GB
Dead simulator containers	~15 GB
iOS DeviceSupport (old version)	~5 GB
Ollama models	~12 GB
npm cache	~6 GB
Homebrew cache	~3 GB
Total	~90 GB

Why this works well with an AI

I’m not doing anything a human can’t do. It’s the same du command, run repeatedly, following the biggest number deeper.

But I don’t lose my train of thought 5 levels deep into a path. I check every simulator’s Dead folder in one pass. I can tell you whether containermanagerd/Dead is safe to nuke without you having to Google it. And when something shouldn’t be deleted (like DerivedData with a long rebuild), I say so instead of just nuking everything.

Storage cleanup is tedious, repetitive, and needs judgment at every step. That’s kinda the sweet spot.

Perhaps a hard skill.