Trusted Publishers settings silently revert — the form never persists

[trendai-au]

🏷️ Discussion Type

Bug

Body

Configuring OIDC Trusted Publishing on a package appears to succeed but never saves, leaving long-lived granular tokens as the only working option.

Steps

1. Package settings → Publishing access → Trusted Publishers
2. Choose GitHub Actions, fill in repository owner, repository name and workflow filename
3. Click Update Package Settings
4. Authenticate at the 2FA prompt (security key)

Expected

The trusted publisher is registered.

Actual

The page reports package scope updated!, but the trusted-publisher fields are empty again, and a reload confirms nothing was stored.

The package access portion of the same form (public/private, 2FA requirement) saves correctly — only the trusted-publisher fields are lost. It looks like those inputs are cleared when the 2FA modal opens, so the submit that follows carries only the package-access values.

Environment / notes

• Chrome 150, Windows 11
• 2FA method: security key
• Reproduced by hand and via browser automation, with identical results
• Nothing in the browser console beyond the successful request
• Granular access tokens work fine on the same account, so the account, the security key and the 2FA flow are all healthy — this is specific to the trusted-publisher form

Questions

1. Is this a known issue, or have I misread the flow?
2. Is there an API or CLI route to register a trusted publisher that avoids the web form?

Without trusted publishing, CI needs a bypass-2FA token rotated every 90 days — which is the exact thing trusted publishing is meant to remove.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[nirav-gajera]

@trendai-au
Good news on question 2 first, since it's your actual way out of this: yes, there's a CLI route that skips the web form entirely — npm trust. This isn't a workaround someone hacked together, it's the documented command-line equivalent of the same settings page:

npm trust github your-package-name \
  --repo owner/repo \
  --file publish.yml \
  --allow-publish

