# mole's install script treats latest as an alias for unreleased main, and the repo is not the product it sells

> Mole is a GPL-3.0 command line cleaner for macOS 12 and newer, built as a pure Go binary with five direct dependencies. Three things are worth reading before you install it. The install script resolves latest to the development branch rather than the newest release, Homebrew installs only the CLI and not the paid native app, and the release tags are single words with a capital V, so the changelog is not in the tag names.

**tw93/Mole** — Terminal toolkit for macOS that deep-cleans caches and leftovers, fully uninstalls apps, maps disk usage, and shows live CPU, GPU, memory, and network stats.

- Repository: https://github.com/tw93/Mole
- Website: https://mole.fit
- Stars: 68,747 · Forks: 2,441
- Language: Shell
- License: GPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/tw93-mole

## The install script resolves latest to the development branch, not to a release

The documented way to pin an install is to pass a tag, with or without its leading capital V, or to pass `main` to track the development branch:

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

Then comes the sentence that matters most on the page: `latest` still works as a legacy alias for `main`, and despite the name it does not install the newest stable release. The page warns separately that `main` installs unreleased code from the default branch and to expect rough edges.

So the consequence is specific and serious for this particular tool. Any install script, Dockerfile, dotfile manager or provisioning script that passes `latest` in the belief that it is getting the newest release is installing unreleased code, and Mole's own commands include five that delete files. Passing an explicit tag is the only way to know what you have. The same note explains why the script accepts a tag with or without the leading V, which matters because the release tags use a capital letter V.

## Homebrew installs the CLI, and the paid app is a separate download

Three different things share the name Mole, and the page separates them explicitly.

The first sentence of the project description says it plainly: this repository is the free open-source CLI, invoked as `mo`. Homebrew installs that and nothing more, with the note that `brew install mole` installs the CLI only. The second is Mole for Mac, a separate native download linked from the homepage, described as covering cleanup, app management, maintenance, disk maps and live status in one app, with one licence covering two Macs, free updates and a 14-day refund. The third is Unsloth and CleanMyMac, AppCleaner, DaisyDisk and iStat Menus, which the feature list names as the workflows whose shape Mole combines in a single terminal binary.

The consequence is that the repository you are reading is not the product the homepage sells. If you arrived looking for the app, Homebrew is the wrong route and the page says so in those words. If you arrived for the CLI, the paid licence is irrelevant to you and the code is GPL-3.0.

There is also a platform floor to note. Mole requires macOS 12 or newer and supports Intel and Apple Silicon, and the page says that if Homebrew no longer supports your macOS version, you should use the install script instead. That fallback is also the route with the least pinning, so on an older machine the two trade off against each other.

## CGO_ENABLED=0 is what protects the macOS 12 support claim

The build configuration contains one line with a comment explaining why it exists:

```
RELEASE_GO_ENV := CGO_ENABLED=0
```

The comment above the release targets says to keep these pure-Go so the macOS SDK on the release runner cannot raise the Mach-O minimum OS version via cgo. In other words, the no-cgo setting is not a preference, it is what stops the build machine from deciding which macOS versions the binary can run on.

The dependency list is the same decision seen from the other side. There are five direct requirements: bubbletea and lipgloss for the terminal interface, gopsutil for system metrics, xxhash, and golang.org/x/sys. The long indirect list is almost entirely gopsutil's platform backends, including go-ole, coninput, wmi and plan9stats, which exist so the same binary can read metrics on Windows as well as on Unix.

So the consequence is a specific failure mode avoided. If a cgo-backed dependency were introduced, a binary built on a newer macOS runner would carry that runner's minimum OS version and stop launching on the macOS 12 machines the project claims to support. The symptom would look like an unsupported operating system rather than a build configuration problem, which is exactly the kind of report that wastes an afternoon. The repository is also classified as Shell rather than Go, because install.sh and the scripts directory are shell, and it configures both linters to match, with a .shellcheckrc and a .golangci.yml.

## The Makefile builds two helper binaries and never produces the mo you install

