npm v12 flips install-time to closed-by-default

What just ran on your laptop?

You type npm install. Somewhere in the dependency tree, a package you have never audited fires a postinstall script with the privileges of your shell. That is how it worked. Present tense, until this week.

On July 8, 2026, npm v12 went generally available and picked up the latest tag. The headline change is small in code and large in posture: install-time defaults now assume the least amount of trust that will still let a package land. The npm team announced the direction in June; this is the release that flips the switch.

The new install-time floor

Three switches moved.

Lifecycle scripts (allowScripts) default to off, so postinstall, preinstall and prepare do not fire automatically. Git-URL dependencies stop resolving unless you pass --allow-git. Remote-URL dependencies stop resolving unless you pass --allow-remote.

Read that back. Every one of those cases has been a documented supply-chain hit at some point in the last few years. A malicious postinstall. A git URL pointing at a compromised fork. A remote URL a lockfile could not really pin. The mitigations existed for a while, as opt-in flags for people who thought to look. What changed is the default. The person who does nothing now gets the safer behaviour. The person who wants the old behaviour has to say so, in writing, in a config file a reviewer can grep.

Won't this break my install?

Yes. That is the point.

If your build silently depends on node-gyp compiling a native binary during install, or on a package fetching a binary blob at postinstall time, your first npm ci under v12 is going to fail with a script that did not run.

There is a bridge. Running npm approve-scripts --allow-scripts-pending before you upgrade produces an allowlist of the lifecycle scripts your current tree needs. You review it, keep the ones you trust, cut the rest. That review is the security exercise the tooling has been quietly avoiding for a decade. Do it once per repo, then commit the allowlist so a reviewer can see who added what.

For CI, the shape of the fix is boring and correct: pin your Node and npm versions in your pipeline image so the flip does not surprise a deploy branch, and stage the upgrade behind a matrix job that runs the old and the new npm against your lockfile side by side.

The 2FA-bypass token is being decommissioned

The other half of the announcement is a two-step retirement of the 2FA-bypass Granular Access Token. It is a legitimate mechanism a lot of automation grew to depend on: a token that lets a CI job publish or manage a package without a human hitting a TOTP prompt. Convenient. Also the exact primitive a stolen npm token needs to do damage.

Two windows to circle.

Around early August 2026, 2FA-bypass tokens lose sensitive account, package and organization management. No more creating or deleting tokens, no password changes, no modifying package access.

Around January 2027, they lose direct publish. What remains is reading private packages, and staging a publish that a human still has to approve.

If you have a release pipeline that pushes to the npm registry from a runner, that pipeline probably relies on one of these tokens today. Between now and January you need a plan for the "human approves the publish" step, whether that is the npm-side staging flow, a signed release job that gates on your own attestation, or a short-lived credential path issued by an identity provider your pipeline already trusts.

Homework for this week

Three items on the whiteboard.

First, run npm approve-scripts --allow-scripts-pending against your repos and read the output honestly. Second, audit which of your automation tokens are 2FA-bypass tokens today; anything that manages packages needs a new plan before early August. Third, decide whether your release publishes belong in the "human clicks approve" bucket at all, or whether they should be moving to signed provenance with a verified release job.

None of this is new territory. The June announcement telegraphed it. If it is a surprise to your pipeline this week, that is data about your pipeline.

Signed. Verified. Still your problem.