Developer Disk Cleanup
Cargo Cache vs target Folder: What Can You Delete?
Learn the difference between Rust target build artifacts and Cargo dependency caches, what is safe to remove, and what you should never delete from .cargo

If you need disk space, clean old project target folders first. They contain build artifacts for individual Rust workspaces and can be recreated by compiling again. Clear Cargo's shared dependency cache only when it is genuinely large, corrupted, or no longer needed for offline work—doing so makes Cargo download or extract dependencies again.
Do not delete the entire .cargo directory. It can also contain configuration, registry credentials, and binaries installed with cargo install, none of which are disposable cache files.
Paths and commands were checked on macOS 15.7.7 with Cargo 1.84.0 and rustc 1.84.0 on August 12, 2026. Cargo supports custom home and target directories, so inspect your actual paths before removing anything.
The short answer: target first, Cargo cache second
Cargo stores two different kinds of reproducible data:
- a workspace
targetdirectory holds compiled output for that project; - Cargo Home, usually
~/.cargo, holds shared downloads, extracted package sources, Git dependencies, configuration, credentials, and installed command-line tools.
That distinction determines the cleanup cost. Removing target trades disk space for compilation time. Removing dependency caches may require both network access and compilation time. For most developers, an abandoned project's target folder is therefore the best first candidate.
| Path | What it contains | Can you remove it? | What happens next |
|---|---|---|---|
project/target | Debug and release builds, incremental data, docs and target-specific output | Yes, after stopping builds | The project recompiles |
~/.cargo/registry/cache | Downloaded compressed crate archives | Usually, if you are online | Cargo downloads missing crates again |
~/.cargo/registry/src | Extracted registry package sources | Usually, if you are online | Cargo extracts or downloads them again |
~/.cargo/git/db and git/checkouts | Git dependency repositories and working checkouts | Usually, if you are online | Cargo fetches and checks them out again |
~/.cargo/bin | Tools installed with cargo install | No—not as cache | Installed commands disappear |
config.toml and credentials.toml | Cargo settings and registry credentials | No | Builds, registries, proxies or authentication may break |
Cargo.toml, Cargo.lock, src | Project definition, dependency lock and source code | No | You damage the project itself |
On Windows, the default Cargo Home is normally %USERPROFILE%\.cargo. If CARGO_HOME is set, use that location instead of the default on any operating system.
Why can the target folder become so large?
Cargo writes build output into the workspace target directory by default. Debug and release profiles use separate subdirectories, and additional target triples create more copies. Incremental compilation also keeps intermediate data so future builds can finish faster.
A workspace that builds desktop binaries, WebAssembly, multiple architectures, or many feature combinations can therefore accumulate much more than its source code size suggests. Cargo's official build-cache documentation treats this output as reproducible build data, but deleting it still has a real cost: the next build starts cold.
On the MangoDisk repository used for this article, target occupied 27 GB. The same Mac had 189 MB in Cargo's compressed registry cache, 1.9 GB of extracted registry sources, and 17 MB in the Cargo Git database. Those are local measurements, not a promise of typical savings. They illustrate why measuring first is better than assuming the global cache is the main problem.
Inspect the real paths before cleaning
From a Rust workspace on macOS or Linux, check the common locations without deleting anything:
cargo_home="${CARGO_HOME:-$HOME/.cargo}"
du -sh target 2>/dev/null
du -sh "$cargo_home/registry/cache" "$cargo_home/registry/src" \
"$cargo_home/git/db" "$cargo_home/git/checkouts" 2>/dev/null
Cargo can be configured to use a different target directory. This command prints workspace metadata, including the actual target_directory value:
cargo metadata --no-deps --format-version 1
In PowerShell, inspect the project and default Cargo Home separately:
$CargoHome = if ($env:CARGO_HOME) { $env:CARGO_HOME } else { Join-Path $HOME ".cargo" }
Get-ChildItem .\target -Recurse -File -Force -ErrorAction SilentlyContinue |
Measure-Object Length -Sum
Get-ChildItem "$CargoHome\registry\cache" -Recurse -File -Force -ErrorAction SilentlyContinue |
Measure-Object Length -Sum
The PowerShell result is reported in bytes. More importantly, both checks force you to confirm the exact directory before cleanup.
How to clean a project target folder safely
First stop cargo build, tests, rust-analyzer work that is actively compiling, and any application running from the workspace. Then preview what Cargo would remove:
cargo clean --dry-run -v
If the scope is correct, remove the complete target directory for the current workspace:
cargo clean
Cargo also supports narrower cleanup when you want to keep useful build data:
# Remove only release-profile artifacts
cargo clean --release
# Remove generated documentation
cargo clean --doc
# Remove artifacts for one package in a workspace
cargo clean -p your-package-name
cargo clean follows Cargo's configured target directory. That is safer than manually assuming ./target, especially in a workspace with a custom target-dir.
After cleanup, the folder returning is normal. The next build recreates it, and the first compile can take substantially longer because incremental artifacts are gone.
When should you clear Cargo's shared cache?
Shared cache cleanup is reasonable in a few situations:
- the measured cache is large enough to matter;
- a downloaded archive or Git dependency is corrupted;
- old toolchains and projects left dependencies you no longer expect to use;
- you need space now and have reliable network access later.
Avoid it before a flight, while working offline, or when an internal registry may be unavailable. Also check whether your organization uses a custom registry, vendored dependencies, or a non-default CARGO_HOME before changing anything.
The official Cargo Home documentation describes registry and Git contents as caches that Cargo can restore by extracting, checking out, or downloading them again. If you decide to remove them manually, quit Cargo-related processes, set the exact Cargo Home first, and inspect it one final time:
cargo_home="${CARGO_HOME:-$HOME/.cargo}"
du -sh "$cargo_home/registry/cache" "$cargo_home/registry/src" \
"$cargo_home/git/db" "$cargo_home/git/checkouts" 2>/dev/null
Then remove only the cache subdirectories you intentionally selected:
rm -rf "$cargo_home/registry/cache" "$cargo_home/registry/src" \
"$cargo_home/git/db" "$cargo_home/git/checkouts"
This command bypasses Trash. It should never be shortened to rm -rf ~/.cargo. Afterward, the next online build may download and extract dependencies again.
On Windows, use File Explorer to review and delete the equivalent cache subfolders under %CARGO_HOME% or %USERPROFILE%\.cargo. Keeping the operation visual makes it less likely that bin, configuration, or credentials are included by mistake.
What should you never delete as Cargo cache?
Do not treat these as cleanup targets:
.cargo/bin, because it contains installed commands such ascargo-auditorcargo-edit;.cargo/credentials.toml, because it can contain registry login tokens;.cargo/config.toml, because it can define registries, aliases, network settings and target behavior;- a project's
Cargo.toml,Cargo.lock,build.rsorsrcdirectory; - vendored dependencies or an organization-managed offline mirror unless its owner has a recovery plan.
If you are unsure whether a directory is a cache, stop at inspection. A directory being under .cargo does not automatically make it disposable.
Review Rust build artifacts with MangoDisk
MangoDisk Deep Cleanup recognizes Rust project target folders and platform-specific Cargo cache locations. The rules do not target the entire .cargo directory, and project build artifacts are not selected by default.
Scanning happens locally. You can review the path and measured size before deciding what to remove, which is useful when several workspaces have their own target directories. See the MangoDisk safety guide for the confirmation and cleanup-history workflow.
Frequently asked questions
Is it safe to delete a Rust target folder?
Yes, if it is the configured Cargo build-output directory and no build is running. It contains reproducible artifacts, not your project source. Expect a slower full rebuild afterward.
Does cargo clean clear the Cargo download cache?
No. cargo clean removes generated artifacts from the target directory. It does not wipe Cargo Home's registry or Git dependency cache.
Can I delete Cargo.lock to save space or fix dependencies?
No. Cargo.lock is small and records the resolved dependency versions. Deleting it is not disk cleanup and may change which dependency versions are selected.
Why did Cargo's cache and target folder come back?
That is expected. Cargo recreates build output and restores missing dependency data as projects build. Cleanup removes old reproducible data; it does not disable caching.
Sources and related reading
- Cargo Book: Build Cache
- Cargo Book: cargo clean
- Cargo Book: Cargo Home
- How to Clear Xcode Derived Data Safely
- Why I Built MangoDisk
Prefer to compare Rust build artifacts and Cargo caches visually before deleting them? Download MangoDisk and review the scan locally.