Mole's mo command cleans, uninstalls and monitors a Mac, but half its deleting commands bypass the Trash

One mo command with nine subcommands, and Go TUIs behind analyze and status

Everything runs through a single entry point. Typing mo alone opens an interactive menu; each task also has its own subcommand:

mo                           # Interactive menu
mo clean                     # Deep cleanup + already-uninstalled app leftovers
mo uninstall                 # Remove installed apps + their leftovers
mo optimize                  # Refresh caches & services
mo analyze                   # Visual disk explorer (or 'mo analyse')
mo status                    # Live system health dashboard
mo purge                     # Clean project build artifacts
mo installer                 # Find and remove installer files
mo slim                      # Remove Intel code from universal apps

mo touchid

The repository is mostly shell, but the two interactive views are Go programs. The Makefile builds analyze-go from ./cmd/analyze and status-go from ./cmd/status, and go.mod pulls in charmbracelet/bubbletea and lipgloss for the terminal interface and shirou/gopsutil v4.26.10 for system statistics. That split explains why analyze can navigate directories and find large files interactively while status shows real-time CPU, memory, disk I/O, network traffic and process stats. The project frames the whole set as CleanMyMac, AppCleaner, DaisyDisk and iStat Menus style workflows in one tool. The analyze command accepts the British spelling mo analyse as well. Optimize handles the maintenance side: flushing DNS, refreshing QuickLook and icons, and optimizing system databases.

clean, purge and installer delete permanently; only three commands use the Trash

Mole's safety model is explicit about where files go, and the answer differs by command. After confirmation, mo uninstall, mo analyze and mo slim send deletions to the Trash by default. mo clean, mo purge and mo installer delete permanently. mo uninstall --permanent skips the Trash as well.

The consequence for a reader is concrete: a mistaken clean or purge has no recycle step to undo it. If purge removes a project's build artifacts you still needed, you rebuild them; if clean removes caches or orphaned app data you wanted, they are gone. The six commands that can delete files are clean, uninstall, purge, installer, slim and remove, and the project tells you to review all of them with --dry-run first, adding --debug when you need detail.

Mole does add guardrails. It validates paths, protects shared and system-owned locations, asks for confirmation when an action needs it, and when it cannot prove an item is safe to change, it skips or refuses it. It should be run without sudo; it requests administrator access only when a step needs it. Those protections reduce risk, but they do not turn a permanent delete into a reversible one.

Dry runs, whitelists and scan paths decide what Mole is allowed to touch

The preview and configuration flags are where you control Mole's reach before anything is removed:

mo clean --dry-run
mo uninstall --dry-run
mo optimize --dry-run
mo purge --dry-run
mo installer --dry-run
mo slim --dry-run
mo history
mo history --json

mo clean --dry-run --debug   # Preview + detailed logs
mo optimize --whitelist      # Manage protected optimization rules
mo clean --whitelist         # Manage protected caches
mo purge --paths             # Configure project scan directories
mo analyze /Volumes          # Analyze external drives only
mo analyze /private/tmp      # Review user-owned temporary directories

Three of these matter most. mo clean --whitelist lets you mark caches that clean must leave alone, which is the fix if a cleanup keeps wiping something an app needs. mo purge --paths sets which directories purge scans for project build artifacts, so it does not wander through folders you never meant it to touch. mo history and mo history --json show what Mole has done, which is your record after the fact rather than an undo. Pointing mo analyze at /Volumes restricts it to external drives, and /private/tmp lets you review user-owned temporary directories. Cleanup activity is also written to a log under ~/Library/Logs/mole/.

The script install lands in /usr/local/bin, so every mo update can ask for a password

There are two standard installs. Homebrew is the short one, and the script install exists for Macs whose macOS version Homebrew no longer supports:

brew install mole

curl -fsSL https://raw.githubusercontent.com/tw93/mole/main/install.sh | bash

The script installs to /usr/local/bin by default, which may prompt for an administrator password, and because Mole updates the installation you invoked, later mo update runs hit the same prompt. To keep updates password-free, install into a user-owned directory:

mkdir -p "$HOME/.local/bin"
curl -fsSL https://raw.githubusercontent.com/tw93/mole/main/install.sh | bash -s -- --prefix "$HOME/.local/bin"
export PATH="$HOME/.local/bin:$PATH"

You also need that PATH export in ~/.zshrc or your shell profile, or new terminals will not find mo. Commands that change system-owned files can still request administrator access regardless of where Mole lives.

