Preparing for npm v12: install scripts and non-registry sources become opt-in

[leobalter]

Hi everyone — sharing this so maintainers, application developers, and CI operators have time to prepare for behavioral changes landing in npm v12 (estimated July 2026). Everything below is already available in npm 11.16.0 so you can migrate today.

What is changing in v12

Three npm install defaults change, each closing an automatic code-execution or code-fetch path:

1. Install scripts are off by default. preinstall, install, and postinstall from dependencies won't run unless explicitly allowed.
2. --allow-git defaults to none. Git dependencies (direct or transitive) won't resolve unless allowed. Available since npm 11.10.0; previously announced Feb 2026.
3. --allow-remote defaults to none. Remote URL dependencies (e.g. https tarballs) won't resolve unless allowed. Available since npm 11.15.0.

--allow-file and --allow-directory exist too, but their defaults are not changing in v12.

Most of this post focuses on install scripts, since that's the migration with the most moving parts.

Why install scripts

Install-time lifecycle scripts are the single largest code-execution surface in the npm ecosystem. Every npm install runs scripts from every transitive dependency, so a single compromised package anywhere in your tree can execute arbitrary code on a developer machine or CI runner. Making script execution opt-in closes that path while keeping it one command away for the packages you trust.

The commands

• npm approve-scripts — allow scripts for specific dependencies. Writes the allowlist to your package.json.
• npm deny-scripts — explicitly block scripts for a dependency (survives --all and future review prompts).
• npm approve-scripts --allow-scripts-pending — read-only: lists every package whose scripts aren't yet covered, without changing anything.
• allow-scripts config / --allow-scripts=<pkg,...> — the mechanism for global installs and npx (see below).
• strict-allow-scripts config / --strict-allow-scripts — opt into the v12 enforcing behavior today (see "Try the breaking behavior now").

By default, npm approve-scripts <pkg> pins the approval to the installed version (pkg@1.2.3). Use --no-allow-scripts-pin if you'd rather allow any future version by name.

Recommended first step: allow what you already have

If you're adopting this on an existing project, the fastest safe migration is to allow everything currently in your tree first, then tighten later — rather than agonizing over each package and delaying rollout:

npm install                      # warns about packages with skipped scripts
npm approve-scripts --allow-scripts-pending   # review the list
npm approve-scripts --all        # approve everything currently pending
git add package.json && git commit -m "chore: snapshot current install-script allowlist"

This gets you protected against new, unexpected scripts immediately. You can then npm deny-scripts anything you don't actually need.

"If you have X, do Y" — migration recipes

Native modules (anything built on node-gyp)

Includes sharp, better-sqlite3, canvas, bcrypt, node-sass, bufferutil, utf-8-validate, and many DB drivers. Note: these are blocked even if they have no explicit install script, because npm runs an implicit node-gyp rebuild for any package with a binding.gyp.

npm approve-scripts        # approve node-gyp + the native packages you use

Cypress, Playwright, or Puppeteer

These download browser/runtime binaries via postinstall.

npm approve-scripts        # approve: cypress / playwright / @playwright/browser-* / puppeteer

Or control downloads yourself with each tool's explicit command (npx playwright install, npx cypress install) after npm install.

Electron

npm approve-scripts        # approve: electron

Husky (git hooks)

npm approve-scripts        # approve: husky

Or move husky setup into an explicit prepare script you invoke during bootstrap.

CI pipelines

1. Upgrade your CI image to npm 11.16.0+.
2. Run your install and check logs for skipped-script warnings.
3. Commit the allowlist from npm approve-scripts so installs are reproducible.
4. Consider --strict-allow-scripts so CI fails loudly on anything unreviewed (see below).

Publishing a package that needs install scripts

Your downstream users won't run your scripts by default in v12. Two things help:

1. Document it — add a note to your README and link npm approve-scripts.
2. Reduce the need — ship prebuilt binaries (prebuild, prebuildify, node-pre-gyp) or move setup into an explicit command users run after install.

If your package has high download volume or many dependents, the npm team may reach out to coordinate — or reach out to us first (see "How to get help").

Try the breaking behavior now

In v11 the default is a warning — scripts still run. If you want the actual v12 behavior today (unreviewed scripts cause a hard failure instead of being skipped), set:

# .npmrc
strict-allow-scripts=true

or pass --strict-allow-scripts on the command line. This is the recommended posture for CI, where you want unreviewed scripts to fail the build rather than silently skip. --ignore-scripts and --dangerously-allow-all-scripts both override it.

Global installs and npx

