CleanMyMac CLI: a Terminal cleaner for Xcode, Docker and project artifacts

The storage problem CleanMyMac CLI is aimed at

General-purpose Mac cleaners look for user-facing clutter: old downloads, photo libraries, mail attachments. A developer's disk fills up somewhere else. Xcode writes DerivedData, Device Support and Module Cache. Package managers keep download caches. Every project folder grows a node_modules, a .next, a .turbo, a target or a .build directory that can be regenerated at any time but is expensive to rebuild. Docker images and volumes sit in their own storage area. The README frames the tool around exactly this: leftovers spread across Docker, Xcode, package managers, project folders and AI tools, brought into one place so the final decision stays with you.

The audience is narrow on purpose. It is for people who already live in a terminal and would rather type a command than open a GUI. The README states the tool is built and used daily by the CleanMyMac team on their own Macs, and that it is currently in public beta, so commands and behavior may change. Treat the surface as unsettled.

How clean, purge and analyze divide the work

The design separates shared caches from per-project artifacts, and the README says so explicitly: use clean for shared caches and tool-generated junk, use purge for removable dependencies and build artifacts stored inside project folders.

clean runs all categories at once, or you can narrow it. clean dev covers cached packages and build files from Homebrew, npm, Yarn, pnpm, pip, Cargo, Go, CocoaPods, Docker, VS Code, JetBrains, Maven, Gradle, Poetry, uv, Bun, Deno and mise. clean junk covers user logs plus Xcode DerivedData, Device Support, Module Cache and Documentation Cache. clean ai scans artifacts left by AI tools, and clean trash empties the system trash and mounted-volume trash bins.

purge is the more interesting one. With no argument it scans ~/Projects, ~/Code, ~/dev, ~/GitHub and ~/Workspace, and groups results by project so you can see which artifact belongs to which codebase. It detects node_modules, .next, .turbo, target, .build, .venv, venv, pycache, Pods, DerivedData, vendor and cmake-build-* directories. The selection rule is age-based: artifacts older than seven days are preselected, newer ones stay visible but unchecked. That is a reasonable default, since a node_modules you rebuilt this morning is probably still in use, but it is a heuristic and not a guarantee about your working set.

analyze is the read-only path. It opens an interactive storage analyzer, optionally rooted at a folder you name, lets you navigate directories by size and reveal items in Finder, and according to the README does not modify files while you browse.

Installing CleanMyMac CLI and running a first cleanup

The requirements are macOS 11 or later and Homebrew. The formula lives in the MacPaw/homebrew-taps tap, and the README gives the cask as the fastest install path:

brew install --cask cleanmymac-cli

Confirm the binary is on your path:

cleanmymac --version

Before removing anything, look at what is actually consuming space. This is the step the README recommends when you are unsure what is safe to remove:

cleanmymac analyze

You can also start the analyzer from a specific directory:

cleanmymac analyze ~/Projects

When you are ready to act on project artifacts, run purge without arguments to scan the default developer folders. Results arrive grouped by project, with artifacts older than seven days preselected and newer ones unchecked for manual review:

cleanmymac purge

If you want to protect a path before any of this runs, add it to the ignore list. The README shows the exact form:

cleanmymac ignore add ~/Projects/important-project

List and remove entries with cleanmymac ignore list and cleanmymac ignore remove. Note that both cleanmymac and cmm run the same tool, so either name works.

Where the safety model stops short

CleanMyMac CLI puts confirmation in front of deletion, excludes protected system locations, and keeps an ignore list. Browsing in the analyzer does not modify files, and removal requires an explicit selection and confirmation. That is a coherent model, and it is the reason the tool is usable at all for something as destructive as deleting build directories.

The weak point is --force. The README's own warning is blunt: --force skips interactive confirmation for supported cleanup commands and removes detected items immediately, and it advises running the command without --force first. There is no documented dry-run flag, no rollback, and no undo. Once a purge completes, the artifact is gone and you rebuild it. For node_modules that is usually a few minutes of npm install; for a Cargo target directory or a large Xcode DerivedData tree it can be considerably longer. The ignore list is your only durable protection, and it is opt-in, so a path you forgot to register is fair game.

The age heuristic deserves the same skepticism. Seven days is a fixed threshold, not a reading of your workflow. A long-lived branch you have not touched in a month will have its artifacts preselected even if you are about to return to it. The preselection is a suggestion, not a correctness guarantee, which is exactly why the interactive review exists.

There is also a scope boundary worth stating plainly: this is a macOS tool. The requirements name macOS 11 or later, and nothing in the README suggests a Linux or Windows build.

How it differs from rm -rf and from the CleanMyMac app

The obvious alternative is doing it yourself. A shell one-liner that walks your project tree and deletes node_modules is trivial to write and has no install step. The difference is knowledge of what each tool leaves behind. CleanMyMac CLI carries a detection list that spans Homebrew, npm, Yarn, pnpm, pip, Cargo, Go, CocoaPods, Docker, VS Code, JetBrains, Maven, Gradle, Poetry, uv, Bun, Deno and mise, plus Xcode-specific paths like Device Support and Module Cache that most people would not think to look for. It also groups purge results by project, which a find command does not do without extra work. The README states the cleanup detection is based on logic shared with CleanMyMac, so the catalog is maintained rather than hand-rolled.

The other comparison is the CleanMyMac desktop application, which is a separate product with a GUI and a paid model. The CLI is distributed as its own Homebrew cask and is described as a public beta. Installing the CLI does not install or replace the app, and the CLI's uninstall path is the standard Homebrew cask removal, not the app's uninstaller. If your question is how to remove the desktop application, this command-line tool is not the answer.

Beta status, licensing and what upgrades cost you

The repository is not archived, and the last push was on 2026-08-26, so it is recent. The single listed release is v.1.0.0, dated 2026-07-17 and labelled Public Beta, which matches the README's own note that commands and behavior may evolve. Practically, that means a scripted workflow built on cleanmymac subcommands should be treated as something that may need adjustment between releases, and pinning a version in your tooling is more sensible than tracking the cask blindly.

The licence field reports NOASSERTION, and the repository root contains a LICENSE file. That means GitHub could not map the file to a known SPDX identifier. Reading the LICENSE file directly is the only way to know what you are permitted to do with the source, and nothing in the README or the repository layout substitutes for that. This is not legal advice; it is a note that the metadata does not answer the question.

On privacy, the README states that no source code or personal files are uploaded and that analytics can be disabled via configuration. It does not document the configuration key or file in the pages available here. If that matters to you, check the Safety and Privacy wiki page the README links before running the tool on a work machine.

Upgrade cost is mostly operational. Homebrew handles the cask, so updates are a brew upgrade away, but a beta that changes command behavior can break a cron job or a shell alias without warning.

Editorial conclusion

Adopt CleanMyMac CLI if you work on macOS and your disk pressure comes from Xcode DerivedData, package manager caches or node_modules trees, and you want to inspect each item before it is removed. Do not adopt it on Linux or Windows, and do not reach for it to uninstall the CleanMyMac desktop app, which is a different product with its own removal steps. Verify two things first: that your Mac is on macOS 11 or later with Homebrew available, and that the paths you care about are registered with cleanmymac ignore add before you run anything with --force.

Frequently asked questions

Official sources

1. Issues
2. MacPaw/cleanmymac-cli on GitHub
3. README
4. Releases