The build targets name exactly two outputs. ANALYZE and STATUS are set to analyze and status, their sources are ./cmd/analyze and ./cmd/status, and the local build target compiles them with stripped flags into a bin directory as analyze-go and status-go:

```
LDFLAGS := -s -w
```

The release targets do the same two builds again with GOOS=darwin and GOARCH set to amd64 or arm64, so the release artefacts are also limited to those two commands. The repository tree meanwhile contains cmd/, internal/, lib/, scripts/, tests/, install.sh, and two entries named `mo` and `mole` at the top level.

Nothing in the Makefile produces a binary called `mo`, which is the command every example on the page uses. So the shipped entry point is not what `make build` gives you, and the documented install path is the install.sh script rather than the Makefile.

The consequence is practical if you are building from source. Follow install.sh, not the Makefile, and expect the Makefile to be aimed at the release pipeline and at testing rather than at producing what users run. Two other targets are worth knowing about: `verify` runs check and test-go together, and the test target invokes the shell test suite with MOLE_TEST_NO_AUTH set to 1, so the authenticated code paths are deliberately not exercised by the default test run.

## The safety model refuses what it cannot prove, and prints a reason per item

This is a tool that removes files, so the safety section is the part to read. Mole validates paths, protects shared and system-owned locations, and asks for confirmation when an action needs it. The stated rule is blunt: when Mole cannot prove an item is safe to change, it skips or refuses it. It is also told to run without sudo, requesting administrator access only when needed.

The skip behaviour is visible per item rather than summarised. In the sample clean output a pnpm cache line is marked as skipped with the reason that pnpm is busy, alongside the other categories that were cleaned. So a run tells you what it declined and why, which is the difference between a tool you can audit and one you have to trust.

Two escape hatches are worth noting. `mo analyze` moves selected items to the Trash after confirmation rather than deleting them outright, and cleanup activity is written to ~/Library/Logs/mole/operations.log, which you can read back with `mo history` or `mo history --json`, or disable entirely by setting MO_NO_OPLOG to 1. If your threat model includes the log file itself, that switch matters.

The project also ships SECURITY.md and SECURITY_AUDIT.md and points at them for reporting guidance, safety boundaries and current limitations. A published audit is unusual for a utility at this size and is the first thing to read before a first destructive run.

## Every destructive command has a dry run, and the whitelists persist to a file

Five commands can delete files: clean, uninstall, purge, installer and remove. Every one of them takes `--dry-run`, and `--debug` is available alongside it for a more detailed preview.

```bash
mo clean --dry-run
mo uninstall --dry-run
mo optimize --dry-run
mo purge --dry-run
mo installer --dry-run
mo clean --dry-run --debug
```

The two whitelists are the part that has a lasting effect. Selections made with `mo clean --whitelist` persist in ~/.config/mole/whitelist, and `mo optimize --whitelist` manages protected maintenance items the same way. Because the state is a file on disk, it survives upgrades and it is inspectable, which means if a clean stops reclaiming space months later the first place to look is that file rather than the tool.

Two other commands scope the tool rather than change it. `mo purge --paths` configures which project directories are scanned for build artifacts, and `mo analyze` accepts a path so you can point it at a single volume or directory, with the page giving /Volumes and /private/tmp as examples. The one privilege-related command is `mo touchid`, which configures Touch ID for sudo.

That last one deserves a second look before you run it. It changes how sudo is authenticated on the machine, so it is a persistent security setting rather than a cleanup operation, and the page does not describe how to undo it.

## Three releases in five days are named Unblocked, Measured and Restraint

The three most recent tags are V1.56.0 on 2026-09-25, V1.55.0 on 2026-09-20 and V1.56.1 on 2026-09-28. Two details about them are worth pausing on.

First, the tags use a capital V. Automation that assumes a lowercase v will not match them, which is the reason the install script accepts a tag with or without the leading V, and the reason the page gives a bare numeric example like 1.51.0 rather than repeating a tag exactly.

Second, the release titles are single words: V1.56.0 is called Measured, V1.56.1 is called Unblocked, and V1.55.0 is called Restraint. Three releases inside eight days, and the names do not tell you whether a change touches the deletion logic, the skip rules, or only presentation.

