npm now allows multiple trusted publishing configurations per package

GitHub on September 3 made three npm trusted publishing changes generally available, all aimed at removing the last cases where maintainers had to keep a long-lived publish token as a fallback.

What changed

A package can now have more than one trusted publishing (OIDC) configuration. Before, each package was limited to one, so a maintainer with a stable channel, a prerelease channel and a staging channel had to send them through the same workflow or keep a legacy token for the paths OIDC could not cover. Each configuration is independent and additive, with its own repository, workflow and environment criteria, added, listed and removed from the package settings page. A publish or stage is authorized if the incoming OIDC token matches any single configuration. Configurations never restrict one another, and the evaluation order is not guaranteed, so maintainers should not build logic that depends on which configuration matched.

Every trusted publishing configuration can stage a package by default. Direct publishing is opt-in per configuration, and GitHub recommends keeping configurations to staging only. Staged publishing adds a human approval step before a version becomes available on the registry, so a compromised workflow cannot publish directly.

The second change ties staging to the malware scanner that npm rolled out earlier this summer. Packages are already scanned before they become available. In the staged publishing queue, the approval button is now disabled while a package is still being scanned and re-enables once the scan completes. The page refreshes status every minute, so a reviewer waiting on a scan does not have to guess when it is safe to click.

The third change is a per-version history: the versions tab on npmjs.com now shows the respective maintainers a detailed log for each version, including whether it was approved, rejected or still staged.

The interesting one is the first. Long-lived npm tokens have been the hardest part of package publishing to remove, because a single-config limit forced any package with more than one release path to keep one around. Removing that limit lets a maintainer finish work they could usually only get eighty per cent of the way through: delete the tokens, and rely on short-lived OIDC identity for every publish.

For a team that already publishes with GitHub Actions, the mechanical work is small. Add a second configuration on the package settings page, set it to the workflow, repository and environment for the release path that was still on a token, and delete the token. Keeping every new configuration on the staging path is the safer default: if a workflow is ever compromised, the human approval step is what stops a version from reaching users, and it costs one click per release.

Source

• Multiple trusted publishing configurations for npm, GitHub Changelog, September 3, 2026.