Unity can install only one version of a package at a time, so it builds a dependency graph and, when another package needs a higher version, installs that one instead of the version you picked. The lock file then records the result. Check the information message in the package details to see why.
What the documentation says
Unity's Package Manager documentation explains that a dependency you add in manifest.json is a direct dependency, written as the package name at a version. Packages can also require other packages, which Unity calls indirect or transitive dependencies. Those are declared in the package's own package.json.
The page gives an example: a project requested version 4.0.3 of XR Plugin Management, but the Package Manager installed 4.0.6 because another package depended on the higher version. An information message in the package details explains why.
Because it can install only one version of a package, the Package Manager builds a dependency graph of every direct and indirect dependency to decide which version to install.
Why this matters for security
If you pin a version because you reviewed it, an indirect dependency can change what is actually used. The pin in your manifest might be a floor rather than the final answer. Reviewers who read only manifest.json will miss that.
The reverse is also true. If a vulnerable version is the only one in your manifest, a transitive requirement might lift it and fix the issue without you noticing. Either way, the resolved version is the one to inventory.
What to read
- Read the lock file, not only the manifest. Unity says that after resolving conflicts the Package Manager saves the resolution in a lock file, for determinism so that the same packages install every time, and for efficiency.
- Compare the manifest version with the lock version for each direct dependency. Flag differences.
- For indirect packages, note which direct package requires them.
- Feed the lock file contents to your inventory or scan, not the manifest alone.
- Commit both files together and review lock file changes in pull requests.
For pin habits in the manifest itself, see what to pin in manifest.json, and for where each package comes from, how Unity chooses a registry.
A habit that pays off
When an advisory lands, search the lock file for the package name. It tells you the exact version resolved in the build, which answers the first question every response starts with: are we affected?
Try it yourself
Click through it at your own pace, or open it full screen.
Look for direct and indirect components in the demo and note that both appear with resolved versions.
Quick check
Is the version in manifest.json always the installed version?
No. Unity's documentation shows a case where another package needed a higher version, so the higher one was installed.
Which file records the final resolution?
The lock file, which Unity says records the resolved packages for determinism.
Sources
Last reviewed: 19 October 2026.