The script takes a version argument, any release tag with or without its leading V, or main for the development branch. One trap here: latest is a legacy alias for main, and despite its name it does not install the newest stable release. Passing latest gets you unreleased code with rough edges.

Nix installs follow unreleased main and ignore mo update

On macOS, Nix users can install the flake, and the repository root carries flake.nix, flake.lock, package.nix and overlay.nix to support it:

nix profile install github:tw93/mole/main#mole
nix profile upgrade mole
nix profile remove mole

There are two consequences. First, the flake comes from main, which contains unreleased changes, so a Nix install is closer to the development branch than to a tagged release. Second, mo update and mo remove leave Nix-managed installations unchanged. You update and remove through Nix only, with nix profile upgrade and nix profile remove, or by managing the flake input github:tw93/mole/main and its packages.${system}.mole package in a declarative setup. If you install through Nix and later wonder why mo update did nothing, that is the documented behavior, not a bug.

Agent installs keep app uninstalls and administrator steps with you

Mole ships an agent skill and host plugins. The quickest route is to tell an agent: Install Mole for me by reading https://raw.githubusercontent.com/tw93/Mole/main/llms.txt. To add the skill yourself for several agents at once:

npx skills add tw93/Mole -a claude-code codex cursor -g -y

You update it later with npx skills update -g -y. As a host plugin, Claude Code takes /plugin marketplace add tw93/Mole followed by /plugin install mole@mole, and Codex takes codex plugin marketplace add tw93/Mole followed by codex plugin add mole@mole.

The skill changes how the agent behaves. With it installed, Claude Code, Codex, Cursor and other agents show every cleanup with --dry-run before anything is removed, and they leave app uninstalls and administrator steps to you. That is a deliberate limit: an agent can propose and preview, but removing an app or approving an admin prompt stays a human action. If you were hoping to hand an agent full, unattended cleanup of a machine, the skill is built to stop short of that.

The free CLI is not Mole for Mac, and several lookalike domains are not Mole at all

This repository is the free open-source CLI. Mole for Mac is a separate download from mole.fit with review-before-delete cleanup, tested leftovers for more than 800 apps, maintenance, disk drill-downs, live status and fan controls on supported Macs. brew install mole installs the CLI only, so anyone expecting the graphical app from Homebrew will get a terminal tool. Windows has its own native app, Mole for Windows, plus a separate Windows CLI on the windows branch installed with:

iwr -useb https://raw.githubusercontent.com/tw93/Mole/windows/quick-install.ps1 | iex

A Linux line lives on the linux branch, and the branches release on their own tracks: V1.68.0 for macOS, V1.41.0-windows and V0.3.0-linux.

Mole is distributed only through Homebrew, this repository and mole.fit. The project names molemac.com, moleapp.net and molefit.com as not Mole, and says the Windows app at mole.bluecatbot.com is a separate community project. For a tool that deletes files with your permission, downloading from one of those lookalikes means running code the Mole project does not vouch for.

Release builds stay pure Go so the macOS SDK cannot raise the minimum OS

The Makefile shows how the Go parts are built and tested. Release targets set CGO_ENABLED=0 and build separate darwin amd64 and arm64 binaries, with a comment explaining why: keeping them pure Go stops the macOS SDK on the release runner from raising the Mach-O minimum OS version through cgo. That is what lets Mole hold its stated floor of macOS 12 on both Intel and Apple Silicon. Binaries are stripped with -ldflags -s -w. Module downloads retry up to three times with a growing sleep to ride out transient proxy or network EOF errors.

For contributors, make test runs ./scripts/test.sh with MOLE_TEST_NO_AUTH=1, make test-go runs go test across the module, and make verify runs the shell check script plus the Go tests. go.mod targets Go 1.26.0 with toolchain go1.26.10. The repository also includes SECURITY_AUDIT.md and TRADEMARK.md alongside the GPL-3.0 LICENSE. Development is current: the last push to main was 2026-11-02, and V1.68.0 shipped on 2026-11-03.

Editorial conclusion

Mole suits Mac users comfortable in a terminal who want cache cleanup, app removal, a disk explorer and a live status view without paying for separate utilities, on macOS 12 or newer, Intel or Apple Silicon. It is the wrong choice if you want review-before-delete in a graphical window; that is the separate Mole for Mac app. Before the first real run, use --dry-run on clean, purge and installer, because those three delete permanently, and confirm you downloaded from Homebrew, the tw93/mole repository or mole.fit rather than a lookalike domain.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes