Trusted publishing failures report misleading 404 / ENEEDAUTH errors instead of trusted-publishing diagnostics

Trusted publishing currently fails in a way that is expensive to debug because npm emits generic errors that point users toward the wrong subsystem.

In our GitHub Actions setup, trusted publishing failed in two different ways at different stages:

First, npm returned a 404 while trying to publish an existing package:

npm ERR! code E404
npm ERR! 404 Not Found - PUT https://registry.npmjs.org/bmad-method - Not found
npm ERR! 404
npm ERR! 404  'bmad-method@6.0.5-next.0' is not in this registry.

This was misleading. The package existed in the registry, and npm view bmad-method worked.

Later, after cleaning up token and .npmrc variables, npm returned:

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

That was also misleading, because this was a GitHub Actions OIDC trusted publishing flow, not a manual login/token publish flow.

We verified all of the following:

• the package exists in the registry
• trusted publisher was configured on npm
• the GitHub Actions job had id-token: write
• the repository, workflow filename, ref, and environment matched the trusted publisher configuration
• the runner was GitHub-hosted
• no .npmrc auth config was present
• NODE_AUTH_TOKEN was unset
• GitHub OIDC claims matched the expected repo/workflow/ref/audience values

What finally resolved the issue was upgrading npm in CI to a newer version compatible with trusted publishing. Until then, npm surfaced the problem as either:

• "package not found"
• or "please log in"

Both diagnoses were wrong enough to waste hours.

Why this matters

These error messages cause users to debug the wrong things:

• package existence and naming
• package ownership assumptions
• GitHub secrets and tokens
• .npmrc contamination
• workflow file naming
• trusted publisher configuration recreation
• GitHub OIDC claims

The actual problem can be trusted publishing support or compatibility, but npm reports it as if either the package does not exist or the user forgot to authenticate manually.

That is not just vague. It is directionally wrong.

What npm should do instead

When npm publish is running in a trusted publishing context, npm should provide diagnostics that distinguish between:

• package genuinely not found
• normal token/login auth missing
• trusted publishing not supported by this npm version
• trusted publishing attempted but rejected
• trusted publisher config mismatch
• unsupported runner/environment

At minimum, npm should not emit:

• 404 Not Found implying the package is absent when it is not
• npm adduser guidance when trusted publishing is the intended flow

A practical compromise

If npm intentionally avoids detailed failure reasons in CLI output for abuse-prevention reasons, then package maintainers should still be able to see trusted-publishing diagnostics in the authenticated npm web UI for the package.

For example, package owners/maintainers could be shown the latest trusted publishing failure with details such as:

• trusted publisher match failed
• workflow filename mismatch
• repository mismatch
• environment mismatch
• unsupported npm CLI version
• unsupported runner type
• OIDC token validation failed

Right now, maintainers get the worst of both worlds:

• the CLI exposes only vague or misleading errors like 404 or npm adduser
• the npm UI provides no useful diagnostic trail explaining why trusted publishing was rejected

If failure details cannot safely be exposed to anonymous clients, they should at least be visible to authenticated maintainers on the package's trusted publisher settings page or publish history.

At present the system behaves like a high-security vault whose only diagnostic interface is "door not found."

Start at the npm publish trusted-publishing authentication path used by GitHub Actions and reproduce the reported 404 and ENEEDAUTH outcomes with the stated configuration. The work is done when trusted-publishing failures are distinguishable from missing packages or manual-login failures, with useful diagnostics exposed through the supported interface.