npm v12 Will Stop Running Install Scripts By Default So Prepare Your CI

npm Is About To Stop Trusting Install Scripts

On June 9, 2026, GitHub published a changelog announcing breaking changes for npm v12, estimated to ship in July 2026. The headline change is the one that has been a long time coming: npm will no longer run a dependency's lifecycle scripts automatically when you install it.

For years, running npm install has quietly executed arbitrary code from your dependencies through preinstall, install, and postinstall scripts. That single behavior is the number one reason supply-chain attacks on npm work: compromise a package, add a malicious postinstall, and every npm install in every developer machine and CI pipeline runs your code. npm v12 closes that default. It is the right move, and it will also break some builds, so the time to prepare is now, before July.

What Actually Changes In npm v12

Per GitHub's changelog, in npm v12:

• preinstall, install, postinstall and prepare scripts from dependencies will not run by default. You opt them back in per package through an allowlist.
• Native node-gyp builds are blocked too. A package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild. That catches a large slice of native modules.
• prepare scripts from git, file, and link dependencies are blocked the same way.
• Git dependencies are blocked unless explicitly allowed with --allow-git (available since npm 11.10.0). This also closes a code-execution path where a Git dependency's .npmrc could override the Git executable even with --ignore-scripts.
• Remote URL and tarball dependencies are blocked unless allowed with --allow-remote (available since npm 11.15.0).

The approval mechanism is an allowlist written into your package.json and committed to your repo, so your team and your CI share one source of truth about which packages are trusted to run code.

Why This Is Happening

GitHub ties the change to the wave of npm supply-chain attacks, including the self-replicating Shai-Hulud campaigns and a string of package hijacks. Malicious lifecycle scripts have been the common thread in nearly all of them. Turning off automatic script execution removes the easiest path attackers have to get code running the moment a poisoned package lands in your tree. It is the same hardening direction as npm's earlier publishing-side controls, which we covered in our note on the npm staged publishing approval gate, but this one protects the consumer side of the ecosystem.

What Will Break In Your CI

This is where teams need to pay attention, because npm install runs constantly in CI. The honest triage:

• Pure-JavaScript dependencies are unaffected. Most of your tree has no install scripts and will keep working exactly as before.
• Native modules will break until approved. Anything that compiles on install through node-gyp (database drivers, image and crypto libraries, some headless-browser tooling) will not build unless you allow it.
• Tools that rely on postinstall will break. Git-hook managers, certain CLIs that download binaries, and build tooling that wires itself up in postinstall will silently stop doing that work until allowed.
• Git and URL dependencies will fail to resolve unless you add --allow-git or --allow-remote.

A build that depended on any of these and is not pre-approved will not error in an obvious "blocked a script" way as much as it will break later, when the thing the script was supposed to set up is simply missing. That is exactly why you want to surface and fix this before v12 forces it.

How To Prepare Before July

GitHub's migration path, and the one we would run for a client, is straightforward:

1. Upgrade to npm 11.16.0 or later now. This version warns you about scripts without yet blocking them.
2. Run a normal install and read the warnings. They tell you which packages in your tree have lifecycle scripts.
3. Surface them with npm approve-scripts --allow-scripts-pending, then allow the ones you actually trust and need with npm approve-scripts, and block the rest with npm deny-scripts.
4. Commit the allowlist in package.json so every developer and every CI runner uses the same trusted set.
5. Test your pipeline with scripts blocked before v12 lands, so any missing native build or postinstall step shows up on your schedule, not in a failed production deploy in July.
6. Audit your git and URL dependencies. Where you genuinely need them, add --allow-git or --allow-remote. Where you do not, this is a good prompt to remove them.

The Bigger Picture

This is the JavaScript ecosystem finally closing a default-trust hole that should never have been open. There will be short-term friction, a few broken builds, and a one-time audit of every package that wants to run code on your machines. That audit is the point. After it, you have an explicit, committed record of exactly which dependencies are trusted to execute code in your pipeline, which is a far stronger position than "all of them, automatically."

Getting a fleet of pipelines ready for this kind of change without breaking deploys is the day-to-day of our CI/CD pipeline and DevOps as a service work. If your builds lean on native modules or postinstall tooling, the cheap move is to run the npm 11.16.0 audit now rather than meet it as a surprise in July.

Sources

The facts above are drawn from GitHub's official changelog "Upcoming breaking changes for npm v12" (published June 9, 2026). Version numbers, the allowlist commands, and the July 2026 estimate are quoted from that announcement; confirm the exact release date against the changelog as v12 nears.