npm v12 Kills Auto-Run Scripts: What Developers Must Do

For over a decade, running npm install has been an act of implicit, terrifying trust. With a single command, developers routinely invite hundreds of nested, third-party packages to execute arbitrary code on their local machines and CI/CD runners. It is an attack surface so vast and easily exploited that it birthed entire families of malware, most notably the Shai-Hulud worm.

That era is coming to a close. In npm v12, scheduled for release in July 2026, GitHub is turning off automatic install-time script execution by default. As maintainer Leo Balter noted, install-time lifecycle scripts represent "the single largest code-execution surface in the npm ecosystem."

This is not a minor configuration tweak; it is a fundamental shift in control philosophy. By forcing developers to explicitly opt into script execution, npm is finally shedding a legacy of dangerous defaults. However, because these defaults have spent a decade hardening into the bedrock of the JavaScript ecosystem, the transition will be noisy, disruptive, and highly breaking.

The Three Pillars of the npm v12 Lockdown

The security overhaul in npm v12 targets three distinct, highly abused vectors. By default, the package manager will transition from a model of "trust unless blocked" to "block unless permitted."

flowchart TD
    A[npm install] --> B{Is script in allowlist?}
    B -- Yes --> C{Is version pinned?}
    C -- Yes --> D[Execute Script]
    C -- No --> E[Block Script]
    B -- No --> E

1. Disabling allowScripts by Default

Scripts configured for preinstall, install, or postinstall will no longer run automatically. This restriction includes implicit node-gyp builds. If a package contains a binding.gyp file but no explicit install script, npm v12 will still block the implicit node-gyp rebuild step. Similarly, prepare scripts originating from git, file, and link dependencies will be blocked.

2. Turning Off --allow-git

Previously, a malicious dependency could ship with a custom .npmrc file designed to override the local Git executable path, leading to arbitrary code execution even if a developer had set --ignore-scripts. In v12, --allow-git defaults to off, preventing npm from resolving Git dependencies (both direct and transitive) unless explicitly configured.

3. Blocking Remote URLs via allow-remote

To prevent untrusted code from slipping into the dependency tree at install time, allow-remote will default to none. This blocks npm from downloading dependencies from arbitrary remote URLs, such as external HTTPS tarballs, forcing all dependency resolution through trusted registries.

The Practical Migration Path

If you are running the current stable version, npm 11.16.0 (or any version since 11.10.0, released in February 2026), these security controls are already available as opt-in flags. You can prepare your codebase for the v12 upgrade today by setting these flags in your local .npmrc or via environment variables.

To audit and approve scripts in your current project, use the new interactive tooling introduced in the npm 11.x line:

npm approve-scripts --allow-scripts-pending

This command scans your dependency tree, identifies packages requiring install-time scripts, and prompts you to approve the ones you trust. Once approved, these permissions are recorded in your package.json and pinned to the specific installed version of the package.

{
  "dependencies": {
    "some-native-tool": "^1.2.0"
  },
  "allowScripts": {
    "some-native-tool": "1.2.3"
  }
}

If a package is updated to a new version, its script execution privileges are revoked until you re-approve the new version.

The ignore-scripts Conflict

Many security-conscious teams currently set ignore-scripts=true in their .npmrc files. Be warned: the legacy ignore-scripts flag is a blunt instrument that does not support an allowlist. If ignore-scripts is active, it will completely override the new allow-scripts configuration. To adopt the new, granular allowlist model, you must remove ignore-scripts from your configuration and transition entirely to the allowScripts schema.

The Fallout: What Breaks and Who Wins

This change will break builds. The JavaScript ecosystem has long relied on post-install hooks to paper over platform differences and fetch heavy binaries. The impact will be felt immediately across three major categories of tools:

• Native C/C++ Modules: Packages that compile native code on install via node-gyp (e.g., database drivers, cryptography libraries) will fail to build until explicitly allowed.
• Headless Browsers and Testing Frameworks: Tools like Playwright and Puppeteer rely on postinstall scripts to fetch browser binaries. Without explicit approval, your testing suites will break.
• Desktop Shells: Frameworks like Electron, which bundle Chromium and Node.js, use install-time scripts to set up platform-specific binaries.

While this friction is real, it is the price of security. As Sanchit Vir Gogia, chief analyst at Greyhound Research, noted, "The trouble with bad defaults is that they become infrastructure." In 2016, npm's official stance was that the convenience of automatic install scripts outweighed the security risks. Ten years later, that trade-off is no longer defensible.

npm is also the last major package manager to make this leap. Rivals like pnpm (v10+), Yarn Berry, Bun, and Deno have blocked third-party install scripts by default for some time. By adopting these defaults, npm is finally aligning with modern industry standards.

The Next Battleground: Runtime Execution

Skeptics of this change point out an obvious limitation: blocking install scripts does not eliminate malware; it merely relocates it. As one developer dryly observed, "Now all the malware can move from the install script to the module itself where it will inevitably still be run."

This is true, but it misses a critical distinction in the threat model.

Install-time exploits are highly dangerous because they execute automatically upon download, regardless of whether the compromised package is ever imported or executed by your application. A deeply nested, unused transitive dependency could compromise a developer's machine or steal CI secrets during a routine bootstrap.

By contrast, runtime malware requires the application to actually load and execute the compromised module. This introduces a critical point of friction for attackers. It also buys time for static analysis tools, dependency scanners, and features like npm's min-release-age (which blocks packages published less than a specified number of days ago) to detect and quarantine malicious code before it is ever imported into a running process.

The Verdict

This is a necessary, overdue correction. The friction of managing an allowlist in package.json is a minor tax compared to the catastrophic risk of unconstrained code execution on developer workstations and build servers.

Do not wait for July's npm v12 release to break your pipelines. Upgrade to npm 11.16.0 today, run npm approve-scripts, and start auditing your dependency lifecycle hooks before the platform forces your hand.