The locked flag asserts that Cargo uses exactly the dependencies and versions recorded in the existing Cargo.lock. If the lock file is missing, or Cargo would need to change it, the build stops with an error. Use it whenever you want to build what was reviewed rather than what resolves today.
What the documentation says
The Cargo build reference describes locked as asserting that the exact same dependencies and versions are used as when the existing Cargo.lock was originally generated. Cargo exits with an error in two cases: the lock file is missing, or Cargo attempted to change the lock file because of a different dependency resolution.
The frozen flag is equivalent to specifying both locked and offline. The offline part stops Cargo from touching the network, so the build can only use what is already available locally.
Why it matters for your laptop
By default, Cargo will update the lock file when the manifest changes or when the lock is absent. That is helpful while developing and a risk while evaluating someone else's project. If you clone a repository that lacks a committed lock file, a default build resolves the newest allowed versions at that moment, and you run their build scripts on your machine as a side effect.
Build scripts are ordinary programs that run during compilation. That makes the dependency set a code execution surface, not only a source of library code.
When to use which flag
- Reviewing a pull request that touches dependencies: use locked, so an accidental lock change shows up as a failure you can look at.
- Building a release artifact: use locked, so the build matches the committed lock file.
- Working offline or from a vendored cache: use frozen.
- Adding a dependency on purpose: run without the flag, then read the lock file diff before committing.
A short review habit
When the lock file changes in a diff, check three things. Which crates were added? Did any existing version jump further than expected? Does a new crate have a build script or a proc macro, which run at compile time?
Teams that treat the lock file as reviewed code, with the same attention as source, catch most surprises at that point.
Libraries versus applications
The convention many projects follow is to commit the lock file for applications and binaries, where reproducibility is the goal. Libraries differ in practice, so check what a given project does before assuming. If a project you depend on omits a lock file, your own lock file is what protects you, so commit yours.
What locked does not cover
Pinning protects against drift. It does not protect against a pinned version that was already malicious or vulnerable. Pair it with advisory scanning and a human look at new crates.
If you want a quick look at what your projects actually resolve, Safeguard offers SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Quick check
What is the difference between locked and frozen?
Per the Cargo documentation, frozen is equivalent to locked plus offline, so no network access is used.
Does locked make a build safe?
No. It ensures the versions match the lock file. The pinned versions themselves still need review and scanning.
Sources
Last reviewed: 19 October 2026.
