npm Trusted Publishing fails with ENEEDAUTH / need auth This command…

Symptom

A GitHub Actions job that publishes with npm Trusted Publishing (OIDC, no token) fails at npm publish:

npm error code ENEEDAUTH
npm error need auth This command requires you to be logged in to https://registry.npmjs.org/
npm error need auth You need to authorize this machine using `npm adduser`

The workflow has permissions: id-token: write, there is deliberately no NPM_TOKEN, and the message sends you looking for a token you are not supposed to have.

When it happens

npm (11.5.1 or newer is required for trusted publishing, per npm's documentation) first asks GitHub for an OIDC ID token (audience npm:registry.npmjs.org), then exchanges it at POST /-/npm/v1/oidc/token/exchange/package/<name>. If the registry refuses, npm drops the refusal and continues without credentials, which ends in ENEEDAUTH. The registry refuses when it has no trusted-publisher entry for the package that matches the run's claims:

• no trusted publisher saved for the package at all (in our case the web form had not saved — npm trust list <pkg> came back empty);
• workflow file name differs (the entry names publish.yml; the job runs from release.yml, or from a reusable workflow);
• environment differs: entry says npm, job has no environment: (claim is empty) or another name — or the reverse;
• repository owner/name differs (renamed or transferred repo, or a fork/mirror);
• the kind of publish is not allowed for that entry (direct publish vs. staged publish are separate permissions in current npm).

Other variants of the same root problem:

• no id-token: write → npm never tries OIDC; plain ENEEDAUTH, no exchange line in the verbose log;
• actions/setup-node with registry-url: writes an .npmrc that uses NODE_AUTH_TOKEN. When a (placeholder) token is present, npm falls back to it after the refused exchange and the failure becomes E404 Not Found - PUT https://registry.npmjs.org/<pkg> instead (reproduced with a placeholder token against the local stand-in). Leave registry-url out for OIDC publishing.
• a brand-new package: the first version could not be published from CI in our setup; the owner published it once by hand, then added the trusted publisher.

Cause

Registry answer to the exchange is 404 {"message":"package not found"} — in our case the package existed; the message was the answer to "no matching trusted publisher", so do not take it literally. npm logs it only at verbose level:

npm http fetch POST 404 https://registry.npmjs.org/-/npm/v1/oidc/token/exchange/package/<pkg>
npm verbose oidc Failed token exchange request with body message: package not found
npm error code ENEEDAUTH

A successful exchange answers 201 with a short-lived token.

Fix

1. Register (or re-register) the trusted publisher from the CLI and check it, rather than trusting the web form:

   npm trust github <pkg> --file publish.yml --repo <owner>/<repo> --env npm --allow-publish --yes
   #   add --allow-stage-publish if the workflow uses `npm stage publish`
   npm trust list <pkg>

--file is the workflow file name only (inside .github/workflows/), not a path. It needs a maintainer login with 2FA; we ran it in a throwaway node:24 container with -e npm_config_browser=false so the auth URLs print instead of opening a browser.

1. Make the job match exactly what you registered:

   jobs:
     publish:
       environment: npm            # must equal --env
       permissions:
         contents: read
         id-token: write
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with: { node-version: "24" }   # no registry-url
         - run: npm install -g npm@^11.5.1
         - run: npm publish --access public --provenance

1. Add a diagnosis step before publishing that performs the exchange itself and prints the claims npm is matched against (claims are not secret; mask the token):

   idt=$(curl -sf -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
     "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=npm:registry.npmjs.org" | jq -r .value)
   echo "::add-mask::$idt"
   echo "$idt" | cut -d. -f2 | base64 -d 2>/dev/null | jq '{repository, workflow_ref, environment, ref}'
   curl -s -o /dev/null -w '%{http_code}\n' -X POST -H "Authorization: Bearer $idt" \
     "https://registry.npmjs.org/-/npm/v1/oidc/token/exchange/package/$(jq -r .name package.json)"
   # 201 = trusted; 404 = compare the claims above with `npm trust list`

(JWT payloads are base64url without padding; if base64 -d complains, decode with node: node -e 'console.log(Buffer.from(process.argv[1].split(".")[1],"base64url").toString())' "$idt".)

Verify

• npm trust list <pkg> shows one GitHub entry with the same repository, workflow file and environment as the job.
• The diagnosis step prints HTTP 201.
• npm view <pkg>@<version> shows the version; with --provenance from a public repository the package page shows a provenance attestation (provenance is not available from private repositories).

Notes (what did not help)

• Adding NODE_AUTH_TOKEN/registry-url "to fix auth" only changes the error to E404 on PUT.
• Re-running the job: the claims are the same, so the answer is the same (the stand-in reproduction shows npm makes the same exchange each run). After a failed tag run where nothing reached npm, delete and re-push the tag once the trust entry is fixed.
• The npm account name and the GitHub owner do not need to match.
• npm access get mfa does not exist (npm 11.19.0: get mfa is not a valid access command; only npm access set mfa=none|publish|automation); check the package's 2FA setting on its web settings page.