Setting up trusted publishing and leaving the first release until next week can now produce a failed npm publish. The trust relationship has a validation deadline.
Under npm's 2 October 2026 change, an unvalidated trusted publishing configuration expires 48 hours after creation and can no longer authorise publishing.
The first successful publish validates it
Once the configuration completes its first successful publish, it is validated and exempt from this expiry. Changing the repository or project identity requires a new relationship with a fresh validation window. Ordinary edits do not restart the deadline.
An expired configuration remains visible in settings, but no longer counts towards per-package limits. npm says other valid configurations on the same package are unaffected. Recreating the expired configuration starts a new window.
The stated purpose is to limit the risk of trusting a repository or project name that later changes ownership.
Schedule setup and validation together
For a team preparing a new release pipeline, plan the configuration step alongside an authorised first publish. Creating the relationship long before the release is ready makes it easier to miss the window.
Keep a small setup record: package, repository or project, workflow identity, owner and validation result. That gives someone investigating a failed job a place to start.
If the first publish fails, establish whether the cause is an expired relationship, incorrect identity or a different release error. Repeatedly recreating the configuration without checking the failure wastes time and can hide a wrong setting.
Check the event that starts the job
The same update rejects trusted publishing tokens from GitHub Actions issue_comment events, alongside the existing pull_request_target restriction. It lists push, release and workflow_dispatch as permitted alternatives.
For your workflow, choose a trigger that matches the release process and its access controls. Moving a job to another event also changes who can start it and which code it runs.
Review those details before making the change. A technically permitted trigger still needs appropriate repository permissions and a clear approval process.
Review ownership when projects move
Repository transfers, renamed projects and a change in maintainers are natural moments to revisit publishing access. Confirm that the people responsible for the package still control the configured release source.
Also review any older token-based release route left behind during the move to trusted publishing. An unused route can become an overlooked source of access.
Our suggested outcome is a release process with a known owner, a validated configuration and a tested trigger. Keep the evidence with the package's maintenance records so future staff do not have to infer how publishing was meant to work.
Reporting checked on 13 October 2026.
