Is Mole Safe: What It Deletes and What It Refuses to Touch

Mole ships as two programs, and most safety answers you will find online describe only one of them. Mole for Mac is the native app sold from mole.fit. mo is the free open source command line tool on GitHub. They share a protection list and a log, but they do not behave the same way at the moment of deletion, and that difference is the whole answer to whether Mole is safe for the way you plan to use it.

The short version: the Mac app shows you the full candidate list first and moves ordinary removals to the Trash, so a mistake is reversible. The CLI removes cache files permanently and gives you --dry-run instead of an undo. Both refuse a fixed set of paths no matter what asks for them.

Where deleted files go

In the Mac app, ordinary removals go to the Trash. That covers cache cleanup, app uninstalls, and the leftovers found alongside them, including the removals that need administrator rights and run through Mole's helper. They sit in the Trash under their original names until you empty it, and putting one back is a normal Finder restore.

Two things do not go to the Trash, and both are deliberate. Optimize deletes a small, named set of system-managed files directly: saved application state, the quarantine event database, stale write-ahead journals, broken LaunchAgent property lists, and empty .sfl files. Each one is gated by its own predicate on age, size, or existence, and each is a file macOS regenerates on its own. The other exception is the CLI, where mo clean and mo purge delete permanently by design.

That design choice is why the terminal tool ships --dry-run on every destructive command. In the CLI, the dry run is the undo. In the app, the Trash is.

What Mole refuses to delete

A cleaner is only as trustworthy as the things it will not do, so the refusal list is specific rather than a promise to be careful. These paths are blocked before any deletion runs, and a request that reaches one is refused rather than trimmed:

• System roots. /System, /usr, /bin, /sbin, and /private/var/folders.
• Audio plug-ins. /Library/Audio/Plug-Ins/Components, VST, and VST3, plus the iZotope and LaserSoft support directories. These look like inert application support and are load-bearing for anyone who opens a project that references them.
• Downloaded model weights. ~/.ollama/models, ~/.lmstudio/models, ~/.cache/huggingface, ~/.cache/torch, ~/.cache/whisper, ~/.cache/tensorflow, and ~/.cache/wandb. They live under cache-shaped paths but they are downloads, and some of them are tens of gigabytes over a slow link.
• Live Python environments. ~/.cache/pypoetry/virtualenvs stays, while Poetry's rebuildable artifacts and cache children remain cleanable.
• The Apple Neural Engine compiled-model store. Removing it while a consumer app is running breaks recognition until the next reboot.
• Protected system state. System Settings and Control Center configuration, audio services, the privacy database, login items and background task registrations, and the shared file lists behind recent-items menus.
• Mole's own configuration. ~/.config/mole, so a cleanup cannot erase the whitelist that constrains the next one.

Whitelisting is the user-controlled half of the same idea. A path you protect in either program is honored by both, because both read ~/.config/mole/whitelist.

The review step

Scanning is free in the Mac app, without a license and without a time limit. Every tool will scan and show you its full result list; a license is only required to act on it, and each destructive tool runs twice before asking. You can therefore compare what Mole proposes against what you believe about your own disk before paying anything.

Uninstall shows a plan with paths, owners, and sizes before anything moves. Every path is validated again at the moment of deletion rather than at scan time, so a file that changed identity between the scan and your approval does not ride through on a stale decision.

The Mac app is also deliberately narrower than the CLI, in a consistent direction. The clearest case is dependency directories: mo purge will remove node_modules, Pods, venv, and vendor, while the app drops all of them and offers only what a local compile can rebuild without the network. Seeing a category in the terminal that the app never offers is expected, not a missing feature.

What is genuinely not recoverable

Being specific about this matters more than reassurance.

Cache cleanup is meant to be permanent. Even in the app, where files land in the Trash, the point of the operation is that the application regenerates what it needs; emptying the Trash afterwards is a normal part of finishing the job, and after that the files are gone. The CLI skips that intermediate step entirely.

mo purge deletes build output permanently, which is why it is the command that most deserves a dry run first. The Optimize deletions listed above are also immediate. None of these are recoverable without a backup, and Time Machine remains the only general answer to "I deleted the wrong thing".

How to verify any of this yourself

Both programs append every deletion to ~/Library/Logs/mole/operations.log, with paths. That file is the record of what actually happened, and it is written by whichever front end did the work.

The CLI is open source under GPL-3.0, so its deletion logic can be read directly. The Mac app is signed with a Developer ID and notarized by Apple, which is what lets macOS verify the build you downloaded is the one that was published. Neither program sends telemetry.

Claims you may read elsewhere

Three descriptions circulate widely enough to be worth correcting, and all three come from reading the terminal tool and the app as one product.

"It is a terminal utility with no preview and no undo." That describes mo clean. The Mac app is a graphical, review-first tool whose ordinary removals land in the Trash.

"Mole is free." The CLI is free and open source. Mole for Mac is a one-time $19 purchase covering two Macs, with lifetime updates and a 14-day refund.

"The CLI is MIT licensed." It is GPL-3.0.

FAQ

Does Mole move deleted files to the Trash?

In the Mac app, ordinary cache cleanup and app removals go to the Trash, including removals that require administrator rights. The exceptions are a small set of system-managed files that Optimize deletes directly and that macOS regenerates. The free command line tool deletes permanently and offers --dry-run instead.

Can Mole delete something macOS needs?

System roots, protected system state such as privacy and login item databases, audio plug-ins, downloaded model weights, and live Python environments are refused before any deletion runs. The app also re-validates each path at the moment of deletion rather than trusting the scan.

Is the free CLI the same program as the Mac app?

No. They are separate implementations that share a cleanup vocabulary, a whitelist file, and a log. The app is a Swift reimplementation, not a wrapper around the CLI, and it is deliberately narrower about what it will remove.

Does Mole need Full Disk Access, and why?

App-data scans are gated behind it. Without the permission Mole still runs; it sees less and says so rather than reporting a smaller number as if it were the whole picture.

How do I see what Mole deleted?

Read ~/Library/Logs/mole/operations.log. Both programs write to it, so the file covers whichever one you used.