Rust projects have a reputation for eating disk space, and the reputation is earned — but it is earned by three separate things that get lumped together in most people's mental model of "the Cargo cache". Understanding which is which matters, because one of them is safe to delete without a second thought, one is nearly as safe, and one is different for every single project you have ever built.

The three places Rust stores things

~/.cargo/registry — this is Cargo's package cache: downloaded crate source (.crate files, essentially tarballs) and an index of every crate and version on crates.io. It is shared across every Rust project on the machine. Installing the same version of serde in twenty different projects downloads it once.

~/.cargo/git — a similar idea, but for dependencies pulled directly from a git repository rather than from crates.io (a common pattern for unreleased or forked crates, specified with a git = "..." line in Cargo.toml). Cargo keeps a bare clone of each such repository here so it does not have to re-clone on every build.

<project>/target — this one is different in kind. It is not a shared cache; it is the compiled build output for one specific project, including every dependency's compiled artefacts for that project's specific combination of Rust version, feature flags, and target platform. It lives inside the project directory, not in a shared location, and it does not know or care what any other project's target folder contains.

~/.cargo/registry and ~/.cargo/git: safe to delete, slow to rebuild

Both of these are pure caches in the strict sense — nothing in either one is unique or irreplaceable. Cargo will re-download or re-clone anything it needs on the next build. You can delete them by hand:

rm -rf ~/.cargo/registry
rm -rf ~/.cargo/git

The cost is time on your next build across every project, not correctness. If you work on Rust daily, deleting these wholesale is a blunt instrument — better to trim rather than empty, which is where a dedicated tool helps (more on that below).

cargo clean: per-project, not global

cargo clean

Run from inside a project, this deletes that project's target directory — the compiled output — and nothing else. It does not touch ~/.cargo/registry or ~/.cargo/git, and it does not touch any other project's target folder. This is the command you reach for when a single project's build output has grown large (debug builds with full symbol information can be enormous) or when you suspect a stale incremental-compilation artefact is causing a weird build error.

cargo clean accepts a --release flag to clean only release artefacts, leaving debug build output intact, and vice versa is implicit by default (it cleans everything unless scoped).

Why target folders are the real space problem

A single Rust project's target directory, especially with debug symbols and incremental compilation caches enabled (the default for cargo build), can reach several gigabytes for a project of even modest size. Because target lives per-project and is never shared, having a dozen half-finished side projects each with their own multi-gigabyte target folder is extremely common, and none of it is visible from a shared-cache location the way ~/.cargo/registry is.

Finding these requires walking your actual project directories, not a fixed system path:

find ~ -type d -name target -prune -exec du -sh {} \;

This walks your home directory looking for folders literally named target, which will mostly be Cargo build output (watch out for false positives from other tools that happen to use the same folder name).

cargo-cache: a purpose-built tool for the registry side

The Cargo ecosystem has a well-known third-party tool, cargo-cache, installable via cargo install cargo-cache, that understands the registry and git caches well enough to trim them intelligently rather than deleting everything:

cargo cache --autoclean

This removes old, unpacked source checkouts while keeping the compressed .crate files that are cheaper to re-extract than re-download. It can also give you a size breakdown of exactly what is in ~/.cargo/registry by category:

cargo cache --list-dirs

This is worth installing if you maintain more than a couple of active Rust projects and want to reclaim space from the shared cache without going to zero and paying the full re-download cost on your next build.

Incremental compilation and sccache add a further layer

Beyond the three locations already covered, Rust's toolchain has a couple of optional but common extras worth knowing about if you're chasing every last gigabyte. Incremental compilation, enabled by default for debug builds, stores intermediate compiler state inside each project's own target/debug/incremental folder specifically so that recompiling after a small change doesn't require reprocessing the whole crate — this is already covered by cargo clean, since it lives inside target, but it's worth knowing it's there if you're wondering why a debug target folder is disproportionately larger than a release one for the same project.

Separately, some teams configure sccache as a compiler wrapper to cache compiled object code across projects and even across machines (when paired with a shared remote cache backend). If a project's .cargo/config.toml sets rustc-wrapper to sccache, that tool maintains its own cache directory, by default under ~/Library/Caches/Mozilla.sccache on macOS, entirely separate from anything Cargo itself manages. It has its own inspection and clearing commands (sccache --show-stats and sccache --zero-stats for resetting counters, or simply deleting its cache directory), which are worth checking if your team has adopted it, since it can silently become one of the larger Rust-adjacent caches on a shared CI or build machine.

A practical routine

  1. Check du -sh ~/.cargo/registry ~/.cargo/git for the shared caches.
  2. If you build Rust often, install cargo-cache and run cargo cache --autoclean rather than deleting the folders outright.
  3. Walk your project directories for target folders with find ~ -type d -name target -prune -exec du -sh {} \; — this is almost always where the bulk of the space actually is, not the shared registry.
  4. For any project you are not actively building, cargo clean inside it (or simply deleting target by hand) recovers that project's space immediately; Cargo rebuilds it from the shared registry cache on your next cargo build, which is why keeping the registry cache intact makes future clean-and-rebuild cycles faster.

Where VolumeLens fits in

The awkward part of Rust's storage footprint is that the expensive folders live scattered across every project you have ever touched, under a name (target) that gives no hint of its size until you look. VolumeLens scans your whole disk and draws every folder to scale, so a dozen forgotten target directories across old side projects show up next to each other rather than requiring a manual find command to locate. Insights recognises Cargo's registry and git caches by name alongside target folders, so you can see the whole Rust footprint on your Mac in one pass.