Automation can stage a release without being able to publish it
npm added a Read and write (stage only) option for granular access tokens on 18 September. A workflow holding that token can run npm stage publish to upload a version into npm's staging area, but the token is rejected if it attempts a direct npm publish. A maintainer must review the staged package and approve it with two-factor authentication before the version reaches the public registry.
The approval can happen through the npm CLI or npmjs.com. npm's staged-publishing documentation also lets maintainers list staged versions, inspect their details and download the tarball before approval, giving the human checkpoint access to the artefact that automation intends to release.
The token still carries package-write authority
The restriction is specific to publishing new versions. GitHub says a stage-only token retains other write permissions, including moving dist-tags and deprecating package versions, so it still needs to be protected as a write credential. Staged publishing also applies only to packages that already exist in the npm registry; it cannot be used to introduce a brand-new package.
It is an opt-in bridge toward tighter publishing controls
Existing tokens and direct-publish workflows do not change automatically. GitHub says npm is targeting January 2027 to remove direct publishing from granular access tokens configured to bypass 2FA. Its preferred migration path is trusted publishing with OIDC where possible, while stage-only tokens provide an alternative for automation that still needs a long-lived npm credential.
Using staged publishing requires publish access to the package, 2FA on the maintainer account, npm CLI 11.15.0 or later and Node.js 22.14.0 or later. Trusted publishers can also use the staged workflow if teams want a manual approval step even when CI authenticates through OIDC.
Why the change matters
The new permission separates the ability to prepare a release from the ability to make that release public. That reduces the consequence of one class of stolen CI publishing credentials, because compromising a stage-only token alone cannot create a new public package version. It does not remove all package-management risk because the same token can still perform other write operations, and approval security continues to depend on the maintainer account and its 2FA controls.