NPM_TOKEN is invalid — the next real release will fail at verifyConditions

[jamlen]

Summary

The NPM_TOKEN repository secret is rejected by the npm registry. The next commit to main that actually triggers a release (feat:, fix:, perf:, refactor:, revert:, docs(README):) will fail before publishing.

Evidence

Release run on main for #131 (run 31635670403):

[@semantic-release/npm] › ℹ  Verifying OIDC context for publishing from GitHub Actions
[@semantic-release/npm] › ℹ  OIDC token exchange with the npm registry failed: 404 OIDC token exchange error - package not found
[@semantic-release/npm] › ℹ  Verify authentication for registry https://registry.npmjs.org/
npm error code E401
npm error 401 Unauthorized - GET https://registry.npmjs.org/-/whoami
✘  Failed step "verifyConditions" of plugin "@semantic-release/npm"
✘  EINVALIDNPMTOKEN Invalid npm token.

A 401 on /-/whoami is unambiguous — the token is expired, revoked, or malformed.

Why this has gone unnoticed

Every recent Release run reported success without ever validating the token, because semantic-release bails before verifyConditions when there is nothing to release. From the run immediately prior (31635364792):

ℹ  The local branch main is behind the remote one, therefore a new version won't be published.

That run never reached the npm plugin. Same for the chore: / ci: commits before it — all green, none exercising the token. The last genuine publish was deride@2.2.0 (npm latest) back in April, when the token still worked.

So the green checkmarks on the release workflow are not evidence that releasing works.

Not caused by the semantic-release 25 upgrade

The upgrade in #129 is what surfaced this, but it is not the cause. The 401 comes from npm whoami against the registry — no semantic-release version affects that. The earlier runs simply exited before getting there.

Worth noting the log line above it: OIDC token exchange ... 404 - package not found. npm trusted publishing is not configured for this package, so the token path is the only path.

Fix

1. Mint a new npm automation token with publish rights (and provenance, per CLAUDE.md) and replace the NPM_TOKEN secret.
2. Optionally, configure npm trusted publishing (OIDC) for deride so the workflow stops depending on a long-lived token at all. @semantic-release/npm already attempts the OIDC exchange first, so this would need no workflow change — only registry-side configuration.
3. Consider making the release dry-run actually exercise verifyConditions, so an invalid token is caught on a PR rather than at release time.

Related

• Release-time versioned docs are deployed to a branch GitHub Pages no longer serves #132 — release-time versioned docs are deployed to a branch Pages no longer serves. Both are cases of the release pipeline appearing healthy while a step silently does nothing.

[jamlen]

Investigated the fix path. Short version: staged publishing won't fix this — trusted publishing (OIDC) will. The instinct to stop using a long-lived token is right; the feature name is the thing to swap.

• Trusted publishing (OIDC) — replaces the token with a short-lived, workflow-scoped credential. Fixes this issue.
• Staged publishing — a 2FA review gate (npm stage publish → maintainer approves). Per the docs it complements trusted publishing and explicitly does not remove the need for a token. It would also make every release require manual approval, turning semantic-release from automated into human-gated. Reasonable to want, but a separate decision.

#136 does the repo-side half. Two findings from it worth recording here:

1. id-token: write was already granted, and the OIDC exchange is already being attempted — that's the Verifying OIDC context for publishing from GitHub Actions line in the failing log. The 404 ... package not found is the registry saying no trusted publisher is configured for deride. So the tooling is ready; only the registry-side config is missing.

2. npm CLI >= 11.5.1 is required, and the release job doesn't have it. Node 22 bundles npm 10.9.8 (checked against nodejs.org/dist/index.json). This would have bitten after configuring OIDC, which is the worst time to find it.

The reason is subtle. @semantic-release/npm@13.1.5's lib/verify-auth.js:

if (await oidcContextEstablished(registry, pkg, context)) {
  return;                                   // ← no token written to .npmrc
}
await setNpmrcAuth(npmrc, registry, context);
await verifyTokenAuth(registry, npmrc, context, pkgRoot);

The exchanged token is only a boolean probe — oidcContextEstablished returns !!token and throws it away. lib/publish.js then runs npm publish --userconfig <npmrc> against an npmrc with no credentials, so npm itself must redo the OIDC exchange. An npm that can't do that arrives with nothing. #136 adds an explicit npm upgrade for this.

Remaining step — needs npmjs.com login + 2FA

npmjs.com → deride → Settings → Trusted Publisher → GitHub Actions:

Field	Value
Organization or user	guzzlerio
Repository	deride
Workflow filename	release.yml
Environment	(empty)
Allowed actions	npm publish

The config pins the workflow filename — renaming release.yml later breaks publishing.

Rollout

Merging #136 doubles as a safe live test: verifyConditions runs before commit analysis, so the OIDC exchange is exercised on every push to main, but it's a ci: commit so nothing publishes. Look for OIDC token exchange with the npm registry succeeded.

Then #135 (v3.0.0) over the proven path, and only after that succeeds, delete the NPM_TOKEN secret. It's retained as fallback until then.

Aside

Provenance was never actually enabled, despite CLAUDE.md claiming the token needed provenance rights — nothing passes --provenance, there's no publishConfig, and deride@2.2.0 has no attestations. Trusted publishing generates it automatically, so this fixes that too.