pnpm does not run dependency build scripts (preinstall, install, postinstall) until you approve the package. That is a security feature: it stops a newly added or hijacked dependency from running code on install. Approve packages by name after reviewing why they need a build, and avoid the allow all setting.
What you will see
When a dependency has build scripts that nobody has approved, pnpm reports them. With strictDepBuilds enabled, the install exits with a non-zero code. The pnpm settings reference says this setting defaults to true and was added in version 10.3.0. With it disabled, pnpm prints a warning instead.
This catches people the first time a CI job turns red after adding a package with a native build step.
How to approve
The approval list has changed names across versions. The pnpm documentation says the older onlyBuiltDependencies and ignoredBuiltDependencies settings were removed in pnpm 11 and replaced by allowBuilds, where each package is set to true to allow or false to deny. Check your pnpm version, then follow its documentation for the exact syntax.
The approval decision itself is the same on any version:
- Find out why the package needs a script. Common reasons are compiling a native add-on or downloading a platform binary.
- Read the script. It is in the package's package.json. Does it do only what the reason says?
- Check the package. Is it the one you meant, and is it maintained? See how to check an npm package before you install it.
- Approve by exact name. Commit the approval so the whole team and CI agree.
- Deny the rest explicitly, so the warning stops and the decision is recorded.
What not to do
The dangerouslyAllowAllBuilds setting, added in version 10.9.0 and false by default, lets all dependency build scripts run without approval. The documentation warns that this includes future and transitive dependencies. That undoes the control. Use it only in a throwaway environment you would be happy to lose.
Related setting
The ignoreScripts setting, false by default, tells pnpm not to run scripts in your project or its dependencies. The documentation notes it does not stop .pnpmfile.mjs from executing, so remember that your own pnpmfile is also code that runs at install. Review changes to it like any other code.
Make the approval list reviewable
Treat the approval list as a security file. Changes to it should need a reviewer, since adding a name there grants code execution at install. A pull request gate can flag edits to that list automatically.
Quick check
Why did a package I trust get blocked?
Blocking is about the script, not trust in the package. Even good packages run scripts at install. Approve it by name once you have reviewed why.
Is approval permanent?
It lasts until you remove it. Version upgrades can change what a script does, so review the script again on major updates.
Safeguard policies and gates can flag changes to dependency approval files in a pull request. Try a free scan to see your tree.
Sources
Last reviewed: 19 October 2026.
