If a coding agent or a CI job publishes packages for you, it holds a token that can put code in front of everyone who installs your package. On September 18, 2026 npm gave that token a narrower shape. A granular access token can now be created as read and write, stage only: the automation submits a version to a staging area, a maintainer approves the release with two-factor authentication, and npm refuses a direct publish with that token even when it was set up to bypass 2FA.
The date that matters more is the one behind it. npm says it is targeting January 2027 to remove direct publishing through bypass-2FA tokens entirely. This post covers what changes and by when, the write permissions a stage-only token keeps, which of three paths fits which team, and why the approval step is the point rather than a nuisance. Every fact about npm is from GitHub's changelog entry and npm's documentation; nothing here generalises to other registries.
- 01Stage-only is a permission on the token, not a setting on the package.You create a granular access token with the new option, swap it into the workflow, and change the publish command to stage. Existing tokens are untouched; the release is opt-in.
- 02The token still moves dist-tags and deprecates versions.GitHub's changelog says so in bold and tells you to protect it like any other write token. Those two actions change what installers receive without publishing anything.
- 03January 2027 is npm's target, not a promise.npm 'is targeting' that month to remove direct publishing through bypass-2FA tokens. Plan for it; do not quote it as a fixed date.
- 04Trusted publishing is the destination; staging is the bridge.GitHub's own wording positions stage-only tokens as the migration path for teams that cannot move to trusted publishing yet. The two also combine: a trusted publisher can stage for review.
01 — The changeWhat changed and by when
Four lines cover it. First, since September 18 a granular access token can carry the permission read and write, stage only. Second, a workflow holding it runs the stage command instead of the publish command, and a maintainer approves the staged version with 2FA from the command line or the website. Third, the release is opt-in and changes nothing about existing tokens. Fourth, npm is targeting January 2027 to remove direct publishing through bypass-2FA tokens. The changelog entry lists the requirements: publish access to the package, 2FA on the account, npm CLI 11.15.0 or later and Node.js 22.14.0 or later.
Stage-only tokens
A new permission on npm granular access tokens; opt-in, existing tokens unchanged.
End of bypass-2FA direct publishing
npm's stated target for removing direct publishing through tokens configured to bypass 2FA.
Plus Node.js 22.14.0
The client versions that understand the stage commands, per the changelog.
02 — The catchWhat a stage-only token still can do
This is the part readers will get wrong, so it comes before the decision. The word "stage only" limits publishing. It does not limit the other writes a package token carries. GitHub states that stage-only tokens retain other package write permissions, including moving dist-tags and deprecating versions, and asks you to protect them with the same care as any other write token.
| Action | Stage-only token | Why it matters |
|---|---|---|
| Publish a new version directly | Rejected | Even if the token was configured to bypass 2FA; the release needs a maintainer's 2FA approval |
| Stage a version for review | Allowed | The token's purpose; the staged tarball can be listed, viewed and downloaded before approval |
| Move a dist-tag | Allowed | Retained write permission; a moved tag changes what a bare install resolves to |
| Deprecate a version | Allowed | Retained write permission; a deprecation warning reaches every installer |
| Read package data | Allowed | The read half of the permission |
Why the two retained writes matter: a dist-tag is what a bare install resolves to, so moving one redirects every installer who did not pin an exact version, and a deprecation prints a warning to every installer. Neither publishes code, but both change what users get or see. A stage-only token is therefore a narrower credential, not a harmless one, and it is no defence against a compromised maintainer account, which is the account that presses approve.
03 — The decisionWho moves to what
Three paths, and the choice depends on where your workflow runs and who can be in the loop. Trusted publishing replaces a long-lived token with a short-lived identity token minted by a supported CI provider, currently GitHub Actions, GitLab CI/CD and CircleCI per npm's documentation. Staged publishing adds a review step to either.
04 — The pipelineThe approval step in an agent pipeline
Picture the pipeline most teams are drifting toward. An agent opens a pull request, tests pass, the change merges, and a job builds and publishes the package. With a direct-publish token, the last step needs no human at all, which is exactly what made it fast and exactly what made a stolen token or a poisoned build step enough to ship malicious code to every installer.
With a stage-only token the shape changes in one place. The job still builds and still runs the stage command, and the staged version sits in npm's staging area with its tarball available for inspection. A maintainer lists it, views it, downloads it if they want to diff it, and approves with a second-factor prompt. The agent did everything up to the boundary and cannot cross it. The boundary is the point: the one action that reaches every user of the package requires a person and a second factor, and an attacker with the automation's credential cannot buy their way past it.
npm rejects direct npm publish attempts with that token, even if you've configured it to bypass 2FA for automation.GitHub changelog, Stage-only npm tokens for safer automation, September 18, 2026
An approval that is always pressed is not a control. Give the maintainer something to check in the minute they have: the diff of the staged tarball against the last release, the commit it was built from, and who or what triggered the build. If the answer to "what changed" is not visible at approval time, the stage step has bought you a delay and nothing else.
05 — The lessonWhat a credential guarantees
This post and our companion post on plugin pinning are about the same thing from two ends. A pin guarantees only what the installer checks after download; a token guarantees only what the registry refuses. In both cases the safe question is not "is it pinned" or "is it scoped" but "what, exactly, is still allowed". For npm the answer after September 18 is: staging, dist-tag moves, deprecations, and reads. Write that list next to every token your automation holds.
The install side of the same supply chain, what npm 12 blocks at install time and how an import-time attack works, is covered in our npm 12 install-scripts guide and our post on the AsyncAPI import-time attack. If your team is wiring agents into release pipelines, our AI transformation service designs the approval boundary before the automation, not after.
06 — Next stepThe narrower token still writes; only the publish now needs a person
List every automation token that can publish, then replace each one before January
Inventory the tokens your CI jobs and agents hold and mark which can publish directly. Move the ones on a supported provider to trusted publishing. Give the rest a stage-only token and a named approver. Then write down, beside each token, that it can still move tags and deprecate versions, and rotate it on the same schedule as before.