Run cargo tree with the invert option and the crate name. It flips the dependency tree and lists every package that depends on the flagged crate, so you can see which parent to upgrade. Add the duplicates option to find crates built in more than one version.
Why the inverted view matters
A normal dependency tree starts at your project and fans out. When a scanner flags a crate three levels down, that view makes you hunt. The inverted view starts at the flagged crate and walks upward to your project, which is the path you need: the chain of parents that decide which version you get.
The Cargo Book describes the invert option as showing the reverse dependencies for the given package. It adds a detail for workspaces: by default the view covers only the reverse dependencies inside the tree of the workspace member in the current directory. The workspace option extends it across the entire workspace, and the package option limits it to the subtree of one package.
Commands
# who depends on the flagged crate
cargo tree -i flaggedcrate
# across the whole workspace
cargo tree -i flaggedcrate --workspace
# crates that appear in more than one version
cargo tree -d
The documentation's own example is the same pattern: show all packages that depend on the syn package with the invert option. It also notes that the duplicates option shows only dependencies that come in multiple versions and implies invert. That can happen when semver-incompatible versions, like 1.0.0 and 2.0.0, appear in the tree.
Reading the result
| What you see | What it means | Next step |
|---|---|---|
| One parent, one version | Single path | Update that parent or the crate |
| Several parents | Shared dependency | Check which one caps the version |
| Two versions listed by the duplicates option | One path still uses the old version | Update the parent on the old line |
| Only a dev dependency edge | Not in the shipped build | Lower urgency, still fix on schedule |
The edges option lets you filter by dependency kind. The default is normal, build and dev. If the only path to the flagged crate is a dev dependency, it may not ship in your binary, though build scripts and tests still run on your machines.
A short decision rule
- If the first fixed version is allowed by the ranges in the tree, run a conservative update of that crate.
- If a parent caps it, upgrade the parent and check its changelog.
- If the parent is abandoned, consider a patch or replacement. See the guide on when to fork an abandoned dependency.
- If nothing in your code reaches the crate, record that decision and still schedule the upgrade.
Be careful with the feature note in the docs: cargo tree shows a graph close to the feature-unified graph Cargo builds, not just what you list in Cargo.toml, and it does not guarantee exact equivalence with a real build. Treat it as a strong guide and confirm with a build and a rescan.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the full list of findings with the ones your code actually reaches.
Where Safeguard fits
Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.
Quick check
What does the invert option do?
It shows reverse dependencies: the packages that depend on the crate you name.
How do I see crates built in two versions?
Use the duplicates option. It shows only dependencies that come in multiple versions.
Sources
Last reviewed: 19 October 2026.
