Between September 3 and October 2, 2026, GitHub announced three changes to npm trusted publishing. Trusted publishing lets a CI workflow publish a package with a short-lived OpenID Connect (OIDC) credential instead of a stored access token. On September 3, packages gained support for more than one trusted publishing configuration, with staging as the default. On September 30, configurations gained an opt-in permission to manage dist-tags. On October 2, unvalidated configurations began to expire after 48 hours, and npm began rejecting tokens from one more GitHub Actions event.
What changed
- Multiple configurations. A package can now have more than one trusted publishing configuration, each with its own repository, workflow, and environment criteria. Before, a package was limited to one. GitHub says "A publish or stage is authorized if the incoming OIDC token matches any one configuration." It also warns that "evaluation order is not guaranteed, so don't build logic that depends on which configuration matches."
- Staging first. "Every trusted publishing configuration can stage a package by default." "Direct publishing is opt-in per configuration." A staged version needs a person to approve it before it becomes available, and the approval button stays disabled while npm's malware scan of the package is still running.
- Dist-tag permission. Dist-tags are the labels, such as latest, next, or beta, that point to a specific version. A configuration can now be allowed to manage them with a setting labeled "Allow npm dist-tag." It is off by default for new and existing configurations, and token-based dist-tag management is unaffected.
- Expiry. "Unvalidated npm trusted publishing configurations now expire 48 hours after creation and can no longer authorize publishing." A configuration becomes validated, and exempt from expiry, after its first successful publish. Changing the repository or project identity requires a new trust relationship with a fresh 48-hour window. GitHub says the expiry "limits the risk of trusting a repository or project name that changes ownership."
- Event restriction. npm now rejects trusted publishing tokens from GitHub Actions issue_comment events, in addition to the existing pull_request_target restriction.
Who is affected
Any team that publishes npm packages from CI with trusted publishing should check three things. A configuration that is created but not used to publish within 48 hours stops working and must be recreated. A workflow that publishes from an issue_comment event, such as a release started by a comment, now fails and must move to an allowed event such as push, release, or workflow_dispatch. And a team that kept a long-lived token only to move dist-tags can now plan to retire it.
What to do
- Build an inventory. For each package, list its trusted publishing configurations from the package settings on npmjs.com and note which repository, workflow, and environment each one trusts.
- Validate new configurations promptly. After you create a configuration or change its repository or project, run a publish within 48 hours, or plan to recreate it. Expired configurations stay visible in the settings, so check each one's status rather than assuming it works.
- Search your workflow files for publish jobs triggered by issue_comment or pull_request_target, and move them to an allowed event such as push, release, or workflow_dispatch.
- Decide which configurations may publish directly. GitHub recommends "keeping your configurations to staging only," because staging adds a human approval step. Opt a configuration into direct publishing only where you have a reason, and keep that workflow narrow.
- Limit dist-tag rights. Because a matching configuration is enough to authorize an action, every configuration with "Allow npm dist-tag" turned on can move latest. Enable it only where automation needs it, then remove the token you used for tags.
- Plan for scan time. GitHub says publish-time scanning typically adds about five minutes, possibly 15 minutes or more, and that these times are not a service guarantee. Release runbooks should not assume a version is installable the moment publishing finishes.
- Review configurations whenever a trusted repository is renamed, transferred, or deleted, and remove any that no longer point to a repository you control.
These changes move npm publishing toward short-lived credentials and human approval. For most teams the work is small: confirm each configuration is validated, move publish jobs off restricted events, and retire tokens that the new permissions make unnecessary.
Sources
- GitHub Changelog: Unvalidated npm trusted publishing configurations now expire (October 2, 2026)
- GitHub Changelog: Opt-in dist-tag permissions for npm trusted publishing (September 30, 2026)
- GitHub Changelog: Multiple trusted publishing configurations for npm (September 3, 2026)
- GitHub Changelog: npm publish-time malware scanning and dual-use metadata (July 28, 2026)