Are Mac cleaners safe in 2026? A developer's safety guide

A developer on an Apple M1 Max with a 1 TB drive opened the GitHub issue tracker for Claude Code on January 17, 2026, and posted this: "I used DaisyDisk to dig into the issue and discovered folders taking up 472GB, both related to Claude CLI." macOS could not even install the next system update because the disk was at 5 GB free. The fix did not require a Mac cleaner. It required a Mac auditor. There is a difference, and the difference is the entire point of this safety guide.

Why does "is this Mac cleaner safe" keep getting asked?

The Mac cleaner category has a trust problem older than the App Store. Consumer cleaners in the late 2000s shipped fake virus scans and red countdown timers, and a generation of users learned to associate the word "cleaner" with shareware that wanted their credit card before it would explain itself. Developers in particular distrust it for a reason: when your machine ships code to production and signs binaries with your name, anything that touches your disk is in your threat model.

The honest 2026 picture is more nuanced. Some Mac cleaners are genuinely well built. Some are still scareware. A Mac cleaner safety guide written for developers is really a checklist of what to look for before you let a binary touch ~/Library/.

What does "safe" actually mean for a developer Mac cleaner?

Safe is not a single property. For a working dev Mac it splits into four checks, and a cleaner has to pass all four before the answer is yes.

1. Bounded scope. It only reads and writes paths it has documented, all inside your user account. No /System/, no /Library/, no ~/Library/Containers/<bundle-id>/Data/ belonging to apps it does not know about.
2. Visible before destructive. Every file it intends to remove is listed with path, size, and last-modified date before any deletion runs.
3. Reversible by default. Move to Trash is the primary action. rm -rf is opt-in, never the default, and never silent.
4. Honest permissions. It asks for the minimum macOS permission required to scan the paths it lists, and explains why on the prompt.

Apply those four to whatever cleaner you are evaluating. If even one fails, the answer to "is this Mac cleaner safe" is "not safe enough for a developer Mac."

How do I read a Mac cleaner's permission prompts?

This is the single fastest way to triage trust. macOS surfaces permission requests through TCC, the Transparency, Consent and Control system, and the prompts you see on first launch tell you what the app is about to reach for. A safe Mac cleaner asks for very little. A reckless one asks for everything up front.

Run this quick check before any cleaner gets to its main window:

# See if the app is signed and notarized by an identifiable developer
codesign -dv --verbose=4 /Applications/SomeCleaner.app 2>&1 | grep -E "Authority|TeamIdentifier"

# Check for notarization ticket
spctl -a -vv /Applications/SomeCleaner.app

If codesign cannot find an authority, the binary is unsigned and you should not have downloaded it. If spctl says the app is not notarized, Apple has not even done its baseline malware check on it. Both are immediate disqualifiers for a developer Mac cleaner safety guide.

Which permissions should a Mac cleaner actually need?

There is a small, defensible list. Anything beyond it deserves a second look.

Compare that to what a typical "free" Mac cleaner asks for on install: Full Disk Access, Accessibility, an admin password, plus a network call to register the device. Each one is a footgun. A Mac cleaner safety guide that takes itself seriously has to flag every grab that is not justified by a feature you actually use.

What do the worst Mac cleaners do that you should learn to spot?

Scareware Mac cleaners share a small set of tells. Once you see them once, you cannot unsee them.

• A first-launch "scan" that finishes in 2 seconds with "47 GB of junk found" and a giant red number.
• The file list is collapsed by default, or rendered as a single "junk" category with no paths.
• A delete button labeled "Smart clean" or "AI clean" that does not show what it is about to remove.
• A subscription prompt before any work happens, with the price hidden behind a "Continue" button.
• A pop-up that says your Mac is "at risk" without naming a specific file or path.

If you see two of those in the first 60 seconds, quit the installer and check for launchd helpers it may have dropped:

ls -la ~/Library/LaunchAgents/ /Library/LaunchAgents/ /Library/LaunchDaemons/ 2>/dev/null \
  | grep -iE "clean|optimize|protect"

A safe Mac cleaner makes uninstall trivial. If you have to grep launchd to undo an install, the cleaner already failed the safety guide.

Move to Trash vs rm -rf: which is safer for a Mac cleaner to use?

rm -rf is faster. Move to Trash is reversible. For a Mac cleaner running on a developer machine, reversibility is the only safety property that matters, because the cost of a wrong delete is rebuilding state you did not realize was state.

DerivedData is reproducible. A 70 GB Ollama model is not, at least not without redownloading on a coffee shop Wi-Fi. An old ~/.claude/projects/ folder may contain conversations you have not exported. A safe Mac cleaner treats every category as "might matter" and lets you drag it back out of Trash. There is a fuller comparison in the Move to Trash vs rm -rf post. CleanMyDev uses the standard NSWorkspace recycle API by default for every category, so the path lands in ~/.Trash/ and macOS keeps it for 30 days.

Does a Mac cleaner need Full Disk Access?

This is the most misunderstood permission in the category. Full Disk Access lets an app read folders other apps own, including ~/Library/Mail/, ~/Library/Messages/, and the protected parts of ~/Library/Containers/. For most developer cleanup targets you do not need it. DerivedData, the Xcode caches, the npm cache, ~/.claude/, ~/.codex/, ~/.cache/huggingface/, and the Ollama models folder are all readable without Full Disk Access. CleanMyDev runs its default scan without the permission, and only asks if you explicitly enable the sandboxed app pass.

How does a safe Mac cleaner compare across the ones you have heard of?

This is the part most cleaner safety posts duck, because it gets personal. Here is the honest table for a developer Mac in 2026, scored on the four safety properties above.

The skeptical-dev takeaway: there are at least four cleaners that meet the safety bar today, and there are many that do not. The marketing pages do not tell you which is which. The first-launch behavior does. There is more on the specific scareware pattern in the dedicated Mac cleaner scareware warning post, and a deeper look at the safety choices for one specific path in the is it safe to delete DerivedData guide.

What does CleanMyDev do differently inside this safety guide?

CleanMyDev was built because the existing safe options were still aimed at consumers, and a consumer cleaner does not understand that ~/Library/Developer/Xcode/DerivedData/ is reproducible while ~/.claude/projects/ is not. The safety model has four ingredients: every category ships with the exact paths in the UI, every entry shows size and last-modified date, Move to Trash is the default on every category, and the default scan needs no sudo and no Full Disk Access.

That is the bar for "safe" on a developer Mac. If you have been putting off cleanup because every cleaner felt like a leap of faith, CleanMyDev for $9.99 lifetime shows the receipts first, asks for the minimum permissions, and leaves a Trash trail you can walk back. No subscription, no scareware, no surprises.

Related reading

• Mac cleaner scareware warning: the pattern to spot in 60 seconds
• The CleanMyDev safety model, explained
• Review-first cleanup philosophy: receipts before deletion