Why Cleanup Should Send Files to Trash — Not Delete Them Permanently

Here's a scenario that happens more than people like to admit.

You run a cleaner app. It does its thing. Files disappear, space is recovered, and the progress bar hits 100%. Feels good. You close it and get back to work.

Then something breaks. An app that was working fine now won't launch. A project file references something that's gone. A browser extension lost its settings. And because the cleanup app deleted permanently, there's nothing to recover. The files aren't sitting in Trash. They're just gone.

This is not a rare edge case. It happens because "clean up my Mac" and "this specific file is safe to delete" are two very different things.

The Problem With Silent, Permanent Deletion

Most cleanup apps work on a simple assumption: they know what's safe to remove, you don't need to see it, and permanent deletion is faster.

That assumption is wrong often enough to matter.

Cache files, for example, are usually rebuildable — but not always. Some apps write state into their cache that isn't stored anywhere else.^[1] App support files look like dead weight, but occasionally hold data the app actively uses. Log folders are almost always safe — except when they're not.

The problem isn't that cleaners remove the wrong things occasionally. The problem is that when they do, you have no fallback.

A permanent delete is permanent. There's no "undo" in Finder after the fact. No recovery. Just a support forum post and a hope that Time Machine had it.^[2]

Trash-First Is a Safety Net, Not a Slowdown

Sending files to Trash instead of deleting them outright sounds like a small thing. In practice it changes everything.

If cleanup ran yesterday and something broke today, you can open Trash, find what moved, and put it back. You figure out what actually caused the problem. You recover in five minutes instead of spending an afternoon troubleshooting.

That's the value. Not that Trash is some sophisticated feature — it's just that the window for recovery stays open.^[3]

Most people don't empty their Trash daily. That gap between "files moved" and "files gone" is where errors get caught. Trash-first cleanup respects that gap. Permanent deletion closes it immediately.

The Visibility Problem Is Even Bigger

Beyond the deletion method, there's a second issue: most cleaners don't show you what they're removing before they remove it.

You click "Clean" and something happens. Maybe a summary appears after. But by then it's done — files are already gone and the list is just a receipt, not a decision.

That's not how a trustworthy tool should work.

The right model is: here's what we found, here's how much space it takes, here's each category — now you decide. Not the other way around.

When "Junk" Isn't Actually Junk

This is where it gets more specific.

Some files look like cleanup targets but sit in a gray area. An old app support folder that might be needed if you reinstall. A cache file that's technically stale but regenerating it will be slow. Developer build artifacts that are safe to remove — unless you're mid-build and they're actively used.

DiskCleaner flags these. Instead of quietly lumping them into the removal list, items that look recoverable but carry more risk get a warning indicator. Not a blocker — you can still choose to remove them — but a signal that says: this one is worth a second look before you decide.

The Philosophy Behind It

We made two decisions early on when building DiskCleaner that shaped everything else.

First: cleanup should always go to Trash unless there's a specific reason not to. The speed difference is negligible. The safety difference is not.

Second: the user should approve what gets removed. Not after the fact. Before.

Those aren't complicated ideas. But a lot of cleanup apps make the opposite choices because it makes the experience feel faster and more magical. Click a button, number goes down, feels clean.

The problem is that "feels clean" and "is actually safe" aren't the same thing.

We'd rather the experience feel a little more manual and a lot more recoverable. That's the tradeoff we chose.