Only trusted jobs should write the pnpm store and metadata cache. The pnpm documentation warns not to let untrusted CI jobs write to a store or cache that trusted jobs later restore. In practice that means pull request jobs from forks may read a cache at most, and release jobs should not restore anything a fork could have changed.
Why caches matter in a migration
Moving to pnpm usually comes with new cache configuration, because the old npm cache directory no longer applies. People copy a workflow snippet that caches the store keyed on the lockfile, and move on. The pnpm CI documentation notes that in its examples the store is cached, but that this is not required, and it is not guaranteed that caching makes installs faster. It also says you can choose not to cache.
The security warning in the same page is the part to keep: cache directories are trusted caches. If an untrusted job can write a poisoned package into the store, a later trusted job that restores that cache can install it.
What is in the cache
| Directory | What it holds |
|---|---|
| Store | Package contents shared across projects |
| Metadata cache | Registry metadata and, per the docs, the lockfile verification log |
The documentation says the verification log lets a job skip re-checking an unchanged lockfile against configured supply chain policies. That is a speed benefit, and also a reason to protect the cache: it records a verification result that later jobs rely on.
Rules to adopt
- Separate cache keys by trust level. Fork pull request jobs use no cache or a read only one.
- Let only protected branch builds save a cache.
- Never restore a cache written by a pull request job in a job that has secrets or publishes.
- Include the lockfile hash and the OS in the key so changes invalidate it.
- Consider skipping the cache for release builds, and accept slower installs.
- Keep a periodic clean build with no cache to prove the lockfile still installs from scratch.
Platform specifics
Most CI platforms have a cache scoping rule of their own, for example caches shared across branches. Read it. See Bitbucket Pipelines cache shared across branches for one case, and GitLab fork merge request pipelines and secret safety for the fork side.
Verify after a cache restore
A frozen install checks the lockfile, including integrity values. See what the npm lockfile integrity field protects for the npm equivalent. A frozen install is your second line of defense, not your first, so do not let it excuse a shared writable cache.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate on the pull request blocks risky changes before merge, which complements careful cache scoping.
Safeguard's policies and gates can enforce checks on dependency changes. A free scan is at gold.safeguard.sh/scan.
Quick check
Do I need to cache the pnpm store?
No. The pnpm docs say caching is not required and is not guaranteed to speed things up. Skipping it removes the risk.
Can a fork pull request restore the cache?
Reading a cache written by a trusted branch is lower risk than writing one. Never let a fork write a cache that trusted jobs restore.
Sources
Last reviewed: 19 October 2026.
