npm 12 is expected to arrive in July with a security change that will be felt across JavaScript projects: dependency install scripts will no longer run by default unless a project explicitly allows them.
GitHub outlined the upcoming defaults in a June 9 npm changelog post, describing them as breaking changes for the next major npm release. The shift also affects two common non-registry dependency paths. Git dependencies will default to blocked through --allow-git=none, and remote URL dependencies such as HTTPS tarballs will default to blocked through --allow-remote=none. Local files and directories get new controls too, but their defaults are not changing in npm 12.
The practical result is simple but disruptive: installs that quietly executed lifecycle scripts from transitive dependencies will start requiring a reviewed allowlist. Teams can begin that migration now in npm 11.16.0 or newer, where the new commands and warnings are already available.
What changes in npm 12
The largest change is the new default for dependency lifecycle scripts. Today, packages can run preinstall, install, and postinstall scripts during npm install. Those scripts are useful for legitimate packages that compile native modules, download browser binaries, or prepare platform-specific assets. They are also a favorite place for malicious packages to execute code as soon as a developer or CI runner installs a dependency.
Under npm 12, that behavior moves from automatic to approved. GitHub says projects should use npm approve-scripts to record trusted packages in the project’s package.json, and npm deny-scripts to explicitly block packages that should never run install scripts. The npm documentation explains that the allowScripts field is advisory in the current release but will become the basis for blocking unreviewed scripts in a future release.
The non-registry dependency changes matter for the same reason. Git dependencies and remote tarballs can bypass some of the visibility and review habits teams associate with packages from the public registry. npm 12’s new defaults will force projects to make those sources intentional instead of inheriting them silently through direct or transitive dependencies.
Why GitHub is changing the default
The npm ecosystem has been under pressure from a steady run of software supply-chain attacks, many of them built around install-time code execution. A compromised maintainer account, a typosquatted package, or a poisoned transitive dependency can turn a normal install into a credential-theft path. That risk is sharper now that AI coding tools and agentic development workflows can add, update, and install packages quickly, sometimes with less human attention on every dependency edge.
This change does not remove the need to review dependencies, lockfiles, registries, or CI secrets. It does narrow one of the most dangerous automatic behaviors in the JavaScript toolchain: package code running during installation before a developer has inspected what changed.
GitHub has been moving npm in this direction for months. In May, it made staged publishing generally available and introduced additional install-source flags. Staged publishing lets maintainers push a prebuilt tarball into a stage queue that requires human approval before release. The install-source flags let projects restrict dependencies from Git, remote URLs, local files, and local directories. npm 12 turns some of that stricter posture into the default.
What will break first
The projects most likely to notice the change are the ones with dependencies that do real work during install. Native Node modules may need approval because npm can invoke node-gyp rebuild. Browser automation tools such as Playwright, Puppeteer, and Cypress often use postinstall steps to download browser or runtime binaries. Electron, database drivers, image-processing packages, password-hashing libraries, and Git-hook tooling can also depend on install scripts.
That does not make those packages suspicious. It means their installation side effects need to be visible and deliberate. A blanket approval list may be the fastest way to keep an existing project moving, but teams should treat it as a snapshot to review, not a permanent substitute for dependency hygiene.
CI pipelines are another likely friction point. Build images that move to npm 12 without preparation may start skipping scripts or failing dependency resolution where projects rely on Git URLs or remote tarballs. The safest rollout is to test on npm 11.16.0 first, review the warnings, commit the generated allowlist, and then move CI to enforcement once the team understands what is being approved.
How developers should prepare
For most teams, the first step is not to wait for npm 12. Upgrade a local branch or CI test image to npm 11.16.0 or newer, run a normal install, and inspect the warnings for packages with unreviewed scripts. The read-only command npm approve-scripts --allow-scripts-pending lists packages that still need a decision without changing package.json.
From there, approve only the packages whose install behavior is understood. Pin approvals to the reviewed version where possible, because a name-only approval gives future releases of that package the same permission. If a package’s install script is unnecessary, explicitly deny it so it does not reappear during a later bulk approval.
Teams should also search for Git dependencies and remote tarballs in package.json, lockfiles, workspace manifests, and internal templates. Some may be intentional, such as private repositories or prerelease forks. Others may be old shortcuts that should move back to normal registry packages before npm 12 makes them fail by default.
The change is especially relevant for organizations using AI-assisted coding agents. An agent can propose a package and trigger an install faster than a human reviewer can notice an unusual lifecycle script. npm 12 gives teams a stronger default boundary, but the policy only works if approvals are reviewed, committed, and enforced consistently across local machines and CI runners.
A stricter npm is still not a complete defense
The new defaults reduce one major attack path, but malicious packages can still cause harm through application code, dependency confusion, compromised maintainers, stolen tokens, or misleading updates that look harmless in a lockfile diff. npm 12 should be paired with registry controls, dependency review, least-privilege CI tokens, secret scanning, lockfile monitoring, and provenance checks where the project supports them.
Still, the direction matters. JavaScript package installation has long assumed that dependency code can run first and be questioned later. npm 12 flips that assumption for install scripts and some non-registry sources. For developers, that means a little more migration work this summer. For security teams, it is a rare default change that makes the safer path the ordinary one.
