GitHub lets npm trusted publishers manage dist-tags with OIDC, if enabled

GitHub has added an opt-in permission that lets npm trusted publishing configurations manage dist-tags using short-lived OIDC credentials rather than a long-lived access token, according to a changelog post dated September 30, 2026.

Dist-tags are the named pointers, such as latest, next and beta, that say which package version a label refers to. GitHub's examples include promoting a version to latest or updating the next and beta pointers.

What is new is the coverage. Trusted publishing previously handled publishing and staging but not dist-tag operations. GitHub says that left maintainers who had otherwise moved to token-free, OIDC-based workflows holding a granular access token solely to manage tags after a release or a rollback.

Each trusted publishing configuration now carries an "Allow npm dist-tag" permission. According to GitHub, it is off by default for both new and existing configurations, so no configuration gains the capability automatically. The permission is independent of direct publishing, so a staging-only configuration can also be granted tag management.

GitHub describes the rule this way: a dist-tag operation is authorized if the incoming OIDC token matches any one configuration that has the permission enabled. Existing token-based dist-tag management continues to work unchanged. To use the feature, a package administrator opens the package's trusted publishing settings and enables the permission on the configurations that should manage tags.

What is confirmed and what is not: everything above comes from GitHub's own announcement, the only credible source we found. A search turned up a third-party write-up, but it only restates the changelog, so it is not independent confirmation. We have not tested the setting, and the post does not say whether the npm command line exposes it or how it behaves in cases beyond the "any one configuration" rule.

Why it matters: tag changes decide which version people get when they install latest or a pre-release channel, so removing a stored token from release pipelines gives an attacker less to steal. The tradeoff is that any workflow whose identity matches an enabled configuration can then move tags, so administrators may want to enable it only where needed. That is our reading, not a GitHub claim.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. The earlier version remains available as revision 1.