Package caches on a Mac: npm, Homebrew, pip and CocoaPods

9 September 2026 · 6 min read

Every package manager on your Mac keeps a copy of everything it has ever downloaded, and none of them clean up thoroughly by default. On a machine that has been used for development for a couple of years, the combined caches are routinely several gigabytes and occasionally tens of them. All of it is re-downloadable, which makes it the safest large thing on the disk to delete.

Measure first, then clear. The commands below do both.

Measure all of them in one go

Run this in Terminal. Paths that do not exist on your Mac are skipped silently:

du -sh -c ~/Library/Caches/Homebrew ~/.npm ~/Library/Caches/pip \
  ~/Library/Caches/CocoaPods ~/.cocoapods ~/Library/Caches/Yarn \
  ~/.cache 2>/dev/null | sort -h

That gives you a sorted list with a total at the bottom, and it tells you where to spend your attention. There is no point running four cleanup commands when one directory holds ninety percent of the weight.

Two things this does not cover, and they are frequently larger than every cache combined: node_modules folders scattered through your projects, and Xcode’s derived data. Both are dealt with below.

Homebrew

Homebrew keeps downloaded bottles and source archives so a reinstall does not need the network. It prunes some of this periodically on its own, but the directory still grows, especially if you upgrade often.

Find and measure the cache:

du -sh $(brew --cache)

Then see what a cleanup would remove before you commit to it:

brew cleanup -n

If the list looks reasonable, run the real thing:

brew cleanup --prune=all

brew cleanup on its own removes old versions of installed packages and stale downloads. Adding --prune=all clears the download cache entirely, which is the version worth running when you are hunting space.

While you are there, brew autoremove uninstalls dependencies that were pulled in for something you have since removed. That one frees real installed software, not cache, so read its list carefully before agreeing.

npm, and the folders npm leaves behind

The npm cache lives at ~/.npm/_cacache. Check it:

du -sh ~/.npm

The maintained way to trim it is:

npm cache verify

That garbage-collects stale entries and repairs the index. If you want it gone completely, npm cache clean --force empties it, and the next install re-downloads what it needs.

The cache, though, is rarely the real problem. The real problem is node_modules. Every project keeps its own full copy of its dependency tree, and old projects keep theirs forever. Find them:

find ~ -maxdepth 6 -type d -name node_modules -prune -print0 \
  | xargs -0 du -sh | sort -h

Deleting a node_modules folder in a project you still use is safe and reversible: the lockfile pins the versions, so reinstalling gives you the same tree back. Deleting it in a project you have not opened in two years is free space with no downside at all until the day you open it again.

If you use a different Node package manager, the store equivalents are yarn cache clean and pnpm store prune, and yarn cache dir or pnpm store path will tell you where the data actually lives before you clear it.

pip and Python environments

pip has a cache command that reports and clears without you needing to know the path:

pip cache info
pip cache purge

The cache is normally at ~/Library/Caches/pip, and the wheels directory inside it is usually the bulk of it.

As with Node, the environments are heavier than the cache. Virtual environments are per-project directories containing a full copy of every installed package, so a folder of old data science projects can hold a dozen copies of the same large numerical libraries. They are rebuilt from a requirements file in a minute or two, so old ones are good candidates.

find ~ -maxdepth 5 -type d -name ".venv" -prune -print0 \
  | xargs -0 du -sh | sort -h

Adjust the name if you use venv or env instead.

CocoaPods and iOS build data

CocoaPods keeps downloaded pods in ~/Library/Caches/CocoaPods and its own support data in ~/.cocoapods:

du -sh ~/Library/Caches/CocoaPods ~/.cocoapods
pod cache clean --all

If your Mac has been building iOS projects for years, check ~/.cocoapods/repos specifically. Older setups cloned the entire public specs repository to disk, which ran to a couple of gigabytes; current versions use a CDN and may not have that clone at all. If it is there and large, it will be rebuilt on demand.

None of this touches the biggest iOS-related directory, which is Xcode’s. Derived data, device support files, simulator runtimes and archives regularly total more than every package cache on the machine put together, and they are handled differently. Xcode eating the disk covers what is safe to remove there and what you will regret.

Other language toolchains worth checking

The same pattern repeats across ecosystems. If you use these, measure them:

Go modules: du -sh ~/go/pkg/mod, cleared with go clean -modcache
Rust: du -sh ~/.cargo/registry
Gradle: du -sh ~/.gradle/caches
Ruby gems: gem cleanup removes old versions of installed gems
Containers: the disk image behind a container runtime does not shrink when you delete images inside it, so its apparent size and its real size drift apart

Doing it without the terminal, and what not to guess at

If you would rather see the whole picture before running anything, Crumb audits the Mac read-only and reclaims by category, with build artifacts, Xcode data and package caches as separate lines and a total shown before you commit. Its Ask Crumb feature is the part that fits this problem specifically: point it at a directory you do not recognize and it explains what the item is, whether it regenerates, and what breaks if it is gone, which is the actual question behind most of these folders. Nothing is deleted until you approve the plan.

The read-only audit and one full cleanup are free; the rest is $9 once. If you are comfortable with the commands above, they do the same job for nothing, and you should use them.

The rule that keeps you out of trouble either way: caches and downloaded packages regenerate, so clearing them costs you time and bandwidth on the next build. Configuration and lockfiles do not regenerate. If you are not certain which one a directory is, leave it and find out before deleting.

Questions

Will clearing these caches break my current projects? No, provided you clear caches and dependency directories rather than lockfiles or configuration. The next install or build re-downloads what it needs and, because lockfiles pin versions, you get the same dependency tree back. Do not run a cleanup in the middle of a build.

Why does my Mac show all of this as System Data? Because macOS puts anything it cannot categorize as a document, app or media file into that bucket, and everything in ~/Library/Caches qualifies. What System Data is goes through the parts of it in order of size.

Is there any harm in leaving them alone? Only the space. Caches make installs faster and let some of them work offline, so on a machine with plenty of room, clearing them is a small loss for no gain. Do it when you need the space, not on a schedule.

Are the caches under ~/Library/Caches safe generally? Broadly yes, but not uniformly, and some of them are actively in use by a running app. Which caches are safe to delete draws the line properly.