What does audit before delete mean for a Mac cleaner?

Audit before delete means a Mac cleaner shows you the full path, size, last-modified date, and owning tool for every candidate file before any deletion runs. You tick the rows you want gone. Nothing is removed until you confirm. It is the opposite of a one-click cleanup that hides the file list behind a scary banner.

Why is audit before delete important for developers?

Because dev caches look like junk and are not. DerivedData rebuilds in minutes, but a 42 GB Ollama model is an hour-long redownload, a `node_modules` tree may include a patched dependency, and `~/.claude/projects/` holds conversation memory you might want next week. Audit before delete forces the cleaner to tell you which is which before it touches your disk.

Is audit before delete the same as a dry-run mode?

Close, but not identical. A dry run shows what would be deleted if you confirmed. Audit before delete is the default behaviour, not a flag you have to remember to set. The audit is the workflow, and deletion is the optional second step you opt into per row.

Can I run audit before delete from Terminal without a GUI tool?

Yes. `du -sh` and `find` produce most of the receipts you need: path, size, optional last-modified date. The audit-before-delete pattern still applies. You read the list, decide what stays, then `mv` the rest to Trash. The shell version just takes longer and skips the per-tool risk labels a developer cleaner produces.

What is the difference between audit before delete and review-first cleanup?

They are two names for the same idea. Review-first cleanup is the philosophy. Audit before delete is the concrete safety rule the philosophy bakes into the UI. CleanMyDev uses both terms in the docs because different developers find one phrase clearer than the other.

Does audit before delete slow down a Mac cleanup?

By a few seconds per category, not by minutes. The audit phase reads sizes and metadata, which is fast on APFS. The slow part of a Mac cleanup has never been the audit, it has always been the deletion of millions of small files in a `node_modules` or DerivedData tree. Audit before delete adds a safety floor without changing the runtime profile.

What does audit before delete mean for a developer Mac cleaner?

A developer on an Apple M1 Max with a 1 TB drive wrote in Claude Code Issue #18869: "My Apple M1 Max with a 1TB drive failed to update macOS last night due to low diskspace, which surprised me." DaisyDisk later showed 472 GB tied up in two folders, both owned by Claude CLI. That story keeps showing up in the issue tracker because the fix is small and the consequences of getting it wrong are large. The right answer is not a faster cleaner. The right answer is a cleaner that shows the receipts before it touches anything.

TL;DR

Audit before delete is the safety rule a developer Mac cleaner has to follow to be trusted on a working machine. It means the tool produces a per-row list of path, size, last-modified date, owning tool, and risk label before any deletion runs, and routes deletions through the Finder Trash so the rollback window stays open. CleanMyDev was built on this rule from day one, which is why every category in the app starts as an audit and never as a one-click sweep.

What does audit before delete actually mean?

Audit before delete is a workflow constraint. The cleaner does two things, in order, and never reverses them.

Audit. Read the candidate paths, gather metadata, and present a list. The list is the contract: every byte the tool intends to remove is named on screen with size and last-modified date.
Delete. Only after the human ticks the rows they want gone, and only via Move to Trash by default. The Trash is the rollback window.

The order matters because the first phase has no destructive side effects. You can run an audit on a fresh dev Mac, on a CI runner, or on a colleague's machine you are debugging, and the worst that happens is you saw a list of files. The second phase is opt-in, per row, and reversible from Finder for the next seven days.

The pattern is older than Mac cleaners. It is how git status works before git rm, how terraform plan works before terraform apply, and how every backup tool worth using shows you what changed before it overwrites the destination. Mac cleaners that skip the audit step are the outliers, not the audit-first ones.

Why is audit before delete the right default for a developer Mac?

Because dev caches do not partition cleanly into "junk" and "important." The same folder can hold a 200 MB build artifact that rebuilds in a minute and a 4 GB language model that took an hour to download. Treating both as junk on a single click is how a fast cleanup turns into a slow Tuesday.

The single sharpest line on this comes from a developer who freed 200 GB on a full drive: "When you stop using an editor, uninstall it properly or manually delete its Application Support directory." That sentence is the audit-before-delete principle in one breath. You only know which Application Support directories belong to dead editors after you read the list. No cleaner can tell you that for sure without your eyes on the rows.

The four working categories on a dev Mac map to four different risk profiles:

Category	Example path	Rebuild cost	Audit value
Build artifacts	`~/Library/Developer/Xcode/DerivedData/`	Minutes to recompile	Low. Almost always safe to delete.
Tool caches	`~/.npm/_cacache`, `~/Library/Caches/pip/`	Seconds on a re-fetch	Low. Safe but cheap.
Diagnostic logs	`~/.claude/debug/`, `~/Library/Caches/claude-cli-nodejs/`	Zero, just stops a tail	Medium. Usually safe but you want to check before mass delete.
State-bearing assets	`~/.lmstudio/models/`, `~/.ollama/models/`, `~/.claude/projects/`	An hour or more to redownload, or unrecoverable	High. Never delete without reading the row.

