npm Staged Publishing Available, Adding a Human Approval Step Before Packages Go Live

npm has introduced staged publishing for Node.js packages, adding a human approval step before a published version becomes installable. According to InfoQ reporting by Daniel Curtis, maintainers must approve a queued version and complete a two-factor authentication challenge before that release goes live. The feature ships in npm CLI 11.15.0 and later, and requires Node 22.14.0 or newer. It arrives alongside new configurable permission flags aimed at tighter control over who can advance a package through the publish path.

Under staged publishing, a version does not become installable the moment it is pushed. It is held in a queue until a maintainer explicitly releases it, and that release step is gated by two-factor authentication. Configurable permission flags sit beside the flow so teams can define who is allowed to approve or finalize a staged version. The mechanics insert a deliberate checkpoint between package upload and public availability rather than treating publish as a single atomic action.

For package maintainers and application engineers, the change targets a common supply-chain failure mode: a compromised credential or automated pipeline that pushes a malicious or mistaken version straight to the registry. A queued state plus a 2FA-backed approval step forces a human decision before consumers can install the build. Builders who automate releases will need to account for that extra gate in CI and release runbooks, especially when multiple maintainers share ownership of a package.

The move sits against a broader rise in npm and wider open-source supply-chain attacks, where stolen tokens and silent republishes have repeatedly put downstream dependents at risk. Staged publishing is a registry-side control rather than a scanner or advisory feed: it slows the path from publish to install so compromised automation cannot go live without an authenticated human step. Configurable permission flags extend that model by letting maintainers limit who can complete the release, which matters for large or multi-owner packages.

Teams that ship on npm should plan for npm CLI 11.15.0 or newer and Node 22.14.0 or newer before relying on the workflow. Practical next steps are to enable staged publishing on high-impact packages, assign permission flags so only trusted maintainers can clear the queue, and update release automation so it stops at the staged state instead of assuming immediate installability. Watch how permission models interact with org and team ownership, and whether CI jobs need explicit human handoff for production releases.