A new npm token can submit a release but cannot publish one

A token that can publish to npm is a token that can put code on every machine which installs the package. Since September 18, 2026, a granular access token can carry a narrower permission, read and write (stage only), which lets automation run npm stage publish and nothing else. The version lands in a staging area and waits there until a maintainer approves it with a second factor.

What the stage-only token can and cannot do

The permission appears in the token creation form as read and write (stage only). A workflow holding such a token submits its build with npm stage publish, and the documentation says that command does not require a second factor. The registry refuses npm publish from the same token, and it refuses it even when the token is configured to bypass two-factor authentication for automation. That setting is the one that makes unattended publishing possible at all.

The narrowing is not total. GitHub states that stage-only tokens keep the rest of their package write permissions, including moving dist-tags and deprecating versions. A dist-tag decides which version npm install hands out by default. One possible reading is that a stolen stage-only token still reaches users, only through a version that is already on the registry rather than a new one.

• Staged publishing needs the npm command-line tool 11.15.0 or later and Node.js 22.14.0 or later.
• The account that stages a version needs two-factor authentication enabled and publish access to the package.
• The package must already exist on the registry, so a brand-new package cannot be staged.
• A maintainer inspects a staged version from the command line or in the Staged Packages tab on the registry site.

The deadline that is already set

This arrives with a date attached to it. On July 31, 2026, the registry said it was targeting January 2027 to remove direct publishing through tokens that bypass two-factor authentication. The recommended destination is trusted publishing, where a continuous integration system proves its own identity to the registry and no long-lived secret exists.

Stage-only tokens exist for the projects that will not get there in time. GitHub describes the new permission as a way to move off token-based automation, and says the release is opt-in: existing tokens and their direct-publish capability are untouched.

What the extra step actually buys

The gain is not in the token. It is in the second person. Staged publishing separates building a version from making it public, and only the second act requires two-factor authentication.

This suggests the benefit is narrower than the headline promises. A leaked stage-only token can no longer put a new version in front of users on its own, but it can still move a dist-tag or deprecate a release. The extra approval also costs a maintainer attention on every release, and that is the kind of cost people switch off after the third false alarm.