What is System Data on Mac, and why is it so huge?

A developer on an M1 Max with a 1 TB drive posted to GitHub in January: his Mac refused to install a macOS update because the disk was full. He wrote, "My Apple M1 Max with a 1TB drive failed to update macOS last night due to low diskspace, which surprised me." When he opened DaisyDisk he found 472 GB of Claude CLI debug logs. None of that 472 GB was visible in the macOS Storage panel as anything except a single gray bar labelled System Data.

That is the question this post answers. What is the gray bar? What does macOS actually count inside it? And why does it always seem to live somewhere between 80 GB and 200 GB on a developer Mac?

What is System Data on Mac, technically?

Open System Settings, General, Storage. macOS shows a stacked bar split into colored segments. The named segments are the categories macOS knows how to label: Apps, Documents, Photos, Mail, Music, Messages, Podcasts, iCloud Drive, TV, and on newer Macs, macOS itself. Everything else lands in System Data.

System Data is not one folder. It is a calculation. macOS asks the file system how big the volume is, subtracts the sum of the named categories and free space, and writes the remainder into the gray bar. That remainder is whatever the operating system could not classify.

For a non-developer Mac, System Data is usually 10 to 30 GB. It holds the OS recovery partition, Time Machine local snapshots, the Photos library cache, the Mail database, and a few system caches.

For a developer Mac, the same bar is regularly 80 to 200 GB. The remainder math has not changed. What changed is everything you installed.

Is System Data the same thing as Other Storage on Mac?

This question shows up in nearly every old guide. The short answer is no, but the categories overlap.

Most pre-2023 cleanup guides talk about "Other Storage" and tell you to run a built-in macOS purge. The bucket name changed. The advice did not get updated. If a guide tells you to right-click your hard drive in Finder to see the Other breakdown, it is from 2018 and was already wrong by 2022.

Why is System Data so large on a developer MacBook?

Because developer tools produce more file system clutter than any other category of software on macOS, and almost none of them clean up after themselves.

Here is the rough breakdown on a typical iOS-plus-web-plus-AI developer machine that is 12 to 24 months old:

Add those up on a busy machine and you are already past 150 GB. None of it shows in the Storage panel by name. All of it counts as System Data.

The AI coding tool category is the newest addition and the fastest-growing one. As one developer documented after auditing his own disk, "After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB." (See Using Claude to free 200GB from a full disk.)

How do I see what is actually inside System Data?

The honest answer: macOS will not tell you. You have to inspect the paths directly. Here is the manual route, run from Terminal:

# Top-level developer suspects
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Developer/Xcode/Archives 2>/dev/null
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator 2>/dev/null
du -sh ~/Library/Developer/XCTestDevices 2>/dev/null

# AI coding tools
du -sh ~/.claude ~/.codex ~/.cursor ~/.cline ~/.factory 2>/dev/null
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null
du -sh ~/Library/Application\ Support/Cursor 2>/dev/null

# Local models
du -sh ~/.ollama 2>/dev/null
du -sh ~/.cache/huggingface 2>/dev/null
du -sh ~/Library/Application\ Support/LM\ Studio 2>/dev/null

# Containers and language ecosystems
du -sh ~/Library/Containers/com.docker.docker 2>/dev/null
du -sh ~/.npm ~/.bun ~/Library/pnpm 2>/dev/null
du -sh ~/Library/Caches/ms-playwright 2>/dev/null

That will list sizes for the known suspects. It does not tell you which sub-paths inside each are safe to delete, which simulator runtime is still in use, or which Ollama models you actually load.

sudo du -sh /System/Volumes/Data/.* 2>/dev/null adds the hidden dotfolders. mdfind -onlyin ~ "kMDItemContentType == 'public.archive'" finds zip archives macOS tucked away. Running find ~ -name node_modules -type d -prune -print 2>/dev/null | xargs -I{} du -sh "{}" 2>/dev/null enumerates every node_modules your filesystem still holds.

This is roughly an hour of work, repeated whenever System Data grows back. Most developers do it once per disk-full panic and never again.

What is the difference between System Data and macOS storage?

On macOS Ventura and later, the Storage panel separates macOS (the operating system files in /System) from System Data (everything else not in a named category). On older versions they were combined.

/System is read-only on modern macOS and is sized in the 10 to 15 GB range. You cannot meaningfully shrink it without breaking the OS. System Data, by contrast, is almost entirely under ~/Library and other writable user paths. That is where the reclaim opportunity lives.

This is also why guides that say "delete System Data to free disk" without qualifying which paths are dangerous. There is no single "System Data folder" to delete. There are 100-plus folders feeding into the same bar.

What is the safest way to reduce System Data on macOS?

Three rules that hold up across every cleanup scenario:

1. Inspect before deletion. Get the size, the last-modified date, and the purpose of every path before anything moves to Trash. Half the perceived bloat is files you still need.
2. Move to Trash, not rm -rf. A move is reversible until Trash is emptied. rm -rf is not. The five-second Trash recovery has saved more development hours than any keyboard shortcut.
3. Never delete blanket categories. "Delete all caches" is the worst advice in this whole space. Xcode's preview cache rebuilds in minutes. Your Ollama 70B model weights take hours to redownload and may cost bandwidth.

CleanMyDev's whole model is built on these three rules. Every path is sized, dated, and risk-labelled. Move-to-Trash is the default action. The dangerous categories show a warning before they can be selected. See pricing on the home page.

Why doesn't Apple show what is in System Data?

Two reasons.

First, the paths are scattered. There is no single registry of "things that count as System Data." macOS computes the bar as a remainder, not as a sum of known contents. Asking Apple to break it down would require them to maintain a catalogue of every third-party app's cache location.

Second, the contents are unsafe to expose to a general audience. Apple's storage UI is shipped to retirees clearing photo libraries and to engineers debugging Claude. Showing /Users/you/Library/Developer/CoreSimulator/Devices/A3B7C9D5-XXXX/data/Library/Caches/ in the Finance app's user interface would terrify the first group and underserve the second. So Apple shows neither group anything.

Third-party tools fill the gap. The good ones earn trust by showing receipts. The bad ones bury the same information behind a "click here to clean" button and remove things you needed.

Get the breakdown without the terminal session

CleanMyDev was built for exactly this problem: a developer Mac where the System Data bar is opaque, the contents matter, and the wrong delete loses real work. It scans 110-plus developer-specific paths, sizes them in parallel, labels the safety risk for each, and waits for your approval before anything moves to Trash. Lifetime license, no subscription, no telemetry.

Get CleanMyDev for $9.99 on the pricing page.

Related reading

• System Data vs Other Storage on Mac: what changed
• Reduce System Data on macOS safely
• System Data 180GB autopsy on a working developer Mac