npm Trusted Publishing Has a 48-Hour First-Publish Deadline
You set up npm trusted publishing a few days before launch, and the first release fails authentication with nothing changed. What do you redo, and will it happen again?
- A new npm trusted publisher configuration expires after 48 hours without a successful first publish.
- Validated configurations do not need periodic recreation under this rule.
- GitHub Actions comment events face a separate restriction on publishing authentication.
The deadline validates a new trust relationship
Registering a trusted publisher days before its first release can leave it expired when needed. npm’s October 2 announcement gives unvalidated configurations 48 hours from creation. A successful first publish removes that expiry condition.
This is separate from the lifetime of a job’s authentication tokens. In GitHub’s OIDC model, the workflow presents evidence of its identity, and the external provider validates it before issuing short-lived credentials. The workflow is not repeatedly submitting a stored, long-lived secret.
A configuration’s initial validation deadline therefore does not mean a package needs a new release every two days.
Replace an expired configuration
The npm expiry documentation directs maintainers to delete the expired configuration and create another. Saving a configuration is not successful validation, and ordinary edits do not reset the deadline.
| State | Meaning |
|---|---|
| New; no successful publish | The initial validation window is running. |
| First publish succeeded | The configuration is exempt from this initial expiry. |
| Deadline passed without validation | Replace the expired configuration. |
A practical approach is to prepare the release path before creating the trust configuration, then validate it through the intended release. There is no need to manufacture an otherwise unnecessary version just to meet a deadline.
Comment-triggered publishing has another problem
npm now rejects trusted publishing tokens from issue_comment, in addition to the existing pull_request_target restriction. An unexpired configuration does not remove that event restriction.
The announcement identifies push, release, and workflow_dispatch as permitted alternatives. For a manual release, GitHub’s event reference requires the workflow file on the default branch and a configured manual trigger. This changes which publishing credentials npm accepts; it does not disable comment workflows on GitHub.
A saved form does not prove the workflow works
npm does not validate the configuration when it is saved. Match the repository and workflow filename exactly, including case, and grant id-token: write. GitHub Actions trusted publishing requires GitHub-hosted runners; self-hosted runners are currently unsupported.
The workflow’s identity must match the registered trust conditions. When diagnosing a failure, examine three separate things: whether initial validation expired, whether the trigger is permitted, and whether the workflow is configured correctly.
Frequently asked questions
Does a previously successful configuration expire every 48 hours?
No. The first successful publish validates it and exempts it from this initial expiry.
Can saving an edit extend the deadline?
No. Ordinary edits do not restart it. Delete and recreate an expired configuration.