CleanMyMac CLI: a Homebrew-installed cleaner for Xcode, Docker and project artifacts

The disk-space problem it targets, and who feels it

The README frames the problem in one line: developer storage builds up across Docker, Xcode, package managers, project folders and AI tools, and CleanMyMac CLI brings those leftovers into one place. That is a real shape of problem on macOS, where the same machine holds tool caches under a user library, per-project dependency trees, and Xcode's DerivedData, Device Support and Module Cache directories. Each of those has its own deletion ritual, and most of them are undocumented in the tool that created them. The intended user is a developer or a technical operator working in a terminal on macOS 11 or later, not a general Mac user looking for a one-button cleanup. The README states the tool is built and used daily by the CleanMyMac team on their own Macs, which is a claim about the authors rather than about the software, and it is the only statement of that kind in the material. What the README does not give is any measurement: no before-and-after disk figures, no list of how much space each category typically frees. You get the categories and the review flow, not a promise about the result.

How the clean and purge commands divide the work

The design splits removable files into two populations, and the README is explicit about which command owns which. clean handles shared caches and tool-generated junk: Homebrew, npm, Yarn, pnpm, pip, Poetry, uv, Cargo, Go, CocoaPods, Docker, VS Code, JetBrains, Maven, Gradle, Bun, Deno and mise are named for the dev category, while the junk category covers user logs plus Xcode DerivedData, Device Support, Module Cache and Documentation Cache. purge handles removable dependencies and build artifacts stored inside project folders, and it scans ~/Projects, ~/Code, ~/dev, ~/GitHub and ~/Workspace by default, or a path you pass. The artifact list for purge is concrete: node_modules, .next, .turbo, target, .build, .venv, venv, pycache, Pods, DerivedData, vendor and cmake-build-*. Results are grouped by project so you can see which artifact belongs to which codebase. The distinction matters because the two categories have different lifetimes. A Homebrew cache is shared across projects and can be rebuilt by re-downloading; a node_modules directory belongs to one repository and is rebuilt by a package manager run against that repository's lockfile. Mixing them into a single scan would make the review list harder to reason about, and the README's tip separates them for exactly that reason.

Age-based preselecting and the review step

The one piece of selection logic the README describes in detail is the seven-day rule in purge. Artifacts older than seven days are preselected; newer artifacts remain visible but unchecked for manual review. That threshold is a heuristic, not a safety guarantee. A project you touched yesterday can still be the one whose node_modules you want gone, and a project you have not opened in a month may be one you are about to return to. The rule is a reasonable default for the common case of abandoned side projects, and it is the only automatic selection the documentation describes. Everything else is presented for review: the README describes interactive prompts before deletion and states that browsing in the analyzer does not modify files, with removal requiring explicit selection and confirmation. The ignore list sits alongside this. cleanmymac ignore add ~/Projects/important-project protects a path permanently, cleanmymac ignore list shows protected paths, and cleanmymac ignore remove takes a path back off the list. The README does not say where that list is stored, whether it is a file you can edit or version-control, or whether entries are matched by prefix or by exact path. Those are the questions to answer before you rely on it, because a prefix match and an exact match behave very differently for nested project trees.

Installation and the commands you actually type

The tool ships through a Homebrew tap at MacPaw/homebrew-taps, and the README gives the install as brew install --cask cleanmymac-cli. Note the cask: this is a cask install rather than a formula, which is consistent with a signed binary distribution rather than a source build. Verification is cleanmymac --version, and running cleanmymac with no arguments launches the interactive interface. Both cleanmymac and cmm run the same tool, according to the README. The command surface is small enough to hold in your head: clean with the subcategories dev, junk, ai and trash; purge with an optional path; analyze with an optional starting folder; optimize with the subcommands ram and purgeable; and ignore with add, list and remove. optimize ram releases inactive memory and optimize purgeable asks macOS to release disk space already marked as purgeable, which the README describes as asking the system rather than forcing anything. The one flag documented is --force, which skips interactive confirmation for supported cleanup commands and removes detected items immediately. The README's own warning tells you to run the command without --force first and review what it finds. That is the single most important line in the installation section, because --force turns a review tool into a deletion tool with no second chance.

