Why I built CleanMyDev: 168 GB of System Data wasn't macOS

I opened macOS Storage on a Saturday in November 2025. The gray bar said System Data: 168 GB. My 512 GB MacBook Pro had 31 GB free. I had not installed anything large that week. I had not downloaded any movies. I had not even cloned a big repo. I had spent the week doing what I always do, which is write Swift, run iOS builds, talk to Claude Code, run a few Ollama models on the side, and ship a TestFlight build on Friday.

168 GB of something macOS would not name. That is the moment CleanMyDev started.

What does 168 GB of System Data even mean?

System Data is the gray segment in System Settings, General, Storage. macOS calls it that because it is the residual after every other category is accounted for. It is not a folder. It is a subtraction. macOS counts Apps, Documents, Photos, Mail, Messages, iCloud Drive, and the OS itself, then dumps the rest into one bar.

For a normal user that bar is 15 to 30 GB. For me it was 168 GB.

I did the obvious thing. I clicked Manage. macOS offered to Store in iCloud, Optimize Storage, Empty Trash Automatically, and Reduce Clutter. None of those said anything about the 168 GB. Apple's own UI gives up after three suggestions. The actual contents of the gray bar are unaddressable from System Settings.

So I opened the Mac cleaner I already owned, CleanMyMac. It scanned. It found 4.2 GB of browser caches and 800 MB of Mail attachments. It congratulated me on a clean machine. The 168 GB remained.

Why didn't CleanMyMac find it?

CleanMyMac is good software. It is also software built for the median Mac user, which is not a developer. Its scan paths are tuned for Safari, Chrome, Mail, iPhoto, language packs, and uninstaller leftovers. Those are the right paths for an average Mac.

They are the wrong paths for my Mac.

That is not a bug in CleanMyMac. That is its scope. The product was designed in 2009 for a Mac that did not have Ollama, Claude Code, Codex, Cursor, Cline, Hugging Face, or Docker Desktop on it. It was designed for the Mac you used to write a thesis, not the Mac you use to ship apps.

The problem is that there are millions of us using the second kind of Mac and only the first kind of cleaner exists.

What did I actually find?

After three hours with DaisyDisk, du, a notebook, and a lot of Cmd-F in Finder, here is the breakdown I scribbled on the back of a Field Notes page:

# rough audit, MacBook Pro 14" M2 Pro 512GB, taken Nov 2025
du -sh ~/Library/Developer/Xcode/DerivedData      #  28 GB
du -sh ~/Library/Developer/CoreSimulator/Devices  #  19 GB
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport #  14 GB
du -sh ~/.ollama/models                            #  47 GB
du -sh ~/.cache/huggingface                        #  11 GB
du -sh ~/.claude                                   #  18 GB
du -sh ~/.codex                                    #   6 GB
du -sh ~/Library/Containers/com.docker.docker      #  21 GB
du -sh ~/.npm/_cacache                             #   3 GB

That is 167 GB before I even checked Cursor's .pack files or the JetBrains caches. The numbers lined up with the gray bar to within 1 GB. None of it was macOS.

Two paths surprised me. ~/.claude at 18 GB was almost entirely MCP debug logs from a project I had abandoned in June. ~/.ollama/models at 47 GB held seven models, three of which I had pulled "just to try" and never opened a second time. Together those two paths were 65 GB on a 512 GB drive that I had paid an Apple premium to keep small.

Why didn't I just write a shell script?

I did. The script lived in ~/bin/devclean.sh for about six weeks. It looked like every developer's personal cleanup script looks. It had a comment at the top that said "be careful" and a long list of rm -rf lines. It worked. It also scared me every time I ran it.

The problem with a shell script is that it cannot show you what it is about to do. You either trust the author of the script, which is yourself, at 2 AM, when you wrote the script, which is the worst possible person to trust at the worst possible time, or you read the script every single time before you run it, which means the script does not actually save you any time.

The other problem with a shell script is that rm -rf is permanent. Trash is not. If I run a cleaner and it accidentally nukes a folder I needed, I want a recoverable mistake, not a forensic data recovery job.

Jonathan Spooner wrote about this exact tension in his post Reclaim 100+ GB from Xcode: The Cleanup Script I Wish I'd Written Years Ago. His title is the joke. iOS pros eventually write the script. They wish they had written it sooner. They also, quietly, never share it, because sharing your personal rm -rf script is the software equivalent of handing someone your unloaded gun and saying "trust me."

So I rewrote the script as a native Mac app. That is CleanMyDev.

What does CleanMyDev actually do?

It does the same thing the script did, with three changes that matter.

First, it shows you every path it found, with size, last-used date, and a risk label, before it touches anything. You see the receipts before you sign.

Second, it moves files to Trash instead of rm -rf. If I made a mistake, you empty Trash and the mistake is permanent. If you made a mistake, you restore from Trash and you are fine.

Third, it scans 110+ developer-specific paths, not 8. That includes the AI coding tool cluster, the local LLM cluster, the iOS dev cluster, the JS and container cluster, and a handful of safety paths like "is this DerivedData folder for a project that is currently open in Xcode?" If the answer is yes, CleanMyDev flags it and refuses to act without an explicit override.

Why is it called CleanMyDev and not DevClean?

Honestly because the .com was available. I had been calling the prototype DevClean for three months, checked the domain, found it taken by a janitorial company, and switched. The new name is more honest. It says what the tool is for in one word.

If you want to read the deeper teardown of where the 168 GB went, see System Data on MacBook: a 180 GB breakdown. If you want the AI-tool-specific version of the story, see Cleaning Claude Code disk usage.

What does Ollama have to do with all this?

Ollama is the new node_modules.

I mean that literally. node_modules became the meme it is because every JavaScript project on your disk has its own copy of the same 200 MB of dependencies, and you forgot 47 of those projects exist. Ollama works the same way. Every model you ollama pull parks 4 to 40 GB on your disk. You pull llama3:70b once to see if it runs, decide it is too slow, and forget it. Six months later you have seven 40 GB models you never use.

Hugging Face is worse because there are three caches: ~/.cache/huggingface/hub, ~/.cache/huggingface/datasets, and ~/.cache/huggingface/transformers. They do not share storage. A model you downloaded for one library is invisible to the other two. You can easily have the same 14 GB model in two places without knowing it.

CleanMyDev scans all three. It also scans ~/.ollama/models and shows you the last time each model was loaded. If you have not touched gemma:7b since February, that is a signal, not a verdict. You decide.

What did real users do with it?

A user emailed me last week. He had been hit by Claude Code Issue #18869, the 472 GB debug log bug. His exact words were "My Apple M1 Max with a 1TB drive failed to update macOS last night due to low diskspace, which surprised me." He had used DaisyDisk to find the source. He had not used a cleaner. He bought CleanMyDev because, in his own words, "I want a tool I can run before this happens again, not after."

That is the audience. Not people who have never lost a disk to dev tooling. People who have, exactly once, and never want to do it again.

What is the closing CTA?

If you have ever opened macOS Storage and stared at a gray bar wondering what it is, CleanMyDev opens the bar for $9.99 once. No subscription. No telemetry. No upsell to a "pro" tier that adds the features the basic tier should have had. One purchase. Lifetime updates. Move-to-Trash by default. Receipts before deletion.

If you want to read the rest of the story, the breakdown posts below are the ones I would point a skeptical developer at before buying.

Related reading

• Claude Code ate 472 GB of my MacBook: a postmortem
• How AI coding tools quietly filled my disk in 16 months
• I freed 147 GB on my MacBook in 12 minutes with CleanMyDev