npm, the default package manager for Node.js now maintained by GitHub, has made staged publishing generally available, requiring an explicit maintainer approval step before a published version becomes installable by users. Instead of a direct publish that instantly makes a version available to consumers, the prebuilt tarball uploads to a stage queue visible on both npmjs.com and in the command-line interface. A human maintainer must then pass a two-factor authentication challenge to release it. The change arrives after what the report describes as "a punishing run of supply chain incidents," from the Shai-Hulud worm waves to a difficult migration away from classic tokens.
The feature works with npm CLI 11.15.0 or newer and Node 22.14.0 or higher, and the package must already exist on the registry. Staging itself doesn't require two-factor authentication and works with any token type, so non-interactive continuous integration pipelines remain unaffected, and the proof of presence shifts to the approval step. GitHub recommends pairing staging with trusted publishing over OIDC, where a configuration can be limited to stage only, so a direct npm publish from that workflow is blocked entirely. Teams already using bulk trusted publishing configuration can reuse it to migrate packages, then update continuous integration to the newer command-line interface and swap the publish command. The same release adds four new flags—--allow-file, --allow-remote, --allow-directory, and the existing --allow-git—each accepting all or none and configurable in .npmrc or package.json, with --allow-git set to default to none in version 12.
Security researcher Adnan Khan was emphatic in a post on X, stating: "Everyone publishing to NPM should turn this feature on today." On Hacker News, one user argued that "staged publishing is a band aid" and that "in the long run it will even hurt our efforts for more secure infra," which prompted a response questioning how it could possibly hurt, noting that for trusted publishing, "it's a significant improvement that kills an entire class of CI takeover publish attacks." Others questioned adoption, with one commenter observing it only helps "if maintainers actually use it" and another asking whether it should be enforced by default. A commenter on Reddit framed it as "a reduction in spread rate" rather than a cure.
The report notes that competitors have moved quickly to adopt similar protections. pnpm 11.3 added pnpm stage with the same subcommands, Yarn exposes yarn npm stage list, and release-it supports a "stage": true option. pnpm also delays installing very new releases by default, a complementary defense. The staging workflow addresses a specific attack vector: compromised continuous integration pipelines that can immediately push malicious code to millions of downstream users. By separating the upload step from the approval step, even if an attacker gains access to a build system, they can't complete the publication without a human maintainer passing a two-factor authentication challenge—creating a human checkpoint that automated attacks can't bypass.
GitHub says next steps include defaulting two-factor-authentication-bypassing granular access tokens to stage only, and an allowScripts field that flips install scripts to opt-in in version 12. The workflow uses a small set of subcommands: npm stage publish to submit the version to the stage queue, npm stage list to list staged versions awaiting approval, npm stage view to inspect the staged tarball, npm stage approve to promote it to the registry with a prompt for two-factor authentication, and npm stage reject to discard it. The CLI reference covers flags such as --tag and --provenance, which behave as they do for npm publish. The approach represents a shift from prevention to containment: rather than trying to make build systems impenetrable, it assumes they will be compromised and adds a human gate that slows the blast radius. For organizations already grappling with the operational burden of defending sprawling dependency trees, the question becomes whether adding another manual checkpoint strengthens the chain or simply moves the weakest link to a place where fatigue and convenience will eventually override caution.

