Open a Terminal and run du -sh ~/Library/Caches ~/.npm ~/.cargo/registry ~/.cocoapods on any active development Mac and the numbers are sobering. Between npm's global package cache, Homebrew's downloaded bottles, Docker's dangling images, and all the other runtime caches that accumulate over months of work, it is completely normal to find 20–50 GB sitting in directories you have never thought about. The good news: almost all of it is safe to delete and will be regenerated on demand.
This guide covers every major developer tool cache on macOS with the exact file paths, realistic size ranges, the terminal command to clear it, and whether TrimyMac's Smart Clean module handles it automatically. Follow along for each tool you use, or scroll to the FAQ for quick answers.
1. npm Cache & node_modules
npm maintains a persistent content-addressable cache at ~/.npm so that packages you have already downloaded do not need to be fetched again on future npm install runs. This is genuinely useful behavior, but it has no built-in expiry. On a machine that has been active for a year or more, ~/.npm routinely grows to 3–8 GB, filled with tarballs for every version of every package you have ever installed. The cache is safe to wipe at any time — npm will re-download what it needs on the next install.
Separate from the global npm cache, each project's node_modules folder is another major culprit. A typical React or Next.js project's node_modules is 300–700 MB. If you have ten projects checked out, that is potentially 5+ GB in dependency trees that can be fully restored with a single npm install. These folders do not live in a single location, so the first step is finding them.
find ~ -name "node_modules" -type d -prune 2>/dev/null \
| xargs du -sh 2>/dev/null | sort -hr
npm cache clean --force
rm -rf node_modules # Restore later with: npm install
TrimyMac automates this. Smart Clean detects both ~/.npm and stale node_modules folders across your home directory, shows the total size, and lets you remove them in one click. It flags folders that have not been accessed in 30+ days as safe candidates so you do not accidentally delete an active project's dependencies.
2. Homebrew Cache
Every time Homebrew downloads a package bottle — pre-compiled binaries for formulae like git, ffmpeg, postgresql, or node — it saves a copy to ~/Library/Caches/Homebrew. Older versions are never automatically removed, so this folder accumulates stale bottles for every formula version you have ever installed or upgraded. By default Homebrew also keeps old versions of installed formulae in its Cellar, each one taking tens to hundreds of megabytes.
Running brew cleanup removes stale downloads and old formula versions under Homebrew's current rules. You can preview what would be deleted with the --dry-run flag before committing. For command scope, retention choices, and a GUI alternative, use the focused Homebrew cache cleanup guide.
brew cleanup --dry-run
brew cleanup # Also clean older cached downloads (>120 days): brew cleanup --prune=all
The Homebrew cache directory on Apple Silicon Macs is at /opt/homebrew/var/homebrew/logs for logs and ~/Library/Caches/Homebrew for downloaded archives. If you installed Homebrew in a custom prefix, check brew --cache to get the actual path on your machine.
TrimyMac automates this. The Smart Clean "Homebrew" category runs brew cleanup --prune=all under the hood and reports how much was recovered, without you needing to open a terminal.
3. pip Cache
pip, the Python package installer, stores downloaded wheel files and source distributions in a local cache so that re-installing the same package version does not require an internet round-trip. On macOS the cache lives at ~/Library/Caches/pip (for pip installed via Homebrew or pyenv with a standard macOS configuration) or at ~/.cache/pip on systems that follow the XDG convention.
If you regularly install packages into virtual environments, work with data science stacks like TensorFlow or PyTorch, or frequently switch Python versions, the pip cache fills up rapidly with large wheel files for packages you may no longer use. The command pip cache purge (available from pip 20.1+) wipes the entire cache cleanly.
pip cache info # Shows cache location and total size
pip cache purge
# macOS (Homebrew Python / pyenv) rm -rf ~/Library/Caches/pip # XDG-style location (some setups) rm -rf ~/.cache/pip
Virtual environment folders (venv/, .venv/) inside your project directories are a separate concern. They are not the pip cache, but they duplicate installed packages and can be multi-hundred-MB each. Delete a virtual environment and recreate it with python -m venv .venv && pip install -r requirements.txt.
TrimyMac automates this. Smart Clean checks both ~/Library/Caches/pip and ~/.cache/pip and presents the combined size for removal in one step.
4. Cargo Cache
Rust developers often have the largest package caches of any ecosystem. Cargo, Rust's package manager, maintains a local registry at ~/.cargo/registry that contains downloaded source archives (src/) and compiled index data (cache/) for every crate version ever fetched. Additionally, Cargo keeps compiled artifacts in the target/ directory inside each project — these can grow to gigabytes per project for large dependency trees.
The recommended tool for managing Cargo's cache intelligently is cargo-cache, a plugin that shows a detailed breakdown and provides a targeted --autoclean option that removes only the source code for crate versions with no installed binary, keeping the build cache for your currently active crates intact.
cargo install cargo-cache
cargo cache
cargo cache --autoclean
rm -rf ~/.cargo/registry
For project-level target/ directories, the quickest cleanup is cargo clean from the project root, or you can find them all and remove manually:
find ~ -name "target" -path "*/rust/*" -prune -type d 2>/dev/null \
| xargs du -sh 2>/dev/null | sort -hr
TrimyMac automates this. TrimyMac scans ~/.cargo/registry and surfaces stale cached crate source archives alongside your project target/ directories, grouping them for easy bulk removal.
5. Docker: Images, Volumes & Build Cache
Docker on Mac stores everything inside a virtual machine disk image, typically located at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw on Docker Desktop. This file grows aggressively as you pull new images, run containers that write data to volumes, and perform builds that layer new intermediate images. Critically, this file does not automatically shrink when you delete images — the VM disk file reclaims space lazily, or in some versions not at all without a manual reset.
Docker's storage breaks down into four main categories you should clean independently:
- Images — pulled base images and locally built images, including dangling layers from intermediate builds
- Containers — stopped containers still occupy their writable layer on disk
- Volumes — named and anonymous data volumes that persist after containers stop
- Build cache — layers cached by BuildKit to speed up repeated builds, often the largest and most overlooked category
docker system df # Shows images, containers, volumes, build cache sizes
docker system prune # Removes: stopped containers, dangling images, unused networks, build cache # Add --volumes to also remove unused named volumes (careful!) docker system prune --volumes
docker image prune
docker image prune -a
docker builder prune # Add -a to remove all cache, not just dangling layers docker builder prune -a
The --volumes flag on docker system prune will permanently delete named volumes, including any databases or persistent data stored in containers. Double-check your volume contents with docker volume ls before including this flag.
Even after running prune commands, Docker Desktop's virtual disk file may not shrink immediately because the file system inside the VM still reports the old allocated size. In Docker Desktop, go to Settings → Resources → Disk image location to see the current disk image size. If it is still bloated, clicking "Clean / Purge data" forces a full reclaim.
TrimyMac guided cleanup. Because Docker data lives inside a VM disk image rather than normal macOS files, TrimyMac detects the Docker.raw size and guides you to the exact Docker Desktop controls and prune commands to recover that space, rather than operating on the raw VM file directly.
6. CocoaPods Cache
CocoaPods, the dependency manager used in iOS and macOS development, stores two things in ~/.cocoapods: the full specs repository (a git repo of every public pod specification, sitting at ~/.cocoapods/repos) and downloaded pod source archives. The specs repo alone can be 400–700 MB, and it never automatically prunes old data. If you have worked across multiple iOS projects or upgraded many pods over the years, the total can easily exceed 2 GB.
There is no single built-in command equivalent to brew cleanup for CocoaPods, but the cache has two parts you can target separately. The specs repo can be updated to remove stale spec entries, and the downloaded pod cache can be cleared entirely.
du -sh ~/.cocoapods
pod cache clean --all # Removes all locally cached pod source zips
rm -rf ~/.cocoapods/repos # Then update to pull a fresh copy: pod repo update
rm -rf ~/.cocoapods # Re-setup with: pod setup
If you are on a project using CocoaPods, the Pods/ directory in your project root is also regenerated by pod install and can be safely deleted when not actively developing. Add Pods/ to .gitignore in new projects to avoid committing it entirely.
TrimyMac automates this. TrimyMac's Smart Clean identifies ~/.cocoapods and project-level Pods/ directories, shows you the size of each component (specs repo vs. downloaded pods), and lets you selectively or fully remove them without running multiple terminal commands.
How Much Space Can You Actually Recover?
On a Mac that has been in active development for 12–24 months without any manual cleanup, the numbers stack up fast. Here is a realistic example of what you might find:
- npm global cache (
~/.npm): 3.2 GB - node_modules across projects: 6.1 GB
- Homebrew downloads (
~/Library/Caches/Homebrew): 2.4 GB - pip cache (
~/Library/Caches/pip): 1.8 GB - Cargo registry (
~/.cargo/registry): 4.7 GB - Docker build cache and dangling images: 12.3 GB
- CocoaPods cache (
~/.cocoapods): 1.6 GB
That is over 32 GB — from just these six tool categories, before accounting for Xcode's DerivedData folder (routinely 10–30 GB on its own), iOS device backups, or general application caches. These are not edge cases. They represent normal developer machine hygiene debt that builds up quietly in the background.
The good news is that every gigabyte above is fully regenerated on demand. None of these caches contain original work or irreplaceable data. You are deleting redundant copies of things that can be fetched, compiled, or computed again.
Let TrimyMac find this waste automatically
Instead of hunting each directory manually, TrimyMac scans all six tool caches in seconds, shows you the exact sizes, and cleans them in one click — no terminal required.
Building a Maintenance Habit
Running these commands once is satisfying but not a long-term strategy. Developer tool caches regenerate within days of active work. The practical approach is to either run a monthly cleanup pass or automate it.
For manual monthly cleanup, a simple shell script chains the most impactful commands:
#!/bin/zsh # Run monthly: chmod +x cleanup.sh && ./cleanup.sh echo "Cleaning npm cache..." npm cache clean --force echo "Cleaning Homebrew..." brew cleanup --prune=all echo "Cleaning pip cache..." pip cache purge echo "Cleaning Cargo cache..." cargo cache --autoclean echo "Cleaning Docker..." docker system prune -f docker builder prune -f echo "Cleaning CocoaPods..." pod cache clean --all echo "Done. Check disk space:" df -h /
Alternatively, TrimyMac Pro's scheduled auto-clean feature handles all of this silently on a schedule you define — daily, weekly, or monthly — without any terminal or manual steps. You set it once and forget it.