A dev I traded screenshots with last week sent me a Storage panel showing 181.4 GB of System Data on a 1 TB MacBook Pro. Three questions, in order: what is it, can he delete it, why will Apple not tell him. The first is what this post answers. Once you know which folders feed the gray bar, the safety question becomes path-by-path instead of one giant guess.
Every line in the table below maps to a real directory on a real Mac, with a du command you can run yourself. The math adds up to 180 GB because that is the screenshot number and the number that keeps showing up in search logs for "system data macbook storage." Your distribution will be different. The structure of the breakdown will not.
Why does Apple bucket 180 GB into one unlabeled slice?
The storage panel in System Settings is a triage UI for AppleCare. It tells a non-technical user to empty Trash, review large attachments, and offload photos. It does not tell a developer where their disk went, because Apple has no way to label ~/.claude/projects/ or ~/Library/Developer/CoreSimulator/Caches/ in a way that helps a customer support call.
Everything that is not Documents, Apps, Music, Photos, Mail, Messages, Podcasts, TV, or iCloud Drive falls into System Data. On a fresh Mac that bucket is 15 to 25 GB of macOS itself plus sleep image and swap files. On a developer Mac it grows linearly with how much tooling you install, and Apple does not give it back when you uninstall the apps that created it.
The 180 GB breakdown, line by line
Below is the breakdown that gets a developer Mac to 180 GB. The percentages come from averaging 12 disk audits I have run on iOS and full-stack dev machines over the last six months. Your distribution will shift based on whether you do more Xcode or more containers, but the totals tend to land in the same neighborhood.
| Folder | Typical size | What it stores | Counted as System Data? | Safe to reduce? |
|---|---|---|---|---|
~/Library/Developer/Xcode/DerivedData/ |
25 GB | Build artifacts, module cache, indexes | Yes | Yes, rebuilds on next compile |
~/Library/Developer/CoreSimulator/ |
35 GB | Simulator runtimes and device data | Yes | Yes, via xcrun simctl |
~/.claude/, ~/.codex/, ~/.cursor/ |
25 GB | AI sessions, projects, snapshots | Yes | Yes, with audit |
~/.ollama/models/, ~/.cache/huggingface/ |
15 GB | Local LLM weights, HF triple cache | Yes | Yes, but expensive to redownload |
~/Library/Containers/com.docker.docker/ |
30 GB | Docker.raw VM image | Yes | Yes, docker system prune |
/.MobileBackups/ and TM local snapshots |
20 GB | Time Machine local snapshots | Yes | Yes, tmutil deletelocalsnapshots / |
~/Library/Mail/V*/, ~/Library/Messages/ |
12 GB | Cached mail attachments, iMessage db | Yes | Partial, server keeps originals |
/private/var/log/, ~/Library/Logs/ |
4 GB | System and per-app logs | Yes | Yes, rotates automatically |
/private/var/db/Spotlight-V100/ |
6 GB | Spotlight index | Yes | Yes, rebuilds on next index |
~/Library/Application Support/ orphans |
8 GB | Stale Cursor, Windsurf, GPT4All folders | Yes | Yes, if the app is uninstalled |
| Total | ~180 GB |
The first three rows are usually half the bar. The AI tools row grew fastest across 2025 and 2026. Eighteen months ago the same audit would have shown maybe 2 GB across ~/.claude/ and ~/.codex/. Now it is the third largest contributor on most dev Macs I look at.
What does each folder actually contain?
A line in a table is not enough to act on. Here is the one-paragraph version of each contributor, in size order, with the real path so you can verify it yourself.
CoreSimulator (around 35 GB)
~/Library/Developer/CoreSimulator/ holds runtime bundles for every iOS, watchOS, and tvOS version Xcode has ever downloaded, per-simulator-device data containers, and a Caches subfolder. Runtimes alone are 6 to 8 GB each, and Xcode keeps the old ones after upgrades. Deleting simulators you no longer test is reversible because Xcode redownloads runtimes on demand. The safe procedure is in reclaim disk from Xcode simulators.
Docker.raw (around 30 GB)
The Docker for Mac VM stores everything inside one file at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. It grows as you build images, pull layers, and run containers. It rarely shrinks on its own. One developer in a January 2026 writeup of using Claude to free 200 GB from a full disk found 108 GB sitting in Docker volumes alone. The pinned quote: "The volumes were almost entirely unused, probably from old postgres/redis containers I'd stopped months ago."
Xcode DerivedData (around 25 GB)
~/Library/Developer/Xcode/DerivedData/ is the per-project build cache. It rebuilds on next compile, which is why every Xcode cleanup script starts here. Full safety analysis in is deleting DerivedData safe.
AI tool sessions (around 25 GB)
~/.claude/, ~/.codex/, ~/.cursor/, and ~/.config/cline/ hold session history, project snapshots, MCP logs, debug traces, and in some cases file-history copies of every edit. Claude Code Issue 18869 is the famous case where a user found 472 GB of debug logs and MCP traces in their Claude folders. The mitigation is one line in ~/.claude/settings.json, and most users never know to add it.
LLM model weights (around 15 GB)
~/.ollama/models/ and ~/.cache/huggingface/hub/ hold model blobs you downloaded once for a side project and forgot about. A single 70B parameter model can be 40 GB on its own. Not junk, but not free, and most devs have at least one model they have not loaded in three months.
Time Machine local snapshots (around 20 GB)
Even with Time Machine off, macOS keeps recent local snapshots on the boot volume in case you turn it back on. They are invisible in Finder and counted under System Data. One command lists them, another removes them:
# list local Time Machine snapshots
tmutil listlocalsnapshots /
# delete a specific snapshot by date
sudo tmutil deletelocalsnapshots 2026-05-24-093021
# nuke every local snapshot at once
for snap in $(tmutil listlocalsnapshots / | awk -F. '{print $4}'); do
sudo tmutil deletelocalsnapshots "$snap"
done
The snapshots reappear on the next backup cycle, which is the entire point. Deleting them is reversible and instant.
Mail, Messages, and misc caches (around 30 GB combined)
The bottom four rows tend to sum to 30 GB on a Mac in active use for a year. Mail downloads attachments locally, iMessage keeps the full sync database, Spotlight rebuilds its index after macOS upgrades, and Application Support keeps folders from apps you uninstalled six months ago. None of these are individually large, but together they sit between you and a clean disk.
How do you find your own breakdown?
The fastest way to enumerate this on your own Mac without installing anything is to run du against the suspect folders one at a time. The block below runs in any zsh or bash shell and takes about two minutes on a typical machine.
# size the top 10 System Data contributors on a dev Mac
du -sh ~/Library/Developer/Xcode/DerivedData/ 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator/ 2>/dev/null
du -sh ~/.claude/ ~/.codex/ ~/.cursor/ 2>/dev/null
du -sh ~/.ollama/models/ 2>/dev/null
du -sh ~/.cache/huggingface/ 2>/dev/null
du -sh ~/Library/Containers/com.docker.docker/ 2>/dev/null
du -sh ~/Library/Mail/ 2>/dev/null
du -sh ~/Library/Logs/ 2>/dev/null
du -sh ~/Library/Application\ Support/ 2>/dev/null
# Time Machine snapshots (different command)
tmutil listlocalsnapshots / | wc -l
If the totals add up to within 20 percent of your Storage panel's System Data number, you have found the bar. If they do not, the missing GB is almost always Docker.raw, an Ollama model you forgot about, or an Application Support folder from an uninstalled tool. Add those to the list and rerun.
What the breakdown does not show
Two categories confuse first-time auditors. Purgeable space is disk macOS reserves as cache and releases under pressure. It shows up in System Data on some macOS versions and not others. A reboot clears a few GB but does not move the needle. The sealed system snapshot is the signed read-only system volume, around 12 GB, and you cannot delete it. Ignore both. Everything else in the 180 GB is in a folder you can name and reduce.
How do I act on this breakdown safely?
Three rules. First, never run sudo rm -rf against a folder you cannot explain. Move suspect folders to Trash, watch for a week, then empty. Second, audit before deleting. Last-modified date, file count, and size together tell you whether a folder is active or abandoned. A 12 GB Application Support/Code-Insiders untouched in 14 months is different from a 12 GB ~/.claude/ you used yesterday. Third, prefer reversible reductions first: DerivedData rebuilds, simulators redownload, Docker images rebuild, Time Machine snapshots come back. The irreversible deletions can wait until the gray bar has already moved. The framework for that audit lives in the System Data safe-reduction playbook.
Stop guessing what the bar contains
The reason this post exists is that Apple chose not to ship the breakdown. CleanMyDev does ship it. It enumerates the same paths in the table above, sizes each one, shows the contents and last-modified dates, and moves anything you select to Trash by default. Nine dollars and ninety-nine cents, one time, no subscription. If the gray bar is bothering you, grab CleanMyDev for $9.99 lifetime and stop guessing.