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.

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").

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?

[rvillane]

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

wondering the same, also can consider manually updating NPM to v12 in Node 24 if needed

[JamieMagee]

We are hoping to backport npm 12 to Node 24 & 26. Though, ultimately, that decision lies with the Node release team. You can follow the discussion here: nodejs/Release#1161

[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.

[marypcbuk]

and strict is mentioned as the way to opt in for 11 because the more nuanced approach of the allowlist isn't supported there?

[JamieMagee]

Yeah, 11 does enforce the true/false record keeping in allowScripts. But, at its core, the breaking change between 11 and 12 is that in 11 unreviewed scripts (absent from allowScripts) still run and in 12 they don't.

strict-allow-scripts does bring that breaking behaviour forward to 11, but it's even stricter than what 12 will be.

[vbjay]

Does the allow hash the allowed scripts and npm compare hash before running? Is this just accept package x's {type of script} and if changed could still just run arbitrary code on an update? If version matching then does npm disallow version delete and republish same version? If not then there is a hole of I replace version 1.2 version with a new bad version. You accepted that version range and I snuck something different in.

[kimballa]

Testing this out on a project of mine... five dependencies need approval to run scripts. Only 2 are direct dependencies; the other three are indirect. Looking at an install.js file from one of these, it just require's another file and invokes some methods there. I can't easily examine "what's the script command"; I would need to fire up the IDE and start tracing through the call stack and parsing code in a transitive dependency where I have zero familiarity with the internals to begin with. And, frankly, zero desire to get deep familiarity!

I also realized that this command pins the exact version, so as soon as you upgrade any dependency, it'll prompt for permission again; and the CLI output doesn't differentiate between "you upgraded from 1.2.3 to 1.2.4, probably fine" vs "this didn't used to have an install script, now it does".

I appreciate the improved rigor but realistically unless you actually want to absolutely scrutinize your dependency tree's code... I think people are going to just accept (or reject) everything reflexively. If you want engineers with jobs other than "forensic analysis of dependency installers" to be able to make safe / educated choices, that needs to be severely narrowed down from "decide whether to trust this random code" to something more like restricting installation processes to some well-defined library(ies) of installer code. Then force installation actions to run through those libraries, rather than giving all package authors the ability to invoke arbitrary js. End-users could then trust (or not) specific installer libraries that have a safe reputation for just doing native compilation, or setting up env files from a template, or downloading another signed package from the same package repository as the original, or some other well-defined common installation activities.

[vbjay]

Testing this out on a project of mine... five dependencies need approval to run scripts. Only 2 are direct dependencies; the other three are indirect. Looking at an install.js file from one of these, it just require's another file and invokes some methods there. I can't easily examine "what's the script command"; I would need to fire up the IDE and start tracing through the call stack and parsing code in a transitive dependency where I have zero familiarity with the internals to begin with. And, frankly, zero desire to get deep familiarity!

I also realized that this command pins the exact version, so as soon as you upgrade any dependency, it'll prompt for permission again; and the CLI output doesn't differentiate between "you upgraded from 1.2.3 to 1.2.4, probably fine" vs "this didn't used to have an install script, now it does".

I appreciate the improved rigor but realistically unless you actually want to absolutely scrutinize your dependency tree's code... I think people are going to just accept (or reject) everything reflexively. If you want engineers with jobs other than "forensic analysis of dependency installers" to be able to make safe / educated choices, that needs to be severely narrowed down from "decide whether to trust this random code" to something more like restricting installation processes to some well-defined library(ies) of installer code. Then force installation actions to run through those libraries, rather than giving all package authors the ability to invoke arbitrary js. End-users could then trust (or not) specific installer libraries that have a safe reputation for just doing native compilation, or setting up env files from a template, or downloading another signed package from the same package repository as the original, or some other well-defined common installation activities.

Thanks @kimballa, I think you are seeing the same concern I am.

I could see this being useful in two related output modes.

The first would be a human-friendly markdown report, aimed at code review / PR discussion. It would show the pending package, where it is installed, which lifecycle scripts are present, and what local files appear to be part of that install-time execution path.

The second would be a machine-readable output format, such as JSON, so CI tools, GitHub Actions, security tooling, dependency bots, or AI review tools could consume the same information without scraping console text.

The important part is that the output should not just say:

Package X needs approval

It should help answer:

What exactly am I approving?

For example, if package "x@1.3.4" is in the pending approval list, the output could include something like:

Package: x@1.3.4
Location: ./node_modules/x/

Lifecycle scripts:
install: node install.js
postinstall: node setup.js

Referenced files:
./install.js
./setup.js
./lib/download.js

If "install.js" references other local files, include those too where reasonably detectable. If "setup.js" invokes another script, binary, shell file, or JS module, include that in the review set. The point would not be to prove the package is safe, but to gather the obvious files and commands a human should review before adding an "allowScripts" entry.

For the machine-readable version, the same data could be emitted as structured output:

{
"package": "x",
"version": "1.3.4",
"location": "./node_modules/x",
"pendingApproval": true,
"lifecycleScripts": {
"install": "node install.js",
"postinstall": "node setup.js"
},
"referencedFiles": [
"./install.js",
"./setup.js",
"./lib/download.js"
]
}

That would let Dependabot or CI say: “this package has pending lifecycle code; here is the review report,” without automatically approving it.

It would also make the data useful for asking AI to help with the review. Instead of asking an AI tool a vague question like “is this package safe?”, a developer could provide the generated markdown or JSON and ask: “Review this install-time execution path. Look for risky behavior such as network calls, "child_process", credential/env access, writes outside the package directory, obfuscation, remote code download, or scripts that invoke other scripts.”

AI should not approve the script automatically, but it could help summarize the risk and point the human reviewer to the specific files or patterns that deserve attention.

In other words, "npm approve-scripts --allow-scripts-pending" identifies the packages that need attention. A review-report mode would help collect the lifecycle commands and obvious referenced files for each pending package so the approval step is more deliberate and less likely to become “approve the package name until the warning goes away.”

On the trusted-installer-library idea: I like the direction, but I think it has the same reapproval loop problem unless there is a different trust model. If installer library versions are pinned exactly, then every installer library update needs reapproval and we are back to the same approval fatigue cycle. If installer libraries are approved by name across versions, then we are trusting future versions of the installer library. That may still be better than trusting arbitrary install scripts from every package author, but the tradeoff should be explicit.

Maybe the distinction is:

• arbitrary package lifecycle scripts should require package/version review;
• well-known installer libraries could have a narrower, documented capability model;
• updates to those installer libraries still need some kind of review, but the review surface is smaller and more standardized than tracing arbitrary package-authored JavaScript.

That would be an improvement because the reviewer is no longer asking “do I trust this random transitive dependency’s custom installer?” They are asking “do I trust this known installer framework and this package’s declared installer actions?”

[vbjay]

Taking the trusted-installer-library idea one step further, maybe the better long-term model is not “trusted installer JavaScript” at all, but a constrained declarative install DSL.

Instead of package authors writing arbitrary lifecycle code like:

{
"postinstall": "node install.js"
}

they could declare a limited set of install actions:

{
"installActions": [
{
"type": "downloadArtifact",
"source": "npm-registry",
"package": "@vendor/native-linux-x64",
"version": "1.2.3",
"integrity": "sha512-..."
},
{
"type": "compileNative",
"tool": "node-gyp",
"source": "binding.gyp"
},
{
"type": "copyFile",
"from": "templates/default.env",
"to": ".env.example",
"overwrite": false
}
]
}

That would make review much easier because the reviewer is no longer trying to trace arbitrary JavaScript through install.js, require() calls, shell commands, network calls, and dynamic behavior. They are reviewing declared install actions with known semantics.

The installer runtime could then enforce the boundaries:

no arbitrary shell execution

no arbitrary network access

no reading unrelated environment variables

no writes outside approved paths

no modifying .npmrc, .ssh, git config, shell profiles, etc.

artifact downloads must come from approved sources and match integrity/signature data

That would not eliminate trust entirely, but it would narrow the decision from “do I trust this random transitive dependency’s installer code?” to “do I trust these declared install actions under a constrained installer engine?”

A review report would still be useful in the short term, but a declarative install model seems like the more reviewable long-term direction.

[kimballa]

Yea I mean that's kind of where this is going; but I think building all of that into npm (or even defining the "right" DSL) is a tall order to do off the bat :) My proposal was a more incremental step in that direction: but "it's not your arbitrary code the user has to trust; it's semi-arbitrary code from some well-known collection of dsl-like js functions."

[vbjay]

Thanks for this writeup and for the clarifications throughout the thread — particularly the confirmation that strict-allow-scripts is not the v12 default, and that Dependabot does not touch allowScripts. Both of those are important distinctions that deserve more prominence in the original post.

Pulling together a few threads from the discussion, I think there are a few connected follow-on priorities worth calling out. One note upfront: reading through the 12.0.0-pre.1 release notes, several real improvements have already landed — the ignore-scripts=true + --allow-scripts-pending listing bug is fixed, allowScripts is now enforced across prune, dedupe, uninstall, audit fix, and link, and bundled dependency hardening is in. That's meaningful progress. The gaps below are about what's still open.

---

The real gap in --allow-scripts-pending

The thread confirmed that the pending output shows the lifecycle script values from package.json. So if the script is node install.js, that is what you see. What you do not see is what is inside install.js, what it requires, what those files do, or whether any of them perform network calls, invoke child_process, read credentials from process.env, or write outside the package directory.

This is also visible in how arborist works: install scripts are read from actual files on disk. The code path runs through real files — install.js, setup.js, download.js, whatever the chain leads to. Those files are there. They are just not surfaced in the pending output.

@kimballa described this from real testing: a transitive dependency's install.js that just requires another file means opening an IDE and tracing a call stack through unfamiliar code. That is not just a workflow gap — it is a workflow that often will not happen in practice. The approval can easily become "node install.js — looks reasonable, approve."

This is the core limitation. --allow-scripts-pending identifies which packages need attention. It does not fully help answer: what exactly am I approving?

A review-report mode would help. Not to prove a script is safe, but to surface the obvious execution path so the decision is informed rather than reflexive. At minimum, that could include:

• lifecycle script name and exact command value
• local files directly referenced by that command, such as install.js, setup.js, shell scripts, or binaries
• obvious local files those scripts reference, where statically detectable
• risk signals such as child_process, eval, network calls, credential/env access, or writes outside the package directory
• a diff against the previously approved version's lifecycle scripts and referenced files, where one exists

The response was to open an issue in npm/cli or npm/rfcs, which makes sense — and I plan to do that. This feels like the feature that determines whether an allowScripts approval becomes a meaningful security decision or a renamed click-through.

---

Dev machine vs. CI/CD

The guidance that emerged here — do not necessarily run strict-allow-scripts on dev machines, but do run it in CI — is practical given the chicken-and-egg problem with new package installs under strict mode.

But the security implication is worth stating explicitly in the docs:

In the recommended local workflow, approvals are often created under the soft-skip model, then enforced by CI under strict mode. That means CI strict enforcement is only as trustworthy as the approval that was committed. The approval step may happen when a developer is simply trying to unblock a local install, with the least context and the most pressure to move forward.

That is not an argument against the recommended split — it is probably the right operational model. But it means the review-report feature above is not just nice-to-have; it is what makes the approval step trustworthy enough to rely on.

One additional note on urgency: the npm team is actively pursuing backporting npm 12 to Node 24 and Node 26 (see nodejs/Release#1161). If that lands, these defaults reach the two active LTS lines rather than waiting for Node 27. That is the right call for security, but it also means the tooling needs to be ready for a much larger audience on a shorter timeline.

---

Version bump vs. new script

Something @kimballa raised that deserves more attention: pending output should distinguish between very different cases:

• a version bump where the lifecycle script is unchanged
• a version bump where the lifecycle script changed
• a package that previously had no lifecycle script and now does

Those are very different risk signals. If they all appear as the same kind of pending approval, developers are pushed toward reflexive approve/reject on the package name alone.

Even simple labels would help:

[new lifecycle script]
[lifecycle script changed since last approved version]
[lifecycle script unchanged since last approved version]

That would make the approval list easier to triage and less likely to collapse into bulk approval.

---

Bots and AI agents modifying allowScripts

The thread confirmed that Dependabot does not currently touch allowScripts, which is the right behavior.

The broader issue is that IDE extensions, AI coding agents, and automated "fix the build" workflows already modify package.json. As allowScripts becomes a normal part of that file, there will be natural pressure for tools to resolve pending approval warnings by updating the allowlist — because resolving warnings is what they are built to do.

The docs should state explicitly that allowScripts is a code-execution permission list, not ordinary package metadata. Automated modification of it should be treated as security-sensitive.

Because allowScripts lives inside package.json, CODEOWNERS alone may not be enough to protect it at field level. A CI check may be needed to flag PRs that expand allowScripts, remove denyScripts entries, change false to true, or add name-only approvals without a deliberate human approval commit.

---

None of this is a v12 blocker. The core change is the right call and a real improvement to the ecosystem's default security posture, and the pre.1 progress shows the team is actively tightening the edges.

These feel like the layer that determines whether allowScripts becomes a real audit trail or a list developers learn to clear as quickly as possible. The foundation is solid — I plan to open an issue in npm/cli to track the review-report idea specifically, and will link back here when that's up.

[Snehajit999]

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.