"I used DaisyDisk to dig into the issue and discovered folders taking up 472GB, both related to Claude CLI." That sentence comes from an Apple M1 Max user whose machine had refused to install a macOS point release because the free disk number had dropped below 5 GB. He had not been careless. He had been using a CLI heavily for four or five months, and nothing on his system flagged that the bytes those tools were writing under ~/.claude and ~/Library/Caches/claude-cli-nodejs/ had crossed half his SSD. The full thread is captured in anthropics/claude-code Issue #18869. The painful part is not the number. The painful part is that the number existed for months with no label, no warning, and no audit trail. A Mac cleaner that just deletes for you would have removed those folders. A Mac cleaner that shows receipts would have let him see them first.
What does it actually mean to "show receipts" in a Mac cleaner?
A receipt is the paper trail a developer would build by hand before deleting anything sensitive. For CleanMyDev that means five fields per row. The first is the absolute path, expanded, so you can paste it into a terminal and confirm. The second is the size, computed live, not from a stale spotlight index. The third is the last-modified timestamp on the deepest file inside the folder, which tells you whether the bytes are current state or an artefact left over from a project you wrapped six months ago. The fourth is the owning tool, named (Xcode, Claude Code, Ollama, Docker, Cursor), because a folder called ~/.cache/huggingface/hub does not announce itself. The fifth is a risk label: rebuilds-on-next-run, redownload-required, state-bearing, or unknown. That last category exists because honesty matters more than coverage on a developer Mac.
Why does a developer Mac need receipts more than a consumer Mac?
Because most of the heavy folders on a developer Mac are not garbage. They are expensive-to-recreate state hiding inside opaque paths. A consumer Mac cleaner can be confident that ~/Library/Caches/com.spotify.client is safe to nuke. A developer Mac cleaner that treats ~/.ollama/models the same way will cost you a forty-minute redownload of a quantised 70B GGUF. A blog post that captures this distinction well comes from a Mac developer who freed 200 GB by hand: "Docker was the biggest culprit. The volumes were almost entirely unused, probably from old postgres/redis containers I'd stopped months ago." (Source: brtkwr.com, Using Claude to free 200GB.) Docker volumes were correctly deletable for him because he could see the names and dates. Without that receipt the same volumes would have looked exactly like state worth keeping.
The same logic applies further up the stack. DerivedData rebuilds in three minutes. The Hugging Face hub cache rebuilds in four hours over a hotel Wi-Fi. A review-first Mac cleaner is the difference between knowing which one you are about to delete.
What does a CleanMyDev receipt look like in practice?
The on-screen row is denser than a Finder window and lighter than a Terminal du. Here is what the same audit looks like when you build the receipt by hand first, so you can see what the app is condensing.
# A manual receipt for a developer Mac, by category.
# Run as your normal user, no sudo. CleanMyDev does this same pass in one scan.
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Developer/Xcode/Archives 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator/Devices 2>/dev/null
du -sh ~/.claude 2>/dev/null
du -sh ~/.claude/projects/* 2>/dev/null | sort -h | tail -5
du -sh ~/Library/Caches/claude-cli-nodejs 2>/dev/null
du -sh ~/.codex 2>/dev/null
du -sh ~/.ollama/models 2>/dev/null
du -sh ~/.cache/huggingface/{hub,datasets,transformers} 2>/dev/null
du -sh ~/Library/Containers/com.docker.docker/Data/vms/0 2>/dev/null
du -sh ~/.npm/_cacache ~/.pnpm-store ~/.bun/install/cache 2>/dev/null
Each line above is one row on the CleanMyDev review screen, but with the size pre-sorted, the risk label rendered in colour, and the project hashes resolved to human names. The audit takes seven minutes by hand on a full developer drive. The app does it in seven seconds, and the receipt is the entire UI.
How does a review-first Mac cleaner compare to a one-button cleaner?
Both approaches free disk. They differ on what they assume about you.
| Property | One-button cleaner | Review-first Mac cleaner (CleanMyDev) |
|---|---|---|
| Default action on scan complete | Auto-selects everything, prompts to delete | Selects nothing, renders the receipt |
| Per-row metadata | Category and size | Path, size, last-modified, owning tool, risk label |
| Granularity | Preset bundle, all or none | Per row, per subpath, per project hash |
| Treatment of expensive state | Often deleted (Ollama, HF cache, archives) | Marked redownload-required, opt-in only |
| Deletion mechanism | rm -rf or unlink |
mv to user Trash, seven-day window |
| Privilege required | Frequently asks for admin | Never asks for admin |
| Failure mode if scan misclassifies | Data loss, redownload, lost archive | A box is ticked you would not have ticked |
The one-button cleaner is faster on a healthy Mac. The review-first Mac cleaner is faster on a Mac that holds real work, because you are not spending an evening rebuilding a model store you did not mean to delete. The deeper safety argument lives in the CleanMyDev Mac cleaner safety guide and the Move to Trash vs rm -rf breakdown.
Why does showing receipts double as a scareware filter?
Receipts and scareware are mutually exclusive. Scareware Mac cleaners depend on the user not seeing what is about to be deleted; the whole pitch is "trust me, your Mac is full of dangerous junk, click here." A review-first Mac cleaner cannot run that pitch because the receipt has to list real paths with real sizes. If the receipt is empty, the scan is honest about there being nothing to clean. If the receipt is exaggerated, you can verify the numbers in Terminal in thirty seconds. CleanMyDev's UI is therefore a structural defence against the same marketing tactics the App Store has cycled through for a decade. The longer breakdown of the tactics lives in the upcoming Mac cleaner scareware warning post.
Does showing receipts slow CleanMyDev down?
A scan of a full developer Mac, with Xcode, Claude Code, Codex, Cursor, Ollama, Hugging Face, Docker, npm, and pnpm caches all present, finishes in under ten seconds on Apple Silicon. The receipt is the page that appears after the scan. The added cost is reading time, not compute. Two minutes of skim, ten seconds of ticking, and the deletion runs in the time it takes Finder to move folders to Trash. Compared to the alternative (which is the four-hour cycle of "DaisyDisk, then guess, then Google, then second-guess, then delete, then break a build") it is the fastest safe option.
Where does the receipt model end, honestly?
Two places. First, a receipt cannot tell you what an opaque folder under ~/Library/Application Support belonged to once the original app is uninstalled. CleanMyDev flags those with the unknown label and leaves them alone by default. Second, a receipt cannot stop you ticking the wrong row. The seven-day Trash window is there for that mistake. Empty the Trash on the eighth day, not the same hour. Those are the limits and they are written into the docs, not buried in a marketing footnote.
A CTA, since you read this far
If the line between "trust me" and "show me" matters to you, the app is CleanMyDev, $9.99 lifetime, no subscription. One-time purchase, Move to Trash by default, the receipt screen is the home screen. It is the smallest review-first Mac cleaner I could build and still cover the developer paths that actually matter.