Leave pnpm's default in place, which does not run postinstall scripts in dependencies, and list the few packages that genuinely need a build in the allowBuilds setting. Avoid the setting that allows all builds. Then a package that never needed a script cannot start running one when a compromised version is published.
The default and the reason for it
The pnpm guidance on mitigating supply chain attacks states that historically most compromised packages have used postinstall scripts to run code immediately upon installation. To mitigate this, pnpm v10 disables automatic execution of postinstall scripts in dependencies.
There is a setting to turn them back on globally, named dangerouslyAllowAllBuilds. The word in the name is deliberate. The documentation recommends listing only trusted dependencies in allowBuilds instead.
Why an allowlist beats a global switch
Consider a package that has never run a script. With scripts globally on, a malicious update can add one and it runs at once. With an allowlist, the update does nothing at install time, because the package is not on the list.
The documentation adds a sensible warning: even for a trusted package that has a postinstall script, be cautious when updating it, because it might get compromised.
A workflow for laptops
- Install normally. Packages that need a build will report that scripts were skipped.
- For each one, ask three questions. What does the script do? Is this package from a maintainer you recognize? Is the version one you have reason to trust?
- Add only the packages that pass to the allow list, in the workspace configuration file that pnpm reads.
- Commit the list so teammates and CI agree.
- When bumping an allowed package, read the changelog and the script diff.
Native modules and binaries
Typical packages that need builds are those that compile native code or download a prebuilt binary. The list is usually short in a real project. If yours is long, that is information too: a large allow list is a large trust surface, and it may be worth replacing a few dependencies.
Pair it with strict build checks
The pnpm settings index also lists a strictDepBuilds option. Read its description for your version before relying on it, since behavior can change between releases. The idea is to make unreviewed builds a visible failure instead of a quiet skip.
What this setting does not do
Skipping scripts at install time does not stop code that runs when your app imports the package. It reduces one common path to your laptop. It does not replace review of new dependencies or a scan of what you installed.
If you want a quick look at what your projects actually resolve, Safeguard offers SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Quick check
Does pnpm 10 run dependency postinstall scripts by default?
No. The pnpm documentation says v10 disables automatic execution of postinstall scripts in dependencies.
Why not just allow all builds?
Because a compromised update to a package that never had a script could then run code at install. The pnpm guidance recommends listing only trusted dependencies.
Sources
Last reviewed: 19 October 2026.
