npm v12: Install Scripts Disabled by Default, Explained

npm v12 has turned off dependency install scripts by default, and the next deadline in the same security overhaul lands in roughly two months. Since npm 12.0.0 shipped on July 8, 2026, preinstall, install, and postinstall scripts from dependencies no longer run automatically during npm install — they have to be explicitly approved. Git and remote-URL dependencies were switched to opt-in at the same time. Now, with npm sitting at version 12.2.1 and GitHub's self-imposed "around January 2027" date for cutting off direct publishing from 2FA-bypass tokens getting closer, teams that haven't audited their install pipeline are running out of runway.

What actually changed in npm v12

According to npm's own release notes for v12.0.0, dependency lifecycle scripts "are now blocked by default unless allowed by the root package's allowScripts policy." That one line covers a lot of ground: preinstall, install, and postinstall hooks defined by anything in node_modules, plus the implicit node-gyp rebuild step that native-addon packages have historically relied on, plus prepare scripts from git, file, and link dependencies. None of it runs anymore unless the project's package.json says it can.

The same release also flips two other defaults. --allow-git now defaults to none, so npm won't resolve git dependencies — direct or transitive — without an explicit flag. --allow-remote does the same for dependencies pulled from arbitrary URLs, such as https tarballs. GitHub's companion changelog post from June 9, 2026 had already previewed both changes as warnings in npm 11.16.0, giving teams a heads-up window before the hard default landed in v12.

A smaller but easily missed change: the root package's own preinstall script now runs before dependencies are installed, rather than after — the opposite of the previous ordering. If a build pipeline assumed dependencies were already in place when its own preinstall hook fired, that assumption no longer holds.

Why GitHub is doing this now

npm has been owned and operated by GitHub since 2020, and GitHub's own framing treats install-time scripts as the single largest code-execution surface in the npm ecosystem: any of the roughly two million packages on the registry can run arbitrary code the moment it's installed, with no review step in between. That surface has been exploited repeatedly through 2026 in self-propagating "worm" campaigns that compromised maintainer accounts and pushed malicious postinstall scripts to widely-used packages, so turning lifecycle scripts into an opt-in allowlist removes the automatic-execution step that those campaigns depend on.

It's worth being precise about what this does and doesn't fix. It doesn't stop a compromised package from shipping malicious runtime code that executes when your application calls it. What it does stop is the much larger blast radius of scripts that fire the instant npm install touches disk, often in CI environments with broad credentials attached, before anyone has looked at the code at all.

How to tell if your project is affected

Almost every real-world Node.js project depends on at least one package that uses install scripts, whether for native compilation (bcrypt, sharp, sqlite3 and similar native-addon packages all build during install) or for simpler setup tasks. The practical way to find out is to run an install on npm 11.16.0 or later first, which surfaces the same warnings v12 enforces as hard blocks, without actually breaking the build. If your CI pipeline pins an older npm version, or your Dockerfile installs npm@latest without checking what "latest" resolves to today, that's the first thing to check — "latest" has pointed at v12 since July.

Fixing a broken install: the approval workflow

npm ships a small set of commands specifically for this migration. npm approve-scripts --allow-scripts-pending lists every dependency that has a script waiting for a decision, without approving anything. From there:

• npm approve-scripts interactively (or with a package name) adds trusted dependencies to the allowScripts map in package.json.
• npm deny-scripts explicitly blocks a package's scripts going forward, which is useful for documenting "we looked at this and it's not needed" rather than leaving it in limbo.
• npm rebuild runs newly-approved scripts after the fact, so you don't need a clean reinstall every time you approve one more package.

Per npm's own CLI docs, npm approve-scripts "manages the allowScripts field in your project's package.json," which means the allowlist is committed alongside the rest of the project rather than living in a developer's local npm config — anyone who clones the repo and runs npm install gets the same behavior. CI runners that install with --ignore-scripts already set will see no change; the new default only affects pipelines that were previously relying on scripts running silently.

Teams coming from a Yarn or pnpm background should note this is an npm-specific mechanism — the underlying problem of install-time code execution is shared across the JavaScript tooling ecosystem, but each package manager has implemented its own guardrails on its own timeline.

Git and remote-URL dependencies also need opt-in now

