Unity's Package Manager compares a package name with the scopes of each scoped registry in your project and uses the closest match. If nothing matches, the package comes from the default registry. That rule decides where code enters your game, so it is worth understanding before you add a registry.
What a scoped registry is
A scoped registry tells Package Manager where a custom package server lives. Unity describes organizations using them to distribute custom packages internally. You add them to the scopedRegistries array in Packages/manifest.json. Each entry has three fields:
| Field | Meaning |
|---|---|
| name | The label shown in the Package Manager window |
| url | An npm compatible registry server |
| scopes | Exact package names or namespaces such as com.example |
The Unity documentation adds that not every registry provider works, because the server must implement the /-/v1/search or /-/all endpoint. Wildcards and glob patterns are not supported, and Unity does not support npm's @scope notation.
How the closest match works
Here is the documentation's own example, restated. A General registry has the scopes com.example and com.example.tools.physics. A Tools registry has com.example.mycompany.tools.
com.example.animationcomes from General, matching thecom.examplenamespace.com.example.mycompany.tools.animationcomes from Tools, because that scope is a closer match thancom.example.com.unity.animationmatches nothing, so it comes from the default registry.
The lesson: a longer, more specific scope wins. A broad scope such as com.example claims every package under that namespace, including ones you did not know existed.
Why this is a supply chain question
The Unity page says to install scoped registries only from trusted sources, because the packages in them can contain executable code. It also warns about registries that might collect data without appropriate controls and third parties that falsely claim Unity's approval.
Because a broad scope claims a namespace, a registry you add could become the source for packages you assumed came from elsewhere. That is the same shape as dependency confusion in other ecosystems, so treat each new scope as a trust decision.
A pre-add checklist
- Who runs the registry, and who can publish to it?
- Is each scope as narrow as it can be?
- Does the namespace overlap with a package you already use?
- Is authentication configured, as Unity describes, in the Package Manager user configuration file?
- In a shared project, did the team review the change? Unity warns you when another user adds a new scoped registry.
Try it yourself
Open the inventory demo and look at how each component is listed with its source. Ask the same question of your manifest: for every package, can you name where it came from?
Click through it at your own pace, or open it full screen.
Quick check
Can a scope use a wildcard?
No. The documentation says wildcards and glob patterns are not supported. Scopes are exact package names or namespaces.
Do scoped registry packages run code?
They can. The documentation says packages in those registries can contain executable code, which is why the source matters.
Safeguard's SBOM and dependency scanning can list the packages a project resolves, so a surprise source shows up. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
