The Storage panel on a 1 TB MacBook a friend sent me last month read 168.4 GB of System Data. He opened a ticket with AppleCare. The answer was the script answer: empty Trash, review large attachments, offload photos. None of those touch System Data. He hung up and texted me, "Apple won't tell me what System Data is." That sentence shows up often enough in keyword logs that it is the reason this post exists.
System Data is not one thing. It is at least seven things on any Mac, and Apple bundles them under one gray bar because the alternative is exposing per-tool cache directories in a UI built for AppleCare. The labels do exist. They are just not in the Storage panel. The rest of this piece is the working taxonomy, with paths, sizes from real audits, and the per-category rule for what is safe to reduce.
Why does Apple lump everything into System Data?
The Storage panel in System Settings is a triage UI, not an audit tool. Its job is to keep a non-technical caller off the line in under three minutes. Apple's nine labeled categories (Documents, Apps, Music, Photos, Mail, Messages, Podcasts, TV, iCloud Drive) map cleanly to consumer phone support workflows. Anything that does not fit gets the catch-all label.
That works fine on a stock Mac where the bucket is 15 to 25 GB of macOS plus a sleep image. It breaks on a developer Mac because the bucket grows linearly with how much tooling you install. There is no documented sub-taxonomy. There is no API to query it. The closest official guidance is the support page that tells you to restart, which clears the local snapshots, and then suggests you try again.
A developer in a January 2026 writeup of using Claude to free 200 GB from a full disk put it plainly. His disk was at 98.5 percent and the Storage panel told him nothing useful. His verbatim conclusion: "Docker was the biggest culprit. The volumes were almost entirely unused, probably from old postgres/redis containers I'd stopped months ago." Docker was 108 GB of his System Data, with zero indication of that in the UI.
The seven categories behind the gray bar
Below is the working taxonomy. It is the one I use when I open a fresh Mac with a complaint that System Data is too large. The percentages come from averaging 12 audits I have run on iOS and full-stack dev machines over the past six months. Your distribution will shift. The category list will not.
| # | Category | Typical size | Primary paths | Safe to reduce? |
|---|---|---|---|---|
| 1 | OS plus swap and sleep image | 15 to 25 GB | /System/, /private/var/vm/ |
No, system-managed |
| 2 | Dev toolchain caches | 30 to 80 GB | ~/Library/Developer/Xcode/, ~/Library/Developer/CoreSimulator/ |
Yes, rebuildable |
| 3 | AI tool state | 10 to 60 GB | ~/.claude/, ~/.codex/, ~/.cursor/, ~/Library/Caches/claude-cli-nodejs/ |
Yes, with audit |
| 4 | Container VM images | 5 to 110 GB | ~/Library/Containers/com.docker.docker/Data/vms/0/ |
Yes, prune |
| 5 | Time Machine local snapshots | 5 to 30 GB | /.MobileBackups/ |
Yes, tmutil deletelocalsnapshots |
| 6 | Mail, Messages, and large user dbs | 5 to 20 GB | ~/Library/Mail/V*/, ~/Library/Messages/ |
Partial, server keeps originals |
| 7 | Orphaned Application Support and logs | 3 to 15 GB | ~/Library/Application Support/, ~/Library/Logs/, /private/var/log/ |
Yes, if app uninstalled |
Categories 2, 3, and 4 are where the surprise sits. On the developer Macs I audit, those three together are 60 to 70 percent of the gray bar. The remaining four are background noise unless the user does something unusual, like keeping every Mail attachment ever sent.
What is actually in each System Data category?
A table row is not enough to act on. Here is the one-paragraph version of each, in size order, with the path you can verify yourself.
Category 2: dev toolchain caches
~/Library/Developer/Xcode/DerivedData/ holds per-project build artifacts, the module cache, and indexes. It rebuilds on next compile and is the safest single thing to delete on a developer Mac. Right next to it, ~/Library/Developer/CoreSimulator/ stores simulator runtime bundles for every iOS, watchOS, and tvOS version Xcode has ever downloaded, plus per-device data containers. Runtimes are 6 to 8 GB each and Xcode keeps the old ones across upgrades. Full per-folder breakdown in system data macbook 180gb breakdown.
Category 3: AI tool state
This category did not exist meaningfully 18 months ago. It grew fastest across 2025 and 2026. Claude Code writes to ~/.claude/projects/, ~/.claude/debug/, and ~/Library/Caches/claude-cli-nodejs/. Codex CLI writes rollout sessions to ~/.codex/. Cursor writes workspaceStorage with multi-gigabyte .pack files. The pathological case is documented in the Claude Code 472 GB postmortem, where ~/.claude/debug plus the MCP log directory reached 472 GB on one M1 Max user before the OS failed to install an update.
Category 4: container VM images
Docker for Mac stores its entire VM in one file at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. It grows with every image pull, build, and volume mount. It rarely shrinks without explicit docker system prune. The Storage panel reports it as System Data and gives you no way to inspect its internal state.
Category 1: OS, swap, and sleep image
Not actionable. macOS itself, the sleep image, and the active swap file live here. Apple manages them. Trying to touch /private/var/vm/swapfile* is the kind of thing that breaks a session.
Category 5: Time Machine local snapshots
Even with no external Time Machine drive attached, macOS keeps hourly local snapshots in /.MobileBackups/ for 24 hours, plus longer-lived snapshots when disk pressure is low. A restart often clears them. tmutil is the targeted alternative.
Category 6: mail and message databases
~/Library/Mail/V*/ and ~/Library/Messages/ hold cached attachments and the iMessage SQLite database. Both can balloon if you keep every attachment and have iCloud Messages mirroring chat history. The server keeps the originals, so a local prune is recoverable.
Category 7: orphaned Application Support and logs
~/Library/Application Support/ collects per-app state for every app that ever ran on the machine. When you uninstall an app by dragging it to Trash, Application Support is not cleaned. Cursor, Windsurf, GPT4All, Code-Insiders, and any other editor you tried once leaves a directory behind. ~/Library/Logs/ and /private/var/log/ rotate automatically but can grow if a chatty app misbehaves.
How do I size each category myself?
Five commands and you have the receipts. Run them in a Terminal session. None of them mutate state. Times are wall-clock on an M1 Max with the disk warm.
# Category 2: dev toolchain caches
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator 2>/dev/null
# Category 3: AI tool state
du -sh ~/.claude ~/.codex ~/.cursor 2>/dev/null
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null
# Category 4: container VM image
du -sh ~/Library/Containers/com.docker.docker 2>/dev/null
# Category 5: local snapshots
tmutil listlocalsnapshots / 2>/dev/null | wc -l
# Category 7: orphaned Application Support (top 20)
du -sh ~/Library/Application\ Support/* 2>/dev/null | sort -hr | head -20
Add the numbers up. If they get within 80 percent of your Storage panel's System Data number, the remaining 20 percent is OS, mail, logs, and rounding. If they explain less than half of System Data, you have a category I have not listed, which is rare, and the next pass is to scan ~/Library/ for any single folder over 1 GB.
Which categories should I clean first?
In order of safety and size payoff:
- Dev toolchain caches (Category 2). DerivedData rebuilds on next compile. Old simulators come back through the Components panel. Highest reward, lowest risk.
- AI tool state (Category 3). Trash the debug and log subdirectories first. Be careful with
~/.claude/projects/. Read is deleting~/.claudesafe before bulk deleting. - Container VM images (Category 4). Run
docker system prune -a --volumesafter confirming you do not need any volumes. - Local snapshots (Category 5).
sudo tmutil deletelocalsnapshots /is the targeted command. A reboot does the same. - Orphaned Application Support (Category 7). Trash directories for apps you have not run in six months.
Categories 1 (OS) and 6 (mail) should be a last resort. The local mail cache rebuilds when you reopen Mail, but it takes time.
What stays out of this taxonomy
iOS device backups in ~/Library/Application Support/MobileSync/ count toward System Data on some macOS versions; if you have ever synced an iPhone with Finder, that folder can be 20 GB on its own. I treat it as a special case inside Category 7, not its own bucket. Spotlight indexes and the rest of ~/Library/Caches/ are real but they are noise next to the seven categories above on a dev Mac.
Why does CleanMyDev exist if du already works?
du works fine. It is also a Terminal command that gives you raw sizes, not annotated paths with last-modified dates, owning-tool labels, or safety classes. CleanMyDev runs the same enumeration this post describes, attributes every byte to one of 110+ developer-specific cleanup targets, and shows the receipts before any deletion. Default action is Move to Trash, not rm -rf, so a wrong call is reversible for seven days. One-time $9.99 from the pricing page. The category list above is the literal mental model the app uses to organize its scan results.
The argument is not that you need an app to decode System Data. The argument is that the gray bar is hostile UI, the categories are real, and you should either learn the taxonomy or use a tool that already has it loaded.