DEV Community

Cover image for The folders eating your Mac's disk (and which ones are safe to delete)
DiskSpace AI
DiskSpace AI

Posted on

The folders eating your Mac's disk (and which ones are safe to delete)

A macOS update told me I needed 25 GB more. Finder said "System Data: 180 GB" and nothing else. If you write code on a Mac, most of that is probably yours: build output, package caches, simulators, containers and models. The good news is that a lot of it recreates itself.

Here's what I found, where it lives, and the right way to clean each one.

Start here: what recreates itself

These are copies. Delete them and the tool that made them makes them again when needed. Close the tool first.

What Where Clean it with
Xcode build data ~/Library/Developer/Xcode/DerivedData Quit Xcode, empty the folder
Xcode iOS symbols ~/Library/Developer/Xcode/iOS DeviceSupport Empty the folder
npm cache ~/.npm/_cacache npm cache clean --force
pnpm store ~/Library/pnpm/store pnpm store prune
Yarn cache ~/Library/Caches/Yarn yarn cache clean
pip cache ~/Library/Caches/pip pip cache purge
uv cache ~/.cache/uv uv cache clean
Homebrew cache ~/Library/Caches/Homebrew brew cleanup -s
Playwright browsers ~/Library/Caches/ms-playwright npx playwright uninstall --all

Prefer the tool's own command over rm -rf. pnpm store prune, for example, only removes packages no project references; deleting the whole store makes every project download everything again. (I keep a longer list, with Gradle, Bun and more, here: clear developer caches on a Mac.)

Then: big things that need a decision

Docker. Docker Desktop keeps images, containers, volumes and build cache in one virtual disk, Docker.raw. Finder may show its maximum size, not the real one. Check with:

docker system df
Enter fullscreen mode Exit fullscreen mode

docker system prune removes stopped containers, dangling images and build cache. Add -a to remove every image not in use. Leave volumes alone unless you know what's in them: that's where your databases live.

iOS simulators. Each one lives in ~/Library/Developer/CoreSimulator/Devices. This removes the ones for iOS versions you no longer have:

xcrun simctl delete unavailable
Enter fullscreen mode Exit fullscreen mode

Whole runtimes (5–10 GB each) go in Xcode → Settings → Components.

AI models. Ollama (ollama list, then ollama rm <model>), LM Studio and Hugging Face (huggingface-cli delete-cache) models are several GB each. They can be downloaded again, but only you know which ones you use.

Xcode archives. Old test builds can go. Keep the archives of versions you shipped: their dSYMs turn crash reports into readable code.

Old projects

node_modules (often 200 MB to 1 GB each) and .venv folders of projects you haven't touched in months can be deleted. npm install or uv sync brings them back from the lockfile.

Why "System Data" stays huge

Part of it is purgeable: local Time Machine snapshots and iCloud files macOS can release by itself. Installers don't always wait for that. Restarting usually helps, or:

tmutil listlocalsnapshots /
sudo tmutil deletelocalsnapshots /
Enter fullscreen mode Exit fullscreen mode

(Your backups on the external drive aren't touched.)

What I'd never delete

  • Anything in /System.
  • The Photos library file (delete photos from inside Photos).
  • ~/Library/Application Support folders of apps you still use: that's their data.
  • Anything a "cleaner" selects without telling you what it is.

The tool I built for this

Doing this by hand every few months got old, so I built DiskSpace AI. It maps the disk by safety color, explains 60+ kinds of folders like the ones above, pre-selects only what recreates itself and cleans each with its own command. Your own files are kept 7 days with Undo. It also ships an MCP server, so Claude Code or Codex can analyze the disk and propose a cleanup.

DiskSpace AI showing the disk by safety color

Analysis is free, and Pro is free for everyone during the beta: https://diskspaceai.com

Which folder eats the most space on your Mac? I'm collecting the ones I don't know yet.

Top comments (0)