GitHub said on October 2, 2026 that npm trusted publishing configurations which never complete a publish now expire 48 hours after they are created, and that the npm registry no longer accepts trusted publishing tokens from GitHub Actions workflows triggered by issue_comment events. Package maintainers who have set up trusted publishing but not yet used it, or who publish from comment-triggered workflows, need to make changes.

According to the changelog entry, an unvalidated configuration “can no longer authorize publishing” once its 48-hour window has passed. A configuration counts as validated, and is exempt from expiry, after its first successful publish. Changing the repository or project identity behind a configuration requires a new trust relationship with a fresh 48-hour window, while ordinary edits do not restart the deadline.

Expired configurations stay visible in a package’s trusted publisher settings but no longer count toward per-package limits, and other valid configurations on the same package keep working. A maintainer whose configuration lapses can recreate it, which starts a new 48-hour window.

Comment-triggered workflows blocked

The second rule extends an existing restriction. npm already refused trusted publishing tokens from workflows triggered by the pull_request_target event, and it now also rejects tokens from issue_comment events. GitHub advised affected users to move publishing to a permitted event, such as push, release or workflow_dispatch.

The changelog entry does not state a reason for either change. It links to an npm roadmap discussion on GitHub’s community forum for feedback.

New packages can now be staged

In a second changelog entry the same day, GitHub said npm’s staged publishing feature now supports creating new packages. Maintainers can create a package with the npm stage publish command, authenticating with a local session, a granular access token or a stage-only token. The feature covers public scoped packages, public unscoped packages and private scoped packages.

The first version of a package created this way enters a staged queue, and a maintainer must promote it before anyone can install that version. Once the package exists, maintainers can manage its settings and configure trusted publishing. GitHub said the change lets automated workflows create packages “without a manual first publish.”

Part of a wider tightening

Both changes follow a roadmap post that npm’s product manager published on GitHub’s community forum on September 17. The post said granular access tokens that bypass two-factor authentication (2FA) will lose the ability to publish versions directly, with direct publishing using those tokens ending in January 2027. It offered maintainers two routes instead: a stage-only token combined with 2FA approval, or trusted publishing, which the post describes as a way to publish from automation without relying on a stored token.

The post and the changelog entries linked from it list other measures npm introduced earlier in 2026. Staged publishing became generally available on May 22, publish-time malware scanning arrived on July 28, and support for multiple trusted publishing configurations per package followed on September 3. On September 9, npm extended security holds to all accounts, so that signing in with a recovery code triggers a 72-hour hold on publishing and other sensitive changes.

The roadmap also said npm is not planning additional trusted publishing provider integrations for the rest of 2026, and that it intends to expand provider support in 2027 after prioritizing staged publishing that does not depend on a particular provider.

Why it matters

The 48-hour rule means a trusted publishing configuration created ahead of a planned move away from long-lived tokens, and then left unused, will stop working. Maintainers who create a configuration need to complete a first publish within two days or recreate it later. Projects that start releases from comments on issues or pull requests need to switch their publishing jobs to one of the permitted events.

The roadmap frames this year’s changes as separating what automation can prepare from who can authorize a release, so that holding a token in a continuous integration (CI) system is no longer enough on its own to publish. Staged creation of new packages follows that model: an automated workflow can create the package, but a maintainer still has to promote its first version before it reaches users.

What to watch

The next fixed date is January 2027, when direct publishing with bypass-2FA tokens ends. The roadmap lists stage-only granular access tokens, which were in preview when it was posted, opt-in trusted publishing permissions including dist-tag operations, batch approval and a combined activity view for staged approvals among npm’s priorities for the rest of 2026. The post describes these as priorities rather than delivery dates.

Corrections and tips: email the editor using the address on the Contact page.