Usually yes for tools in CI. By default cargo install ignores the lockfile packaged with a crate and resolves fresh versions. The locked flag makes it use the packaged Cargo.lock, so you build the dependency versions the author tested. The trade-off is that you do not pick up dependency fixes.
What the default does
Without the locked flag, Cargo recomputes dependency versions, which can pick up releases published after the crate itself. The Cargo documentation warns that this may fail to build or cause other problems. It also means two installs of the same tool version on different days can contain different dependencies.
What the locked flag does
cargo install --locked tool_name
Cargo uses the lockfile packaged with the crate. It errors if the lock is missing or would need to change. Cargo began publishing lockfiles in version 1.37, so older crate releases have none.
The trade-off
| Choice | You get | You give up |
|---|---|---|
| Locked | Reproducible, tested dependency set | Fixes to dependencies released after the tool |
| Unlocked | Latest compatible dependencies | Repeatability, possible build breaks |
For a CI tool such as a linter or scanner, repeatability usually wins, because a surprise dependency can break the pipeline or add an unreviewed update to your toolchain. But a locked install can freeze a vulnerable dependency inside the tool, so pair it with a routine to bump the tool version.
Steps for a controlled tool install
- Pin the tool version explicitly in your install command.
- Add the locked flag.
- Install into a known root so you can cache and inspect it. The root follows a documented order: the root option, an environment variable, config, then the default under your home directory.
- Record the tool version in your build logs.
- Schedule a review to bump the tool version, and read its release notes.
Where else the lockfile matters
The same reasoning applies to your own projects. In CI, the locked flag on build and test commands fails the job if the lockfile would change, which catches a dependency edit that forgot to commit the lock. The frozen flag adds offline mode on top.
Consider where the binary comes from
A crate installed from source runs its build scripts and compiles dependency code on the machine doing the install. That is a trust decision. Review what you install and prefer a pinned version over the latest.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request check reports a failing rule.
Quick check
Does locked mean the dependencies are safe?
No. It means they match what the author tested. They may include known vulnerabilities, so keep scanning.
What if the crate has no Cargo.lock?
With the locked flag the install fails, since the lock is missing.
Safeguard policies and gates can enforce checks in pull requests, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
