npm trusted publishing configurations now expire after 48 hours, and issue_comment workflows can no longer publish

npm's trusted publishing lets a CI workflow publish a package with a short-lived OIDC token instead of a stored npm token. You tell the registry which repository and workflow file to trust, and from then on that workflow can publish. As of an October 2 GitHub changelog entry, that trust has a clock on it until it is first used, and one more GitHub Actions trigger can no longer use it at all.

Forty-eight hours to prove the configuration

The changelog entry is short and specific: "Unvalidated npm trusted publishing configurations now expire 48 hours after creation and can no longer authorize publishing." GitHub gives one reason: "This limits the risk of trusting a repository or project name that changes ownership."

The npm documentation explains what "validated" buys you. Its section on configuration expiry says: "The first successful publish validates the configuration and binds it to the repository's immutable identity."

That sentence is the whole story. Spelled out (this is our reading of GitHub's one-line reason): until the first publish, the configuration points at a repository by name, and names can change hands. A configuration created for a repository that is later renamed, transferred or deleted and re-registered by someone else would have kept authorizing whoever held that name. After the first publish, the binding follows the repository itself, not its name. The 48-hour window caps how long a configuration can sit in the name-only state.

The rules around the window, all from the same entry:

• "Your configuration becomes validated and exempt from expiry after its first successful publish."
• Changing the repository or project identity starts a new trust relationship with a fresh 48-hour window, while ordinary edits "don’t restart the deadline."
• "Expired configurations remain visible in trusted publisher settings but don’t count toward per-package limits. Other valid configurations on the package are unaffected."

On recovery, the npm docs are blunter than the changelog: an expired configuration "can no longer be used or edited," and the fix is to "delete the expired configuration, create a new one, and complete the first publish within 2 days."

issue_comment joins pull_request_target on the blocked list

The second change in the entry closes a different door: "npm also now rejects trusted publishing tokens from GitHub Actions issue_comment events, alongside the existing pull_request_target restriction." The suggested fix is to "move publishing to a permitted event such as push, release, or workflow_dispatch."

GitHub does not explain this one, so what follows is inference. Both blocked triggers run in the context of the base repository and can be started by people who are not maintainers: anyone who can open a pull request, or anyone who can comment on an issue. A publish step reachable from either is a publish step a stranger can set in motion. If your release flow is a "/release" comment bot, it stopped working on October 2.

The same day: staged publishing for brand-new packages

A second entry, also dated October 2, closes a gap in npm's staged publishing. "You can now create a new npm package with npm stage publish, using a local session or a granular access token, including a stage-only token." Previously a new package needed a manual first publish. Now: "Your first version enters the staged queue and requires a maintainer to promote it before that version becomes available to install."

This builds on a September 3 entry that made staging the default for trusted publishers ("Every trusted publishing configuration can stage a package by default. Direct publishing is opt-in per configuration.") and added a malware-scan gate: "the approval button is now disabled while a package is still being scanned."

What to check

If you set up a trusted publisher and have not yet published through it, do it within two days or plan to recreate it. Search your workflows for issue_comment or pull_request_target on any job that runs npm publish or npm stage publish. And if your configurations still allow direct publishing, the September 3 entry states GitHub's own preference plainly: "We recommend keeping your configurations to staging only."

Primary sources: GitHub Changelog: Unvalidated npm trusted publishing configurations now expire, GitHub Changelog: npm staged publishing now supports creating new packages, GitHub Changelog: Multiple trusted publishing configurations for npm, npm Docs: trusted publishers, read 2026-10-16.