npm Trusted Publishing Configurations Now Expire After 48 Hours Unless Validated, and issue_comment Tokens Are Rejected

Overview

GitHub announced in an October 2, 2026 changelog entry that, according to the GitHub Changelog, “Unvalidated npm trusted publishing configurations now expire 48 hours after creation and can no longer authorize publishing.” The entry is filed under the Retired label and the supply chain security topic. It also describes a second change: npm now rejects trusted publishing tokens that originate from a particular kind of GitHub Actions event.

What Changed

• 48-hour expiry. The GitHub Changelog says the change “limits the risk of trusting a repository or project name that changes ownership.”
• How a configuration becomes safe from expiry. Per the same entry, a configuration “becomes validated and exempt from expiry after its first successful publish.”
• Identity changes restart the clock. According to the GitHub Changelog, changing the repository or project identity requires a new trust relationship with a fresh 48-hour validation window, while ordinary edits do not restart the deadline.
• Recovery. A configuration that expires can be recreated to start a new 48-hour window, the GitHub Changelog says. Expired configurations remain visible in trusted publisher settings but do not count toward per-package limits, and other valid configurations on the package are unaffected.
• Event restriction. The GitHub Changelog says npm “now rejects trusted publishing tokens from GitHub Actions issue_comment events, alongside the existing pull_request_target restriction.” Affected maintainers are told to move publishing to a permitted event such as push, release, or workflow_dispatch.

Related npm Changes From the Same Week

The entry follows other trusted-publishing and staging changes announced by GitHub in recent days. On October 2, the GitHub Changelog said a new npm package can now be created with npm stage publish, using a local session or a granular access token, including a stage-only token. Per that entry, the first version “enters the staged queue and requires a maintainer to promote it before that version becomes available to install,” and trusted publishing can be configured after the package exists. The Machine Herald previously reported on the staged-publishing workflow in connection with npm CLI 11.15.0.

On September 30, the GitHub Changelog said each trusted publishing configuration now has an opt-in “Allow npm dist-tag” permission that “defaults to off for both new and existing configurations, so no configuration automatically gains new capability.” It added that previously, trusted publishing covered publishing and staging, but not dist-tag operations. A pnpm release adding dist-tag OIDC support was covered earlier this month.

What We Don’t Know

• The changelog entry does not say how many existing trusted publishing configurations were unvalidated when the change took effect, or how many have already expired.
• It does not describe an incident that prompted the change; it gives the ownership-transfer risk as the rationale.
• It does not say whether other CI providers are affected by the event restriction, which it describes only for GitHub Actions.

Analysis

Taken together, the three entries show GitHub narrowing how long an unused trusted publishing link stays valid and which Actions events can use it, while extending the OIDC-based flow to more tasks, such as dist-tag management and first-time package creation through staging. Maintainers who set up a trusted publisher and then delay the first release should expect to recreate the configuration if the 48-hour window lapses.