npm v12 became generally available on 8 July 2026, and with it npm has changed the behaviour of npm install in a way it never has before: three things that used to run automatically now require explicit approval. The release turns on the install-time security defaults GitHub previewed in a 9 June breaking-change notice, and it is the most consequential change to npm's threat model in years.

The reason is straightforward. Install-time lifecycle scripts are what GitHub describes as the single largest code-execution surface in the npm ecosystem, because every npm install has been able to run scripts from every dependency in the tree — including transitive packages a developer never chose. Many recent npm supply-chain campaigns relied on exactly that install-time execution: code that ran the moment a package landed in node_modules, before any application code loaded. v12 makes that path opt-in.

The three defaults that flipped

Three npm install behaviours that used to run automatically are now opt-in:

  • allowScripts defaults to off. Dependency lifecycle scripts — preinstall, install, postinstall — no longer run unless explicitly allowed. Critically, this also covers implicit native builds: a package with a binding.gyp file triggers a node-gyp rebuild even without an explicit install script, and those are now blocked by default too.

  • --allow-git defaults to none. Git dependencies, direct or transitive, are no longer resolved unless allowed.

  • --allow-remote defaults to none. Dependencies fetched from remote URLs, such as HTTPS tarballs, are no longer resolved unless allowed.

The related --allow-file and --allow-directory flags are not changing. All three of the new defaults were available behind warnings in npm 11.16.0 and later — --allow-git since 11.10.0, --allow-remote since 11.15.0 — so teams have been able to preview exactly what v12 blocks before upgrading.

The part the headlines get wrong

It is easy to read a headline about install scripts being blocked as meaning your builds will break. The default is softer than that. When npm v12 encounters an install script you have not approved, it skips the script, emits a warning, and the install still succeeds. Running npm install -D esbuild still works: the package lands in node_modules, its post-install step is skipped, and you get a warning telling you so. Hard failure only happens if you opt into stricter enforcement with --strict-allow-scripts, which turns the skip into an error before anything is written.

The genuine trap is native builds, and it is worth understanding precisely because it fails quietly. A blocked node-gyp build does not stop the install. It means the native binary is never compiled — so the failure surfaces later, at runtime, when application code first tries to use it. An unapproved sharp does not break npm install; it breaks the first request that tries to resize an image. That is a far worse place to discover the problem, and it is the reason a seemingly clean dependency with no visible scripts can still end up on your approval list.

The workflow to get ahead of it is short: upgrade to npm 11.16.0 or newer, run a normal install, and review the warnings. npm approve-scripts --allow-scripts-pending lists every package whose scripts are not yet covered; approve the ones you trust with npm approve-scripts, block the rest with npm deny-scripts, and commit the resulting allowlist in package.json so installs stay reproducible. For CI runners and any pipeline that invokes npm install non-interactively — which cannot answer an approval prompt — that committed allowlist is what keeps builds deterministic after the upgrade.

The second change: winding down 2FA-bypass tokens

v12 also begins deprecating the most sensitive uses of 2FA-bypass granular access tokens. A later step, expected around January 2027, removes direct publishing from those tokens, leaving them able to read private packages and stage a publish that a human still has to approve with 2FA. GitHub's guidance is to move automated publishing to trusted publishing over OIDC, or to staged publishing with a human approval step, rather than relying on a long-lived publish token. One earlier v12 breaking change was also walked back: unknown configuration keys in .npmrc now warn by default rather than hard-failing, with a strict mode available for teams that want it. Unknown CLI flags still error.

The npm team has said it hopes to backport the v12 install defaults to Node 24 and Node 26, both active LTS lines, though that decision belongs to the Node release team. If it lands, the new defaults reach a much larger audience on a shorter timeline than waiting for Node 27.

Key Takeaways

  • npm v12 went generally available on 8 July 2026, making install scripts, Git dependencies and remote-URL dependencies opt-in rather than automatic.

  • The default is soft: unapproved scripts are skipped with a warning and the install still succeeds; hard failure requires the opt-in --strict-allow-scripts.

  • Native builds are the real trap — a blocked node-gyp build fails at runtime, not install, so a script-free package with a binding.gyp can still surprise you.

  • Prepare on npm 11.16.0+: run npm approve-scripts --allow-scripts-pending, approve trusted packages, and commit the allowlist for reproducible CI installs.

  • v12 also begins retiring 2FA-bypass publish tokens (fuller removal ~January 2027) in favour of OIDC trusted publishing; account-takeover and runtime attacks remain out of scope.