npm approve-scripts / npm deny-scripts only work inside a project with a package.json — they'll error (EGLOBAL) for global installs and npx. For those contexts, use the allow-scripts config or flag instead:

npm install -g --allow-scripts=canvas,sharp <pkg>
# or persist it:
npm config set allow-scripts=canvas,sharp --location=user

Migrating from a blanket ignore-scripts=true

If you currently keep ignore-scripts=true in your .npmrc, npm approve-scripts --allow-scripts-pending will still list the packages that would need approval, so you can move from a blanket ignore onto a precise allowlist. Note that while ignore-scripts=true remains set, it takes precedence and no scripts run — the allowlist does not override it. Remove ignore-scripts once your allowlist is in place.

Timeline

Version	Date	Behavior
npm 11.16.0	Available now	Features available; warnings by default; opt into enforcement with strict-allow-scripts
npm 12	Estimated July 2026	allowScripts off by default; --allow-git and --allow-remote default to none

How to get help

• General questions and discussion: reply in this thread.
• Bugs or regressions: npm/cli issues, tag allowScripts.
• Maintainers of high-impact packages: open an issue in npm/cli tagged maintainer-outreach.
• Enterprise customers: contact your GitHub or Microsoft account team.

References

• allow-scripts config
• npm approve-scripts
• npm deny-scripts
• Breaking changes PR for npm v12

[mrbusche]

Will Node 26 eventually ship with npm 12? Or will that wait until Node 27?

[sebdanielsson]

Would’ve been nice with a default min package age too👍

[VladSez]

hard agree

[tbroyer]

There should be a way out of ignore-scripts, while keeping it for NPM < 11.16.0

In a shared CI environment, we set a global npm_config_ignore_scripts environment variable, and could easily set npm_config_strict_allow_scripts. We cannot force every project to upgrade to NPM >= 11.16.0.
Ideally there should be a way to have npm_config_ignore_scripts respected in NPM < 11.16.0 projects, and using allowScripts in NPM >= 11.16.0 projects. Maybe some other flag allowing to ignore npm_config_ignore_scripts.

[JamieMagee]

IMO The env var winning is a feature, not a gap. You set npm_config_ignore_scripts globally, which sits at the env level, and a project's package.json can't override that with allowScripts. Env outranks project, and ignore-scripts beats allowScripts regardless. If a user says "run nothing," a repo shouldn't be able to switch its own scripts back on.

Old npm keeping the blanket block while new npm uses the allowlist, is being discussed in npm/cli#9450. The migration half already landed: approve-scripts --allow-scripts-pending now lists packages even under ignore-scripts=true, so you can build the allowlist without dropping your global block first.

[chronoB]

What is the recommended way to install new packages that include scripts?

Current behaviour when strict-allow-scripts=true is set in the .npmrc:
npm install -D esbuild fails because esbuild includes a postinstall script.
npm approve-scripts esbuild fails because esbuild is not installed
npm install -D esbuild --allow-scripts=esbuild fails because the option is only for global installs.
npm install -D esbuild --dangerously-allow-all-scripts works but it bypasses the whole allowScripts mechanism although I only wanted to allow the script for esbuild.

Am I missing something?

[JamieMagee]

strict-allow-scripts is not the v12 default and won't be. The v12 default is softer: an install script you haven't approved gets skipped, you get a warning, and the install still succeeds. So npm install -D esbuild just works. esbuild lands in node_modules, its postinstall is skipped, you see a warning saying so. No failure, and no chicken-and-egg.

The wall is coming entirely from strict-allow-scripts=true. That turns the skip into a hard error that fires before npm writes anything, so esbuild never gets installed. That's why approve-scripts esbuild can't find it afterward. There's nothing on disk to approve yet.

The other two are doing what they should. --allow-scripts is blocked in project installs on purpose (it's for -g and npx), and --dangerously-allow-all-scripts skips the whole policy by design.

So I'd just not run strict on your dev machine. Keep it in CI, where the package is already in package.json and already approved. Locally:

npm install -D esbuild        # installs; postinstall skipped + warning
npm approve-scripts esbuild   # writes the allowScripts entry
npm rebuild esbuild           # runs the now-approved postinstall

Commit the package.json and CI passes, because esbuild is now covered. If you really want strict locally too, add new packages with --no-strict-allow-scripts for that one command, then approve and rebuild.

[tbroyer]

strict-allow-scripts is not the v12 default and won't be.

This is not what the "Try the breaking behavior now" section above says though.

[JamieMagee]

I'll get that updated.