How many gigabytes of junk are sitting on your Mac right now without you even noticing?
I’m not talking about duplicate photos from that 2019 barbecue or your Downloads folder looking like a digital landfill. I’m talking about build artifacts. node_modules from projects you haven’t touched since the pandemic. Build caches for frameworks you barely remember installing. Xcode’s derived data piling up like dust under the bed.
I spent months with my drive hovering at 85% full, juggling what to delete. Then I found Mole, ran mo purge --dry-run, and the screen spat out a number: 17 GB recoverable. Three hundred and fifty forgotten build artifacts quietly rotting in the dark.
Seventeen gigabytes. Without even touching a single photo or document.
What is Mole (and what it’s not)
Mole is a CLI for macOS that promises to “deep clean and optimize your Mac.” It comes with a Swiss army knife’s worth of commands:
mo clean # Cleans caches, logs, and temp files mo uninstall # Fully uninstalls apps mo optimize # Checks and “optimizes” your system mo analyze # Inspects disk usage mo status # Monitors system health mo purge # Removes project build artifacts mo installer # Finds old installers mo touchid # Configures Touch ID for sudo
Eight commands. Let me save you the suspense: **only two are worth your time**. The rest range from "meh, I can handle this myself" to "no way I’m running that without more details."
## mo purge: The silent hero
If you’re a developer and have been using your Mac for more than six months, `mo purge` will uncover treasure troves. To put it simply: it scans your project directories to find build artifacts that take up space but serve no purpose whatsoever.
What kinds of artifacts? Here are the usual suspects:
- **node_modules** in Node/Bun projects you’ve abandoned
- **target/** in Rust projects
- **build/** and **.build/** in Swift/Xcode projects
- **DerivedData** from Xcode
- **__pycache__** and virtual environments in Python
- **.gradle** and **build/** in Java/Kotlin projects
- **Pods/** in iOS projects using CocoaPods
The key here is that these directories are 100% regenerable. If you revisit a project later, a quick `npm install` or `cargo build` will have them back up and running. But until then, they’re squatting on your drive rent-free.
### The right workflow
Always start with a dry run:
```bash
mo purge --dry-run
This shows you what it would find and how much space it could free without actually deleting anything. That’s your moment to double-check the list and ensure it won’t wipe the node_modules folder of a project you’ve got open in three terminals.
If the results look good:
mo purge
And just like that, 17 GB return to your drive. That simple.
Configuring scan paths
By default, Mole searches generic paths (~/Projects, ~/GitHub, ~/Code…). If your directory structure is different — and if you’re remotely organized, it probably is — you’ll need to configure it:
mo purge --paths
This opens an editor where you can specify your actual directories. In my case, ~/code and ~/courses. Without this, Mole will scan non-existent directories or miss the ones that actually matter.
mo analyze: The treasure map
mo analyze is the other gem. It launches an interactive TUI (terminal user interface) that maps out your disk, directory by directory, sorted by size.
mo analyze # Analyzes your main drive
mo analyze /Volumes # Analyzes external drives
It’s like Disk Inventory X or GrandPerspective, but in the terminal and without requiring a graphical app.
Why is it useful? Because the problem with disk space isn’t “I need to delete something.” The problem is “I have no idea what’s eating up 50 GB.” mo analyze delivers that answer in seconds. Navigate through the tree, see what’s taking up the most space, and decide what to delete.
The difference from a manual du -sh * | sort -rh: the TUI lets you drill into directories without re-running the command. Go in, come back out, compare sizes. It’s faster and more visual than the purely manual alternatives.
And the rest… well
Here’s a hot take: the other Mole commands range from unnecessary to outright skippable.
mo clean: Does little you can’t already do yourself
It cleans system caches, logs, and temporary files. Sounds great, but macOS already manages most of these caches automatically. The ones it doesn’t handle (like Homebrew or Docker caches) are better cleared manually so you have control over what to keep.
Will you recover 2-3 GB? Probably. Is it worth automating? If your disk is so full that 2 GB makes a difference, mo purge would have given you 10x more.
mo optimize: The black box
“Check and maintain system health, apply optimizations.” Optimizations for what? Applying what exactly? The documentation is vague, and I’m not comfortable running anything claiming to “optimize” my system without knowing the details.
You can run mo optimize --dry-run to preview changes, which is something. But in my experience, these “optimizations” involve things like checking disk permissions, clearing broken fonts, and rebuilding Spotlight indexes. Stuff macOS either already handles or that aren’t necessary unless something’s broken.
mo uninstall: Useful, but conditional
It uninstalls apps and removes all their leftover support files (preferences, caches, etc.), which would otherwise stay behind after you drag the app to the trash. It’s essentially AppCleaner, but for the terminal.
If you uninstall apps frequently, it’s worth having. If not, meh.
mo status: Nice, but more for aesthetics
This displays a terminal dashboard with CPU, memory, disk, and battery stats. It’s slick. But you’ve already got htop, btop, Activity Monitor, and if you use a digital assistant, you can just ask it “How’s my memory usage?” without opening anything.
The takeaway: Less is more
Mole comes with eight commands. Two are pure gold. The rest is fluff you can live without.
mo purge solves a real problem that no other Mac cleaning tool addresses: developer build artifacts. It’s not a shoddy tool clearing system caches and hoping you notice the difference. It targets specific build artifacts, tells you how much space they’re taking, and deletes them. Everything is regenerable. Zero risk.
mo analyze tackles the other real problem: figuring out where your disk space is going. No graphical interfaces, no waiting for Finder to index, no repeating du commands. It’s a fast, efficient TUI that lays out your entire disk usage.
Between the two, I reclaimed 17 GB on my machine in under a minute. Best of all, I can repeat the process every month without hassle — build artifacts pile up like dirty laundry, but now I’ve got a washing machine.
# Your new monthly ritual
brew install mole # One-time setup
mo purge --paths # Set your directories (one-time setup)
mo purge --dry-run # Review
mo purge # Clean
mo analyze # Investigate what else to clear
Bonus: Automate the whole maintenance process
If mo purge is reliable — and it is, because everything it deletes is regenerable with a quick install or build — why not automate it alongside brew upgrade?
“But wait, won’t auto-updating with brew upgrade break things?” It’s a valid concern, but as of 2026, it shouldn’t. Modern version managers like uv handle isolated Python installations per project (uv python install 3.x), and tools like fnm or nvm do the same for Node. The Python or Node from Homebrew is just for the system; your projects won’t rely on it.
With that settled, here’s a LaunchAgent script to run every Sunday for pure maintenance bliss:
#!/bin/bash
# Update Homebrew
brew update && brew upgrade
brew cleanup --prune=30
brew autoremove
# Clear development artifacts
mo purge --yes
Wake up on Sunday, find your Mac with updated packages, empty gigabytes reclaimed from dead node_modules, and a summary message on Telegram. No effort. No reminders. No friction.
That said: don’t automate mo analyze. Deciding what else to delete should always remain a manual choice. But once a month, after your automated purge, running mo analyze to spot unnecessary files is a solid habit.
The best software isn’t the one with the most features. It’s the one that does the two things you genuinely need. Mole has six extra commands, but the two that matter make it absolutely worth installing.