Where the documentation thins out

Three gaps stand out. First, the ai category. The feature list says CleanMyMac CLI can detect caches and generated files from supported AI-tool artifacts, and the command table says clean ai scans for junk created by AI tools, but no tool is named. Compare that with clean dev, where seventeen package managers and editors are listed by name. If your disk pressure comes from model weights or local inference caches, the README does not tell you whether those are in scope. Second, the protected system locations are described as excluded from cleanup but never enumerated, so you cannot verify the boundary yourself. Third, the privacy section states that no source code or personal files are uploaded and that analytics can be disabled via configuration, but it does not name the configuration file, the key, or the default state. The README also does not state whether cleanup detection runs entirely locally or consults a signature list fetched from MacPaw, though it does say the detection logic is shared with CleanMyMac. For a tool whose whole job is deciding what is safe to delete, the safety and privacy wiki page is doing more work than the README, and you should read it before the first --force run rather than after.

The licence is unclassified in the repository metadata

The repository metadata reports NOASSERTION for the licence, which means no standard licence identifier was detected. That is not the same as having no licence, and it is not the same as being unlicensed. It means you cannot tell from the metadata alone what terms apply, and the README does not discuss licensing at all. For an individual developer installing a cask on a personal Mac, this is a footnote. For anyone packaging the tool into a corporate machine image, a CI runner or an internal developer setup script, it is the first thing to resolve, because redistribution and internal-use terms are exactly what an unclassified licence leaves open. Check the repository for a licence file and read it. This is a factual gap in the supplied material, not a legal opinion, and the answer has to come from the project rather than from any summary of it.

Versus a shell script or a general-purpose disk utility

The obvious alternative is a hand-written cleanup script: a shell function that removes ~/Library/Caches/Homebrew, Xcode's DerivedData, and a find over your project roots deleting node_modules. That approach is free and fully transparent, and it is genuinely better on one axis: you know exactly what it deletes because you wrote it. What it lacks is the review step and the per-project grouping. A find command that deletes node_modules across ~/Projects does not tell you which projects it hit, does not preselect by age, and has no ignore list beyond the paths you remember to exclude. CleanMyMac CLI's purge gives you a grouped list, a seven-day default, and a persistent ignore list with add, list and remove subcommands. The trade is that you are trusting MacPaw's detection logic, which the README says is shared with the GUI CleanMyMac product, instead of your own. The second alternative is a GUI disk analyzer, which shows sizes well but does not know that .turbo or cmake-build-* directories are regenerable. The CLI's value is that its category list is developer-specific. Its cost is that the same category list is opaque: you cannot read the rules, only the results.

Beta status, maintenance and what to check before adopting

The README states plainly that CleanMyMac CLI is in public beta and that commands and behaviour may evolve. The release history supports that reading: the only release in the material is v.1.0.0, published 2026-07-17 and labelled Public Beta, with the most recent push to the repository on 2026-08-26. There is no changelog in the supplied material, no compatibility matrix beyond macOS 11 or later, and no statement about how long a beta period will last or what changes at 1.0. Practically, that means two costs. The first is upgrade churn: a beta CLI whose commands may change is a poor candidate for a pinned internal script, because a flag or subcommand can move under you. The second is that the ignore list and any analytics configuration are state you would have to migrate if the format changes, and the README does not document either format. The honest position is that this is a tool to try interactively on your own machine now, and to reconsider for automation once the project leaves beta and the licence and configuration details are documented. Until then, the safe pattern is analyze first, then clean or purge without --force, and treat --force as a switch you only use after you have seen the same scan produce a list you agree with.

Editorial conclusion

Adopt it if you work on a Mac and want one terminal command that finds Homebrew, npm, pip, Xcode and Docker leftovers without opening a GUI. Do not adopt it as an unattended scheduled job: the README warns that --force deletes detected items immediately, and the tool is in public beta with commands and behaviour explicitly subject to change. Before trusting it with real work, run cleanmymac analyze and a plain cleanmymac purge without --force, then check that cleanmymac ignore list shows the paths you protected with cleanmymac ignore add. The repository metadata reports the licence as NOASSERTION, so confirm the actual terms in the repository before shipping it inside a company image.

Official sources

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