If your package.json has entries like "some-lib": "git+https://github.com/org/some-lib.git" or a dependency pinned to a raw https tarball URL, npm v12 will no longer resolve those without an explicit flag. Set --allow-git=all (or root to scope it to direct dependencies only) and the equivalent --allow-remote flag to restore the old behavior, or better, use the opportunity to move those dependencies onto the registry proper, which already goes through the script-approval flow described above. --allow-file and --allow-directory, used for local path dependencies in monorepos, keep their previous permissive defaults and are unaffected.

The January 2027 token deadline

The install-script change is the part of npm v12 that breaks builds immediately, which is why it's gotten most of the attention. The part with an actual calendar deadline is quieter: granular access tokens (GATs) configured to bypass two-factor authentication are being wound down in two stages. GitHub's changelog for the v12.0.0 launch says the first stage — removing the ability to use a 2FA-bypass GAT for account, package, and organization management actions such as creating new tokens or changing account settings — was expected to take effect "in early August 2026." The second stage is the one worth putting on a calendar now: GitHub's own wording is that it expects direct publishing via 2FA-bypass tokens to end "around January 2027." After that date, a token configured to skip 2FA can still authenticate and stage a release, but an actual human with 2FA enabled has to approve it before the package goes public.

This matters most for CI pipelines that publish packages automatically — a long-lived npm token stored as a GitHub Actions secret, with 2FA bypass enabled so the pipeline doesn't stall waiting for a one-time code, is exactly the pattern being phased out. The underlying motivation is the same as the install-scripts change: a stolen or leaked long-lived publish token with 2FA bypassed is a direct line to shipping malicious code to every consumer of a package, and GitHub has watched that exact failure mode play out in multiple account-compromise incidents through 2026.

Stage-only tokens: the migration path GitHub actually recommends

GitHub's preferred long-term fix is trusted publishing via OIDC, which removes long-lived tokens from the picture entirely. For teams that aren't ready to re-plumb their release pipeline before January, GitHub shipped an intermediate option on September 18, 2026: a "stage only" permission for granular access tokens. A token created with this permission can run npm stage publish from CI, submitting a version for release, but npm rejects any attempt to publish directly with that token even if 2FA bypass is configured on it. A maintainer then reviews and approves the staged version with their own 2FA — the same human-in-the-loop step the January 2027 change makes mandatory for everyone, just adopted early.

Stage-only tokens still carry real permissions worth guarding: GitHub's changelog notes they can still move dist-tags and deprecate versions, so they shouldn't be treated as harmless just because direct publish is blocked. The requirements are npm CLI 11.15.0 or later, Node.js 22.14.0 or later, and 2FA enabled on the approving maintainer's account — broadly the same baseline already needed for the install-script changes, which is one reason GitHub keeps pointing teams at the same npm 11.16.0-or-later upgrade regardless of which part of this rollout they're dealing with.

Where this sits in npm's broader security push

None of this is happening in isolation. npm v12 landed the same year as several high-profile self-propagating supply-chain campaigns that abused exactly the install-script and token-permission gaps v12 closes, and GitHub has been shipping related hardening — from registry-level provenance checks to the stage-only token option above — on a rolling basis rather than as one single release. Projects that have already gone through a major dependency or build-tooling migration this year, such as moving off a legacy JavaScript linter setup or working through a platform upgrade's breaking-change list, will recognize the pattern: a deprecation warning window, followed by a hard default flip, followed by a follow-up patch release cleaning up edge cases. npm 12.2.1's October 15 fix for how allowScripts keys are written under install-strategy=linked installs is exactly that kind of cleanup, not a new breaking change.

What to do next

If you haven't touched your install pipeline since before July, start by upgrading to at least npm 11.16.0 locally and running a normal install to see the warnings npm v12 turns into hard blocks — that tells you exactly which dependencies need a decision before you touch CI. Run npm approve-scripts --allow-scripts-pending to get the specific list, approve what you recognize and trust, and either deny or replace the rest. Separately, audit any CI secret that's an npm publish token: if 2FA bypass is enabled on it purely so an automated pipeline doesn't stall, that token is on GitHub's list to lose direct-publish rights around January 2027, and a stage-only token or a move to OIDC trusted publishing is the cleaner fix either way. Pandromeda will follow up once GitHub confirms a firm date for the January cutover, since "around January 2027" is still, by GitHub's own wording, a target rather than a locked-in deadline.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage