Should I vibe code
Surface large files, caches, login items, and safe cleanup suggestions without deleting automatically
Deleting a file is one line. Knowing which files are safe to delete is the entire product.
?
Their verdict, the Plan for 1 Mac price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Walking the filesystem and ranking directories by size really is one sitting, and a read-only version of this is among the more genuinely useful things on the list — you will find the 40GB of stale Docker images inside five minutes. What no agent can produce is the thing MacPaw actually sells: a curated, continuously re-verified map of which of the ten thousand items under ~/Library are disposable caches, which are the only copy of something, and which are load-bearing for an app that will simply refuse to open without them. Build the analyser and keep it. The delete button is where the weekend project stops being one.
What actually breaks
not "if". the specific failures.
- A path assembled by string concatenation meeting a folder name with a space, a quote, a newline or a `~` that never expanded — and the shell doing precisely what it was told
- Directories named like caches that are not caches, because Photos, Mail, Messages and the iCloud sync stores all keep primary data under names that read as disposable
- An app's support directory taken wholesale, along with its licence key, its local database and the drafts it had not synced
- macOS moving things every September, so a rule that was correct on one release removes something load-bearing on the next
- Symlinks and hardlinks, where following one quietly turns "clean this cache folder" into "clean the thing it pointed at"
- Full Disk Access, which the tool needs to be useful and which makes a script you wrote on a Sunday the most privileged process on your machine
- Freed-space arithmetic, which is where these tools get their reputation — counting sparse files, snapshots and purgeable space as reclaimed when none of it was
Is that you?
the verdict is a default, not a law
- It only reports — sizes, counts, biggest offenders, a sorted list — with no delete path in the codebase at all
- Anything it does remove goes to the Trash through the system API and is never unlinked
- It runs on your machine, you have a restorable backup from this week, and nobody else runs it
- Every run is a dry run unless you pass a flag you had to look up
- You plan to give it to anyone, because the blast radius becomes other people's disks and other people's assumptions
- It runs unattended, on a schedule, with no confirmation step
- It needs `sudo`, or reaches anywhere outside your home directory
- You cannot restore last Tuesday
If you build it anyway
the checklist, then the prompt that enforces it
- Ship the analyser first and live with it for a month before writing a single delete call. The report is most of the value and none of the risk.
- Removal means moving to the Trash through the system API — never `unlink`, never `rm -rf`. Undo should be a drag, not a restore.
- Keep an explicit allowlist of directories that may be touched. A denylist is a guess about a filesystem you do not control and did not write.
- Dry run by default. Print exactly what would go and how much it would free; `--apply` is a separate, deliberate, documented flag.
- Never follow symlinks, and never act on a path you did not construct yourself from a known-safe root. Pass paths as arguments, never through a shell string.
- Nothing outside `$HOME`. If a rule wants elevated privileges, the rule is wrong and should be deleted instead of the files.
- Log every removal with the full path, size and timestamp to a file outside the cleanup scope, so "what did it take last Tuesday" is answerable.
I am building a macOS disk cleanup tool for my own machine. The
dangerous part is not finding files, it is removing them, so build in this order
and refuse to reorder it when I get impatient.
1. Build the analyser first and stop there: walk the filesystem, report sizes,
biggest directories, stale caches — and include no code that removes
anything. I will live with it before we continue.
2. When I ask for removal, do not implement rm. Move items to the Trash through
the macOS API, and say plainly that unlinking on APFS is unrecoverable
without a backup.
3. Dry run is the default and prints every path with its size. Applying takes a
separate flag and a typed confirmation of the item count and total size.
4. Removal targets come from an allowlist of directories I approve, never a
denylist and never a pattern. If a rule cannot be expressed as an allowlisted
root, do not write it.
5. Never follow symlinks. Build every path from a known root using path APIs and
pass arguments as arrays — never interpolate a path into a shell string.
6. Refuse anything outside my home directory, anything needing sudo, and
anything under /System or /Library. If a rule wants those, the rule is wrong.
7. Before implementing any "safe to delete" rule, tell me which app owns that
directory and what happens on next launch if it is missing. If you cannot
answer both, we do not ship the rule.
8. Write an append-only removal log outside the cleanup scope: path, size,
timestamp, matching rule. It is the only forensics I will have.
9. Report reclaimed space from what the filesystem says before and after, not
from the sum of what you matched.
10. Never run on a schedule and never at login. Cleanup is something I start.
11. Put "Not safe to delete" at the top of the README — Photos, Mail, Messages
and the iCloud sync stores all look disposable and are not — and note this
is for one machine, mine, with a backup.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If you want the deleting rather than the looking. $3.33 a month buys a maintained answer to "what is safe to remove on the current macOS" — a question that changes every September and that you would otherwise re-derive by experiment, on your own disk. Build the analyser regardless; it is better than the one you are buying, because it does not want to sell you anything.
$3.33/mo is cheaper than your weekend.
There is nothing to migrate — delete the binary and the project is over. The exit plan that matters is the one that protects you during the project: a Time Machine backup or an APFS snapshot taken before the first run with `--apply`, because the risk here is not that the tool ends, it is that a single run takes something with it.
Source-available macOS app uninstaller and orphaned-file cleaner; author has paused development since late 2025.
Fast `du` replacement that visualises which directories are actually consuming the disk — the read-only half of this build, already done.
Questions
Why is this DEMO ONLY when the other desktop utilities on this site are SHIP IT?
Because a launcher, a menu-bar tidier or a hotkey tool cannot destroy anything. This one exists to remove files, and it wants Full Disk Access to do it. The analyser half genuinely is a ship-it and you should build it. The verdict covers the version everybody actually ends up with, which has a delete button.
Surely moving things to the Trash makes it safe?
It makes it recoverable, which is most of the way there and is the single highest-value guardrail here. What it does not fix is an app that will not launch until you put its support directory back, or a cache clear that logs you out of everything you had a session for. Reversible is not the same as free.
Is macOS moving things around really that much of a maintenance burden?
Every major release relocates or renames something, adds new container paths, or changes what the system already purges on its own. A rule set that was correct in one September is subtly wrong by the next, and nothing tells you — the tool goes on reporting success while removing the wrong thing. That treadmill is what the licence fee is actually buying.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice