Where does cargo install put binaries, and how do you list them?

Cargo installs executables into the bin folder of its installation root. The Cargo book says the root comes from the root option, then CARGO_INSTALL_ROOT, then the install.root config value, then CARGO_HOME, and finally $HOME/.cargo. Run cargo install with the list option to see every crate you have installed.

The order matters

The documented precedence, highest first, is:

1. The root option on the command line.
2. The CARGO_INSTALL_ROOT environment variable.
3. The install.root value in Cargo config.
4. The CARGO_HOME environment variable.
5. $HOME/.cargo.

Most people never set any of these and end up in $HOME/.cargo, so binaries land in the bin folder inside it. If you work in a team that sets a variable in a shared profile, your binaries may be elsewhere. Check the environment before you assume.

What the command manages

The documentation describes cargo install as managing Cargo's local set of installed binary crates. Only packages with executable bin or example targets can be installed, and by default only binaries, not examples, are installed. The default source is crates.io, and flags for git, path and registry change the source.

That last point has a safety angle. A crate installed from a git URL or a local path is not the same as one from the registry. Our post on cargo deny sources explains the control for project dependencies. For tools on your laptop, the list output may show where non-registry installs came from on your Cargo version, so check it.

Repeatable installs

The docs describe the locked option as forcing Cargo to use the packaged Cargo.lock file if one exists. It is useful for reproducing the exact dependencies available when the package was published, and for cases where a newer dependency release breaks a build. We cover the trade-offs in what cargo install locked changes.

A review routine

cargo install --list

1. Read the list and delete crates you no longer use.
2. For each one you keep, note why you have it.
3. Look for git or path installs in the output, and decide whether you trust each source.
4. Reinstall tools you rely on deliberately, with a pinned version, rather than leaving old binaries around.
5. Add the result to your laptop tool inventory.

Common surprises

Two things catch people out. First, an old binary keeps working after the project that needed it is gone, so the list grows without anyone choosing that. Second, reinstalling a crate replaces the binary in place, so the version you ran last month may not be the version you run now. If a build once worked and now fails, the tool version is a good first suspect.

For a team, agree a single install root so everyone looks in the same place, and say so in the onboarding notes. When two people debug the same problem with different binaries in different folders, hours are lost.

Why this is worth ten minutes

A Rust tool in your bin folder runs as you, on demand, from any directory on your PATH. It is not in a project lockfile and no scanner will see it. If one of those crates is later reported as compromised, a recent list is how you find out whether you were exposed.

Quick check

Sources

• Cargo install documentation

Last reviewed: 19 October 2026.