Where Do All the Dev Caches Live on macOS? A Map of pip, npm, cargo, .m2 & More

If your Mac's storage keeps shrinking despite deleting apps and emptying the Trash, the culprit is almost certainly the layer of caches that development toolchains silently accumulate. Knowing every developer cache location on Mac is the first step toward reclaiming tens — sometimes hundreds — of gigabytes without breaking a single project. This guide maps the real paths for Python (pip/uv), Node.js (npm/pnpm/Yarn), Rust (Cargo), Java (Maven and Gradle), Xcode, CocoaPods, Homebrew, and a handful of others. All paths are tested on macOS Sequoia and apply equally to Apple Silicon (M-series) and Intel Macs.

Why Dev Caches Get So Large

Package managers cache downloaded archives so they don't re-download them on every install. Compilers cache build artifacts so incremental builds stay fast. Both behaviors are genuinely useful — but neither cleans itself up automatically on macOS. A laptop used for active development for a year or two can accumulate 30–80 GB in caches spread across a dozen hidden directories. Unlike application caches in ~/Library/Caches, most developer caches live in dotfolders in your home directory (~) and are invisible to Finder by default.

The Master Map: Developer Cache Paths at a Glance

Use the table below as a quick reference. Disk sizes are illustrative ranges based on typical active projects; your numbers will vary.

Python: pip, virtualenvs, and uv

pip stores downloaded wheel and sdist archives at ~/Library/Caches/pip/wheels and ~/Library/Caches/pip/http-v2. These directories persist even after you uninstall packages, because pip intentionally keeps them to speed up future installs. Clear them with:

• pip cache purge — removes all cached wheels and HTTP responses
• Or delete directly: rm -rf ~/Library/Caches/pip

The newer uv package manager (now widely adopted on Sequoia) keeps its cache at ~/.cache/uv. Run uv cache clean to purge it. Virtualenvs created with python -m venv or uv venv live wherever you placed them (commonly ~/.venv or within your project directories), so check those repo folders too — node_modules-style bloat is common inside large monorepos that create many envs.

Node.js: npm, pnpm, and Yarn

Node tooling is among the biggest offenders. See how to clean up node_modules on Mac for a deeper look, but the caches themselves are separate from node_modules:

• npm — cache lives at ~/.npm (specifically ~/.npm/_cacache). Verify the size with npm cache verify, then clear with npm cache clean --force.
• pnpm — uses a global content-addressable store at ~/.local/share/pnpm/store/v3. Prune unreferenced packages with pnpm store prune.
• Yarn Classic (v1) — cache at ~/Library/Caches/Yarn/v6. Clear with yarn cache clean. Check the path with yarn cache dir.
• Yarn Berry (v2+) — stores cache per-project under .yarn/cache inside each repo, so you need to audit each project directory separately.

Rust: The Cargo Registry

Cargo keeps a local registry of downloaded crate sources at ~/.cargo/registry/src and compressed index data at ~/.cargo/registry/cache. Git-sourced dependencies land in ~/.cargo/git. Build artifacts live inside each project under target/, not in the home directory — those can easily top 10 GB per project for large codebases.

The cleanest way to prune unused crate caches is the cargo-cache crate. Install it and run:

1. cargo install cargo-cache
2. cargo cache -a — removes all cached sources while leaving installed binaries intact
3. Or cargo cache --remove-dir git-db,registry-sources for selective removal

Java: Maven .m2 and Gradle Caches

Java-based build tools are notorious for accumulating multi-gigabyte local repositories.

Maven

Maven's local repository lives at ~/.m2/repository. Every version of every artifact you've ever resolved sits here — including old SNAPSHOT builds that may no longer exist on any remote server. Safe pruning:

• Delete old SNAPSHOT directories manually, or
• Use the versions-clean goal from the Versions Maven Plugin, or
• Simply rm -rf ~/.m2/repository and let Maven re-download what the next build actually needs

Gradle

Gradle scatters caches across ~/.gradle/caches, which contains version-specific subdirectories like ~/.gradle/caches/8.7 or ~/.gradle/caches/modules-2. Older version directories are completely safe to remove. The Gradle wrapper distributions live at ~/.gradle/wrapper/dists — keep only the version(s) your active projects use. To clean from the command line:

• rm -rf ~/.gradle/caches/build-cache-* — removes Gradle build caches only
• gradle --stop then delete specific cache subdirs for a more targeted approach

How to Audit Your Dev Caches in One Pass

Rather than hunting each directory manually, you can get a ranked summary in Terminal with a single pipeline. Open Terminal and run:

1. Check all common dev cache roots at once:
   du -sh ~/.npm ~/.cargo ~/.m2 ~/.gradle ~/Library/Caches/pip ~/Library/Caches/Yarn ~/Library/Caches/Homebrew ~/Library/Developer/Xcode/DerivedData 2>/dev/null | sort -rh
2. Identify the largest offenders from the output.
3. Use the appropriate clean command from the table above for each toolchain.
4. Re-run the du command to confirm reclaimed space.

A tool like Crumb can audit all of these locations at once, show you exactly what each folder contains, and let you confirm what's safe before anything is removed — useful if you'd rather not type a dozen rm -rf commands by hand.

Xcode: DerivedData, Archives, and Device Support

Xcode is usually the single largest source of developer storage bloat on a Mac. The main locations to know:

• ~/Library/Developer/Xcode/DerivedData — per-project build artifacts, indexes, and module caches. Completely safe to delete; Xcode rebuilds from source. See why Xcode takes up so much space for a full breakdown.
• ~/Library/Developer/Xcode/Archives — signed app archives created for distribution. Do not delete unless you are sure you no longer need to re-export those builds.
• ~/Library/Developer/Xcode/iOS DeviceSupport and watchOS DeviceSupport — debugging symbol packages downloaded when you first connected a device running a specific OS version. Old OS folders (e.g., iOS 15 or 16 symbols on a machine now running iOS 18 devices) are safe to delete.
• ~/Library/Developer/CoreSimulator/Caches and ~/Library/Developer/CoreSimulator/Devices — simulator runtimes and device states. Remove unused runtimes via Xcode > Settings > Platforms rather than deleting files directly.

Homebrew and CocoaPods

Homebrew stores downloaded formula bottles (prebuilt binaries) at ~/Library/Caches/Homebrew. Old versions accumulate every time you upgrade a formula. Run brew cleanup (or brew cleanup --prune=all for a more aggressive purge) to remove everything older than the currently installed version. The command is safe to run at any time.

CocoaPods caches pod sources at ~/Library/Caches/CocoaPods/Pods. Clear with pod cache clean --all. Note that the CocoaPods specs repo itself lives at ~/.cocoapods/repos and can reach 500 MB–1 GB; you can delete and let it re-clone, though the initial pod install after that will take longer.