The consequence is that you cannot triage an upgrade from the tag names. For a tool that removes files on someone's laptop, read the commit diff between the two tags yourself before you move, and pay particular attention to anything touching path validation or the protected-location list, since those are the two behaviours the safety section depends on. The last push to main was on 2026-09-29, so the branch is moving, which is the other reason not to install from it by accident.

## GPL-3.0 covers the code, and a trademark file covers the name

The repository is licensed GPL-3.0, and it carries a TRADEMARK.md alongside LICENSE. It also carries SECURITY.md, SECURITY_AUDIT.md, CONTRIBUTING.md, a .gitleaks.toml for secret scanning, githooks, and agent instruction files in .agents/, .claude/ and .cursor/ next to an AGENTS.md and a CLAUDE.md.

The licence and the trademark file are separate obligations, and the page is explicit that the repository is the free open-source CLI while the native app of the same name is a paid download with its own licence terms.

So the consequence is a fork question. If you take this code, you are working under GPL-3.0, which carries its own distribution obligations. If you also want to call your build Mole, you have to look at TRADEMARK.md, because a copyleft licence on the source does not hand you the right to use someone else's product name, and the presence of a dedicated trademark file next to a commercial product of the same name suggests the mark is being actively policed. Nothing in the page states the trademark terms, so read that file before you publish anything under the name.

The same separation explains the odd repository shape. A Go codebase with a shell installer, a published security audit, a whitelist file in the user's config directory and a companion app for sale is a coherent project, just not a single-product one.

## Conclusion

Use Mole if you want a scriptable cleaner you can preview before it deletes anything, and prefer it over a closed-source cleaner on that basis alone. Four things to settle first. Always pass an explicit tag to the install script, because latest resolves to unreleased main and this is a tool that removes files. Decide which of the three things sharing the name you actually want, since brew install mole gives the CLI, the native app at mole.fit is a separate paid download, and the repository is the CLI only. Read SECURITY.md and SECURITY_AUDIT.md before a first destructive run, since the project states its own limitations there. And diff the commits between two tags before upgrading, because three consecutive releases are named Unblocked, Measured and Restraint, which tells you nothing about what changed. Use the whitelists and keep the operations log on until you trust a run.

## FAQ

### Is mole from tw93 as safe as CleanMyMac?

The project page makes no comparison with CleanMyMac. What it documents is its own safety model: path validation, protection of shared and system-owned locations, confirmation prompts, skipping or refusing any item it cannot prove is safe, a printed reason per skipped item, an operations log at ~/Library/Logs/mole/operations.log readable through `mo history`, whitelists for caches and maintenance items, and separate SECURITY.md and SECURITY_AUDIT.md files listing limitations. It also instructs you to run it without sudo.

### What is a free app for cleaning up Mac storage?

Mole's CLI is the free part, installed with `brew install mole` or with the install script, and it requires macOS 12 or newer on Intel or Apple Silicon. It provides `mo clean` for caches, logs and leftovers of apps you already removed, `mo analyze` as a disk explorer that moves selected items to the Trash, and `mo status` as a live dashboard. The native app is a separate paid download, not something the CLI or Homebrew installs.

### What are the pros and cons of CleanMyMac?

Nothing on this project's page evaluates CleanMyMac, so there is no comparison to report. Mole names CleanMyMac alongside AppCleaner, DaisyDisk and iStat Menus only as the workflows it says it combines into a single terminal binary. That is a claim about scope, not a judgement about those products, and no benchmark or feature matrix is published here.

### Is there an open-source app cleaner for macOS?

Mole is one, licensed GPL-3.0, with the command line tool `mo` as the open-source part. `mo uninstall` removes an installed app along with launch agents, preferences and hidden remnants that Mole can tie back to that app, and it keeps shared data when another installed copy still uses it. If an app is already gone, the page directs you to `mo clean` to find the leftovers instead.

## Sources

- [Official documentation](https://mole.fit)
- [Official README](https://github.com/tw93/Mole#readme)
- [Project repository](https://github.com/tw93/Mole)
- [Release notes](https://github.com/tw93/Mole/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tw93-mole