It's the morning of April 29, 2026. I've been chasing disk hogs with dumap for a while wondering where the hell my disk space keeps disappearing. Docker volumes? node_modules? Old Xcode runtimes? 

But every time I checked back a few weeks later, I was short again. Something was leaking, and I had a hunch I knew where.

The problem

Cargo's target/ directories.

Years of SaaS work, projects, prototypes, CLI tools, every random cargo new I'd ever run. Each one with its own multi-gigabyte cache (deps/, build/, incremental/, .fingerprint/), never cleaned up. Spread across ~/www and ~/labs — too scattered for any single cargo clean to catch.

The naive fix is to delete every target/ whole. But then I'd lose yesterday's release/ build that I might still want to run (like some MCP that I wrote and use locally). I wanted the cache gone, not the binaries.

What about cargo clean? It's too aggressive, cargo clean wipes a project entirely.

That was a hard No for me. So I sat down and wrote it.

The solution

A Cargo subcommand that walks any directory, finds every target/ it can prove is one (CACHEDIR.TAG or .rustc_info.json, the markers Cargo itself drops), and removes only the cache subtrees. The compiled binaries (release/myapp, debug/myapp, examples, dylibs, rlibs, wasm) stay put.

First run on my laptop:

done: 127 target dir(s), 4199 path(s) removed, 773.17 GiB freed

773 GiB. I re-read that line three times. Almost a full terabyte across 127 target dirs, accumulated without me ever noticing. That's a LOT for a 2 To drive!!

If I had this much sitting on my disk, I can't be the only one. So I open-sourced it the same morning.

How it works

A single src/main.rs. No dependencies beyond std. ~600 lines.

The detection rule is the only thing that really matters: a directory is treated as a Cargo target only if it contains CACHEDIR.TAG or .rustc_info.json. A folder named target/ that isn't actually one (some random project's data dir, whatever) is left alone.

Inside each profile (debug/, release/, custom):

Target-triple wrappers (x86_64-apple-darwin/, aarch64-unknown-linux-gnu/, …) get descended into and each profile inside is cleaned the same way.

Try it

cargo install cargo-clean-targets

# preview first
cargo clean-targets --dry ~/code

# do it
cargo clean-targets ~/code

Or via Homebrew:

brew tap FGRibreau/tap
brew install cargo-clean-targets

Or cargo binstall for a prebuilt binary (no compile):

cargo binstall cargo-clean-targets

The dry-run output tells you exactly what it's about to do:

target: /Users/me/code/myproj/target
  would rm dir  /Users/me/code/myproj/target/release/.fingerprint  (12.04 MiB)
  would rm dir  /Users/me/code/myproj/target/release/incremental   (48.21 MiB)
  would rm dir  /Users/me/code/myproj/target/release/deps          (612.80 MiB)
  would rm dir  /Users/me/code/myproj/target/release/build         (4.10 MiB)

done: 1 target dir(s), 5 path(s) removed, 677.82 MiB freed (dry)

What's next

• An age filter (only clean targets untouched for >N days), to preserve hot projects
• A --keep-doc flag for folks who actually use cargo doc output
• A reporting mode that shows per-project savings before touching anything

Open to other ideas. The whole tool is one file. Easy to hack on.

Run it tonight

Seriously. Run it on your dev machine with --dry and tell me what number comes back. I'm curious whether 773 GiB is an outlier or whether half of us are walking around with terabytes of dead Rust caches.

Star it if you find it useful. Report bugs. Send PRs.

github.com/FGRibreau/cargo-clean-targets

Some context

You just tried to compile your Rust project and got the there is no timer running, must be called from the context of Tokio runtime error?

You are desesperatly trying to understand what is going on?

So did I!

For future reference, my project relied on tokio v0.3. I added a dependency (bollard) that was relying on tokio v0.2.

Even when my code was in the execution context of a tokio runtime (v0.3) calling bollard code triggered at runtime the there is no timer running, must be called from the context of Tokio runtime error.

How do I fix this?

Option 1: start a new runtime in tokio v0.2

Your first option would be to start another runtime in the same tokio version that your dependency requires, something like:

use tokio::runtime::Runtime;

// Create the runtime
let rt = Runtime::new().unwrap();

// Spawn a future onto the runtime
rt.block_on(async {
    // call your dependency
});

That would result in two threadpools so it might be an issue in some case. I did not go down this path

Option 2: use the same version that your dependency

It's the easiest option. Downgrade your tokio project dependency to v0.2 so it can be the same as your dependency. But yep, it sucks.

Option 3: send a patch to the dependency

Last option (and the best one) is to create and send a patch to your dependency project to upgrade its tokio version.

I had this weird cargo error while trying to publish a new Mailchecker rust crate version and could not find anything on Google about.

Updating registry `https://github.com/rust-lang/crates.io-index`
error: failed to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  invalid pack file - invalid packfile type in header; class=Odb (9)

rm -rf ~/.cargo/registry