npm trusted publisher still visible but expired? The 48-hour window and recovery steps

The 48-hour rule does not apply to every npm token

GitHub announced on October 2, 2026 that an npm trusted publishing configuration that has not been validated expires 48 hours after creation. Its first successful publish validates it and exempts it from expiry. Other valid configurations are unaffected.

Trusted publishing authorizes package publication using short-lived workflow identity credentials, avoiding a long-lived write token for that step. The item that expires here is an unvalidated trust configuration, not every npm account, package or token. The announcement says the change reduces the risk of stale trust when a repository or project name changes ownership.

For a hypothetical example, suppose you create a connection on Monday morning but do not attempt its first publish until Thursday, with no successful publish in between. Check whether it has expired before proceeding. The example shows why creation time matters: ordinary edits and saving again do not restart the deadline.

Confirm expiry before treating a queued runner as an authentication failure

Record the target package, repository, connection creation time and whether it has ever published successfully. Inspect the original workflow run. A publishing step that ran and reported an authentication error is a different investigation from a job that has not yet obtained a runner. Queue time alone is no reason to delete a connection.

Expired configurations still appear in trusted publisher settings, but no longer authorize publication and do not count toward per-package limits. The npm documentation adds that an expired configuration cannot be used or edited: delete it and create a new one. Saving a connection does not validate whether its fields are correct, so a successful save is not proof that identity validation passed.

Step 1: identify the exact connection in the target package settings

A maintainer with permission to manage the package settings should open Packages on npmjs.com, select the target package, then open Settings → Trusted publishing. Use creation time, the connected repository and actual publishing history to identify the connection. Keep other valid connections; do not reset every connection on the package.

For GitHub Actions, the required fields are Organization or user, Repository and Workflow filename, with an optional Environment name. Enter only the workflow filename with its .yml or .yaml extension, and ensure the file really exists under .github/workflows in the repository. Case and identity must match exactly.

Step 2: recreate the expired connection and check runner support

Once you have confirmed that the target connection expired, delete it, then choose the provider through Add trusted publisher and create a new connection. That connection has a fresh 48-hour window. A repository or project identity change also requires a new trust relationship. The provider and required fields of an existing connection are fixed; editing in place cannot extend its lifetime.

The current documentation requires npm CLI 11.5.1 or later and Node 22.14.0 or later. Supported platforms are GitHub-hosted runners for GitHub Actions, GitLab.com shared runners and CircleCI cloud. Self-hosted runners are not currently supported; planned support is not current availability. Recreating a configuration cannot fix an unsupported runner environment.

Check Allowed actions against your existing release policy as well. Permission for npm stage publish does not automatically allow direct npm publish or dist-tag management; those permissions are independent. Do not broaden connection permissions merely to complete a publish before the window closes.

Step 3: verify the first successful publish

Schedule the first publish within your normal release process, retaining tests, builds, review and required approvals. GitHub Actions needs id-token: write, and repository.url in package.json should match the actual GitHub repository exactly. The configured calling workflow and package name must match too. Do not rush out a meaningless version just to beat the window.

Then inspect the actual publishing step and the target package records to confirm the package name, version, connection used and successful result. The first successful publish validates the configuration and binds it to the immutable identity of the repository. Saving settings, starting a job or entering a staged queue does not mean a version is publicly installable. Staged publishing must still follow its maintainer-approval process.

Publishing triggered by issue_comment also needs attention

The same announcement adds rejection of trusted publishing tokens from GitHub Actions issue_comment events. The existing pull_request_target restriction still applies. This is npm restricting the events that supply these tokens; GitHub has not disabled both events across the platform.

Affected maintainers can review migration to a permitted event such as push, release or workflow_dispatch while retaining their original approvals and tag protections. A permitted event does not automatically resolve an identity or permission mismatch. For reusable workflows, the current documentation requires checking the calling workflow name and id-token: write permissions in both parent and child workflows.

If recreation still fails, narrow the issue to the actual publishing step

Follow the official troubleshooting guidance to check the exact workflow filename, case-sensitive fields, repository.url, OIDC permissions and cloud-hosted runner. OIDC is how the workflow proves its identity to npm. Repeatedly triggering runs, disabling release gates or adding a long-lived write token should not be the default solution.

Keep the connection creation time, the first successfully published version and the run link. Share only redacted status information when seeking help. The announcement does not promise a universal error code, an exact rollout time or a recovery duration; check the logs for the step that actually failed. This guide explains public rules and operating limits; it has not published a real package.