A one-click cleaner that flattens all four categories into a single "Junk" total is wrong about category four every time. Audit before delete is the floor that prevents that mistake.

What does an audit row actually need to show?

The receipt should be readable in five seconds. That means five fields, no more, no fewer.

# What a Terminal audit looks like for one category.
du -sh ~/.claude/* 2>/dev/null | sort -h
find ~/.claude -maxdepth 1 -type d \
  -exec stat -f "%Sm %z %N" -t "%Y-%m-%d" {} \; 2>/dev/null \
  | sort

The five fields a developer cleaner has to surface for each row:

Path. Full, unabbreviated. ~/.claude/debug not "Claude logs". The path is the proof.
Size. Human-readable. 42.7 GB beats 42712984576 bytes for triage speed.
Last-modified date. A file you touched yesterday is different from one you have not touched since 2024.
Owning tool. Claude Code, Xcode, Cursor, Ollama. So you can decide based on context.
Risk label. Cache, log, state, model. So you know what is reversible.

The Terminal version skips the risk label because the shell does not know which tool owns the folder. That is the one piece a developer cleaner adds on top of du -sh. The other four come for free from the filesystem.

How does CleanMyDev implement audit before delete?

The app opens on the audit screen for every category. There is no homepage cleanup button. There is no estimate banner. The first thing you see is a per-folder list with the five fields above, sorted by size, with a checkbox next to each row. Nothing is preselected. Nothing is hidden behind an "Advanced" tab.

When you tick rows and confirm, every selected path is moved to ~/.Trash/ with a date-tagged name. The Trash is the seven-day rollback window. macOS auto-empties the Trash on day thirty by default, and CleanMyDev never forces that timer. The deletion is reversible from the Finder the same way every other file in your Trash is reversible.

The audit also reads ~/.claude/settings.json, .dockerignore, and a small allowlist of tool config files to attach the owning tool label correctly. That mapping is what turns a generic du -sh into a developer cleaner. Without it, every path is just bytes.

What goes wrong without audit before delete?

Three failure modes show up in the issue trackers and forums often enough to name.

Deleted a state-bearing asset. Someone clicks a cleaner's recommended action and loses 42 GB of Ollama models, then realises tomorrow's local-LLM benchmark just turned into a redownload. The cleaner did not show "state-bearing" anywhere on the row.
Broke the build on a CI parity check. A blind sweep removed ~/Library/Developer/Xcode/UserData/IDEPreferences/ along with DerivedData. The next archive needed two hours of re-signing setup. The cleaner did not surface that the path was config, not cache.
Deleted the auth token. Claude Code Issue #24207 records the cascade where ~/.claude was wiped at 0 bytes free, taking auth and settings with it. The audit version of that fix touches only ~/.claude/debug and ~/Library/Caches/claude-cli-nodejs/, and leaves ~/.claude/auth.json alone. The audit is what makes the difference.

In each case the destructive step was small and fast, and the recovery was slow. The audit step would have caught the wrong row before the click landed.

When does audit before delete fail you?

It is not magic. Three situations where the rule alone is not enough:

You read the audit and clicked anyway. The cleaner did its job. The mistake is yours and the Trash is your friend. Move it back inside seven days.
The cleaner audited the wrong path. A bug or a stale path map can list the wrong folder under the wrong tool label. The fix is a current path map, not abandoning the audit pattern. CleanMyDev publishes its path map in the docs so you can verify.
The disk is at 0 bytes free. When macOS cannot write to Trash because there is no space, you have to rm -rf something quickly. That is the legitimate emergency case for skipping the audit. Plan it for an obviously safe path like ~/Library/Caches/claude-cli-nodejs/--mcp-logs-* and recover the breathing room. Then run the proper audit on everything else.

The first case is the most common, and the seven-day Trash window absorbs it almost every time.

Where does this fit with everything else CleanMyDev does?

Audit before delete is the safety floor. Move to Trash is the safety net. Per-category coverage across Xcode, Claude, Cursor, Codex, Ollama, Docker, and the JS toolchain is the scope. Those three properties together are the product. None of them works on its own.

If you have been burned by a cleaner that swept first and asked questions later, the audit-first model is what fixes the trust problem. The whole point of /#pricing being a one-time $9.99 and not a subscription is that there is no reason to manufacture urgency. The cleaner runs when you open it, audits what is on your disk, and shows you the receipts. You decide.