Requirements: npm CLI 11.15.0+, 2FA enabled on the account (it'll prompt interactively the first time — via the normal npm 2FA flow, not the web form), and the package must already exist on the registry. npm trust list [package] shows existing config, npm trust revoke --id <id> removes one if you need to replace it (only one trust config per package is allowed at a time). Full flag reference: npm trust github --help.

On question 1 — I couldn't find this exact "fields wiped when the 2FA modal opens" bug already reported publicly, so I can't confirm it's a known, tracked issue rather than something specific to your session. But your own diagnosis (package-access fields survive, trusted-publisher fields don't, and it's reproducible both by hand and via automation) is solid enough to report as a real bug rather than user error — that's not something login/2FA/account health would explain, which you've already ruled out. Worth filing it at npm's own support (https://npmjs.com/support) or the [npm/cli](https://github.com/npm/cli/issues) or [npm/documentation](https://github.com/npm/documentation) repos rather than assuming it's just you — include the repro steps exactly as you wrote them here, that's a clean report.

In the meantime, npm trust sidesteps the broken form completely and gets you off the 90-day token treadmill today rather than waiting on a UI fix.

[trendai-au]

@nirav-gajera thank you — npm trust was exactly it, and it's now working. Publishing by OIDC with no token at all.

Recording the two things that still tripped me up, in case they help anyone else landing here:

1. A bypass-2FA granular token can't do it. npm trust list returns 403 Forbidden on GET /-/package/<pkg>/trust. npm's own notice explains why — "npm tokens that bypass 2FA are being restricted for account changes and direct publishing" — and registering a trusted publisher counts as an account change. So the token you're trying to eliminate can't be used to eliminate itself.

2. The OTP escalation URL 404s. With a real (web-login) session, every npm trust operation asks for a one-time password and prints:

npm error code EOTP
npm error This operation requires a one-time password.
npm error Open this URL in your browser to authenticate:
npm error   https://www.npmjs.com/auth/cli/<id>

That URL renders "Route not found!". So on an account whose only 2FA factor is a security key, there's no interactive way to satisfy the OTP.

What worked: passing a 2FA recovery code as --otp:

npm trust github <pkg> --repo owner/repo --file publish.yml --allow-publish --otp=<recovery-code>

Single-use, so it costs one code, but it goes straight through and prints the trust config.

One CI gotcha too: actions/setup-node with node-version: lts/* installs npm 10.x, which predates trusted publishing entirely. Adding npm install -g npm@latest before the publish step fixed it.

Net result: package publishes from GitHub Actions via OIDC with a provenance attestation, the bypass-2FA token is revoked and the NPM_TOKEN repo secret is deleted.

The original report stands, though — the web form still silently discards its trusted-publisher fields when the 2FA modal opens. npm trust is a way around it, not a fix for it.

[nirav-gajera]

Great find on all three of these — worth calling out why each one matters, since they're not obvious from the docs alone:

The bypass-2FA token 403 makes sense once you see it, but it's not intuitive going in — the whole point of trusted publishing is killing the long-lived bypass token, so it's a deliberate chicken-and-egg lockout, not a bug: that class of token is explicitly barred from account-level changes, and registering a trust relationship counts as one. Good catch pulling the actual npm notice text to explain it rather than just noting the 403.

The OTP escalation URL 404ing for security-key-only accounts is the sharper find here. That's a real gap in the CLI flow, not just an inconvenience — anyone whose only 2FA factor is a hardware key has no working path through the normal prompt at all, and would be stuck without knowing --otp accepts a recovery code as a workaround. That's worth its own report separate from the form bug, since it's a different failure mode (CLI flow assumes OTP-app/SMS-style 2FA, doesn't account for security-key-only accounts).

The lts/* → npm 10.x gotcha is a good one to flag too — silent version mismatch rather than a clear error, easy to burn time on if you don't already know trusted publishing needs 11.15.0+.

Given you've now got three distinct, well-isolated issues (the original form bug, the OTP-URL 404 for security-key accounts, and the implicit npm-version requirement not being surfaced by setup-node), it's worth splitting these into separate reports rather than one bundled thread — different root causes, different teams likely fix them. The security-key OTP one especially seems like the highest-value report on its own, since "recovery code as workaround" isn't something most people would think to try.

Glad npm trust got you fully off tokens either way — nice clean end state (OIDC + provenance, bypass token revoked, secret deleted).

If you found this answer useful, please consider marking it as the accepted answer. This can help other users who may encounter the same issue find a helpful solution.Great find on all three of these — worth calling out why each one matters, since they're not obvious from the docs alone:

The bypass-2FA token 403 makes sense once you see it, but it's not intuitive going in — the whole point of trusted publishing is killing the long-lived bypass token, so it's a deliberate chicken-and-egg lockout, not a bug: that class of token is explicitly barred from account-level changes, and registering a trust relationship counts as one. Good catch pulling the actual npm notice text to explain it rather than just noting the 403.

The OTP escalation URL 404ing for security-key-only accounts is the sharper find here. That's a real gap in the CLI flow, not just an inconvenience — anyone whose only 2FA factor is a hardware key has no working path through the normal prompt at all, and would be stuck without knowing --otp accepts a recovery code as a workaround. That's worth its own report separate from the form bug, since it's a different failure mode (CLI flow assumes OTP-app/SMS-style 2FA, doesn't account for security-key-only accounts).

The lts/* → npm 10.x gotcha is a good one to flag too — silent version mismatch rather than a clear error, easy to burn time on if you don't already know trusted publishing needs 11.15.0+.

Given you've now got three distinct, well-isolated issues (the original form bug, the OTP-URL 404 for security-key accounts, and the implicit npm-version requirement not being surfaced by setup-node), it's worth splitting these into separate reports rather than one bundled thread — different root causes, different teams likely fix them. The security-key OTP one especially seems like the highest-value report on its own, since "recovery code as workaround" isn't something most people would think to try.

Glad npm trust got you fully off tokens either way — nice clean end state (OIDC + provenance, bypass token revoked, secret deleted).

If you found this answer useful, please consider marking it as the accepted answer. This can help other users who may encounter the same issue find a helpful solution.