npm adds stage-only tokens to separate package preparation from release approval

npm has added a Read and write (stage only) option for granular access tokens, according to GitHub's September 18, 2026 announcement. This September 19 report examines the separation between preparing a package and releasing it: automation submits a version using npm stage publish, then a package maintainer reviews and approves publication with two-factor authentication.

npm rejects a direct npm publish attempt made with that token. However, the token retains other package write permissions, including moving dist-tags and deprecating versions. It should not be treated as a read-only credential.

A review step needs a defined purpose

From a team's perspective, the design can leave package preparation to automation while keeping the release decision with a responsible maintainer. But that review needs substance. Clicking approve without examining the result provides different evidence from checking the actual package against an intended change.

In a hypothetical review process, a team could inspect the package name, version number, included files and relationship to approved changes. These are suggested checks, not findings from an inspection of a specific package. Their purpose is to make the reviewer's job understandable before a release is waiting.

Ownership matters as well. The team should know who reviews a staged version and what happens if that person is unavailable. A new boundary in the release process changes the daily workflow, rather than merely replacing one command in an automation file.

It is also useful to distinguish an approval from a guarantee. A human decision can provide a deliberate checkpoint, but its quality depends on the evidence presented and the attention given to it. A documented purpose makes that decision easier to assess later.

Replacing a token is only part of migration

Before changing the workflow, a team can identify where its publishing credential is used and which release operations depend on it. A limited trial can then establish whether the intended version reaches the review stage and whether the final release follows the expected decision.

The remaining write permissions deserve explicit attention. Blocking direct creation of a new version does not remove the effect of every write operation: tags and deprecation status also affect how package users encounter releases. Understanding that boundary is more precise than treating the change as a blanket safety guarantee.

The feature is opt-in and does not automatically alter existing tokens or their direct-publishing capabilities. Reading the announcement therefore cannot establish that a particular project's automation has migrated. The relevant evidence is its actual configuration and observed behaviour. This report does not claim to have migrated or tested a live publishing workflow.

Sources

• GitHub — stage-only tokens, September 18
• npm Docs — staged publishing