Updated 16 Aug 2026: Updates the dossier to reflect that npm's first bypass-2FA granular access token restriction is now live, rather than merely scheduled, and tightens the migration guidance for affected automation.
Key details
- npm v12 became generally available and was tagged `latest` on July 8, 2026.
- Dependency `preinstall`, `install` and `postinstall` scripts are opt-in; implicit `node-gyp` builds are covered by the same policy.
- `--allow-git` defaults to `none`, so direct and transitive Git dependencies require explicit permission.
- `--allow-remote` defaults to `none`, so direct and transitive remote-URL dependencies require explicit permission.
- npm 11.16.0+ can warn about scripts and dependency forms that will be blocked after upgrading.
- As of July 31, bypass-2FA npm granular access tokens can no longer perform sensitive account, organization and package-management actions.
- The new token restriction affects npm granular access tokens specifically, not GitHub personal access tokens, GitHub App tokens or `GITHUB_TOKEN` in Actions.
- GitHub still expects direct publishing through bypass-2FA granular access tokens to end around January 2027.
What builders should take away
- Pin npm in CI and test the same lockfile under npm 12 before changing the team's default toolchain. Include a clean dependency install in the upgrade gate, not only application tests.
- Run `npm approve-scripts --allow-scripts-pending` on npm 11.16.0+ and review every package requesting install-time execution. Commit the resulting policy so developer machines and CI enforce the same trust decisions.
- Search manifests and lockfiles for Git and remote-URL dependencies, including transitive ones, and replace unusual sources with registry releases where practical rather than broadly enabling the new allowances.
- Audit automation that uses npm granular access tokens configured to bypass 2FA. Sensitive package, organization and account changes now require an interactive 2FA challenge, so workflows that performed those operations may already fail.
- Move package publishing toward trusted publishing/OIDC before the expected January 2027 direct-publish cutoff instead of treating that date as a future migration problem.
What changed
npm v12 became generally available on July 8 with dependency lifecycle scripts, Git dependencies and remote-URL dependencies changed from automatic behaviour to explicit opt-in. A related npm security change that BTN previously described as forthcoming is now live: on July 31 GitHub confirmed that npm granular access tokens configured to bypass 2FA can no longer perform sensitive account, organization and package-management actions. Those operations now require an interactive 2FA challenge. GitHub still expects direct publishing through bypass-2FA granular access tokens to end around January 2027.
Why it matters
The npm changes are reducing two different supply-chain attack surfaces at once: automatic code execution during dependency installation and the blast radius of stolen long-lived credentials. Teams upgrading to npm 12 need to encode install-time trust explicitly, while package maintainers using granular access tokens must also verify that automation does not depend on privileged account or package changes that now require interactive 2FA. Publishing automation should be migrated toward trusted publishing/OIDC before the next token restriction lands.
Install-time code execution is no longer assumed
In npm v12, `allowScripts` defaults to off. Dependency `preinstall`, `install` and `postinstall` scripts no longer execute unless the project explicitly permits them. The same restriction covers implicit `node-gyp` builds and `prepare` scripts from Git, file and link dependencies. This changes the default posture from trusting dependency-provided install behaviour to requiring an allowlist in the consuming project.
Git and remote-URL dependencies now need explicit permission
The `--allow-git` and `--allow-remote` defaults are `none`. Direct or transitive Git dependencies will not resolve unless Git use is explicitly permitted, and the same applies to dependencies fetched from remote URLs such as HTTPS tarballs. That narrows the set of installation paths capable of introducing code outside the npm registry.
Teams can prepare before changing the npm major version
npm 11.16.0 and later can surface warnings for behaviours that npm 12 blocks. GitHub recommends running `npm approve-scripts --allow-scripts-pending` to inspect packages that want to execute scripts, then approving trusted packages with `npm approve-scripts` and denying the rest with `npm deny-scripts`. The resulting policy is written to `package.json`, so it can be reviewed and committed before CI or developer machines move to npm 12.
The bypass-2FA restriction is now live
On July 31 GitHub confirmed that npm granular access tokens configured to bypass 2FA can no longer perform sensitive account, organization and package-management actions. Creating or deleting tokens, changing package access or maintainers, changing trusted-publishing configuration, and managing organization or team membership now require an interactive 2FA challenge. GitHub says this closes a credential path where a leaked bypass-2FA token could previously be used to expand an attacker's control.
Direct publishing through bypass-2FA tokens is still on borrowed time
GitHub continues to say that around January 2027, bypass-2FA granular access tokens are expected to lose direct package-publishing capability as well. npm recommends trusted publishing with OIDC, or staged publishing with human approval, for automation that cannot rely on interactive 2FA.
Timeline
2026-06-09
npm previews the v12 breaking changes
GitHub announces the new install-time security defaults and makes warning-based preparation available in npm 11.16.0+.
2026-07-08
npm v12 becomes latest
npm v12 is generally available with install scripts, Git dependencies and remote-URL dependencies changed to explicit opt-in.
2026-07-31
Sensitive bypass-2FA token actions are blocked
GitHub confirms npm bypass-2FA granular access tokens can no longer perform sensitive account, organization and package-management actions.
2027-01
Direct publishing through bypass-2FA tokens is expected to end
GitHub expects those tokens to lose direct publish capability around January 2027 and recommends trusted publishing or staged publishing.
What to watch next
- The exact rollout date for the January 2027 restriction on direct publishing with bypass-2FA granular access tokens.
- Whether npm expands trusted publishing support or migration tooling across more CI environments.
- Whether high-use packages publish migration guidance for installs that depend on lifecycle scripts or native builds.
- Whether npm adjusts the ergonomics of allowlists as more projects adopt v12 and report compatibility issues.
Still unclear
- The amount of real-world npm v12 breakage varies substantially by dependency graph; pure registry-based JavaScript projects may notice little, while native or non-registry-heavy projects can require explicit configuration.
- GitHub describes the direct-publishing restriction for bypass-2FA granular access tokens as expected around January 2027 rather than giving a fixed date.
Sources
Direct reading behind this dossier.