What does cargo:install_binary_conflict mean?

Cargo refused to overwrite a binary already owned in the selected install root, which may be the same crate, an older version, or a different package.

How can I manually validate cargo:install_binary_conflict?

Run `cargo install --list` as the same user to identify the package and version that Cargo records as the binary owner. Inspect `CARGO_INSTALL_ROOT`, `install.root`, and `CARGO_HOME` to find the destination used by the failing command. Use `command -v ` and inspect that resolved path so another system package or shell path does not get confused with the Cargo destination. In CI, check whether multiple jobs restore or write the same shared install root instead of using job-scoped tool directories.

Cargo error: binary <name> already exists in destination

Q: How do I prevent cargo:install_binary_conflict in CI?

Use isolated install roots for CI jobs and disposable build images. Pin tool versions and skip installation when the required version is already present. Avoid treating a mutable Cargo install directory as a general shared cache across projects.

Fix it fast

Most likely: The destination binary is already owned by the same crate, an older release, or another installed package.

Confirm this is your error

Match the output and confirm you are troubleshooting the same failure.

error: binary `cargo-example` already exists in destination as part of `cargo-example v1.2.0`
Add --force to overwrite
error: binary `tool` already exists in destination as part of `other-tool v3.0.0`
Add --force to overwrite

Check the cause

Run focused checks to identify what is failing in this environment.

cargo install --list
command -v <binary>
<binary> --version
grep -nE "^root[[:space:]]*=" .cargo/config.toml "${CARGO_HOME:-$HOME/.cargo}/config.toml" 2>/dev/null

Apply the safe fix

Use the smallest safe change that addresses the confirmed cause.

# Only for a confirmed same-package replacement
cargo install --force <crate>

# For CI isolation
cargo install --root "$PWD/.cargo-tools" <crate>

Verify it works

Repeat the relevant checks and confirm the original error is gone.

cargo install --list
<binary> --version

Avoid unsafe shortcuts

Keep security and data protections in place while troubleshooting.

Do not use --force before confirming which package owns the binary.
Do not share one writable install root across unrelated CI jobs.

What Local Operation Failed

The remote service may be fine. This class of error is usually about what the local machine was allowed to read, write, cache, or execute.

Fix the local path, cache, or permissions

Treat this like a local host problem first. Ownership, free space, read-only mounts, and stale caches explain more of these failures than upstream service issues do.

Same package already installed:skip the install or use the existing binary after verifying its version.

Intentional same-package upgrade:use cargo install --force <crate> only after confirming every reported binary belongs to that crate.

Different-package collision:choose a separate --root, remove the unwanted package with cargo uninstall, or invoke one tool without placing both in the same binary directory.

Shared CI state:assign a job-scoped install root and avoid restoring mutable install metadata across unrelated jobs.

Untracked file:preserve it, identify how it was installed, and remove or relocate it through its owning package manager rather than letting Cargo overwrite blindly.

Identify the binary owner and install root

Run cargo install --list as the same user to identify the package and version that Cargo records as the binary owner.

Inspect CARGO_INSTALL_ROOT, install.root, and CARGO_HOME to find the destination used by the failing command.

Use command -v <binary> and inspect that resolved path so another system package or shell path does not get confused with the Cargo destination.

In CI, check whether multiple jobs restore or write the same shared install root instead of using job-scoped tool directories.

Why the Local Machine Blocked It

The same crate version is already installed and the repeated install is unnecessary.

An older version owns the binary and the command is effectively an upgrade that requires deliberate replacement.

A different crate publishes the same binary name, creating a real ownership collision.

A reused CI cache or shared install root contains state from another job or user.

Verify the Local Path Is Usable Again

Run cargo install --list, execute <binary> --version, and confirm the destination now belongs to the intended package.

Repeat the install command without --force. A clean already-installed result or no collision confirms install metadata and ownership are consistent.

How Cargo tracks installed binaries

This is the part worth understanding if the quick fix did not hold. It explains what Cargo is trying to do at the moment the error appears.

cargo install writes binaries into an install root and records ownership metadata. Before copying a new binary, Cargo checks whether that destination name is already managed by another installed package.

--force permits replacement, but it is safe only after confirming the current owner and deciding that every colliding binary should be overwritten.

Prevent Local State Drift

To prevent this, use isolated install roots for CI jobs and disposable build images, pin tool versions and skip installation when the required version is already present, and avoid treating a mutable Cargo install directory as a general shared cache across projects.

Docs and source code

cargo install

Official install-root, force, lockfile, registry, and git installation behavior. - Source

This command manages Cargo's local set of installed binary crates.

Cargo Configuration

Official reference for registry, proxy, network, credential, and install settings. - Source

Cargo allows local configuration for a particular package as well as global configuration.