Feedback wanted: one stage/publish setting per package (with multiple OIDC configs)

[leobalter]

👋 We're planning to add support for multiple OIDC configs per package this quarter — so you could publish the same package from more than one source. That might be different CI providers, or the same provider with different workflows (say, one workflow for releases and another for prereleases). Today it's one OIDC config per package.

We're still early enough that your feedback can shape it — and there's one design question we're leaning toward a specific answer on, but want to hear from you before we settle it.

What we're planning

Since May, packages have had a stage-or-publish setting for OIDC publishing — you choose whether automated publishing goes stage only (a maintainer approves before it goes live) or stage and publish directly.

With multiple configs on the horizon, we're leaning toward keeping that as a single setting per package: all of a package's OIDC configs would share the same stage/publish permission — you set it once for the package, not per config. It's simpler to reason about, and we think it covers the vast majority of setups.

Where we'd love your input

Would one stage/publish setting per package break your workflow?

• If one-per-package works for you — a quick "works for me" is genuinely useful. 🙂
• If you need per-config permissions, tell us the concrete scenario — for example, a release workflow allowed to publish directly while a prerelease workflow is restricted to staging (or vice versa). Bonus if it's a setup you have today with a mix-and-match using granular tokens, not one you could imagine.

That's exactly the kind of detail that would tell us whether the granular version is worth building.

Good to know

• This is about the publish/stage permission, which is package-level. Multiple OIDC configs are the new part.
• OIDC configs are publish/stage only — they don't grant read access. (Reading content, like installing private packages, still uses a token.)
• One setting per package is our current lean, not a locked decision — if a real need for per-config permissions emerges from this thread, we'll revisit it.
• Separately, we have parallel work on namespace-level configs and package creation — that's orthogonal to this and not what we're asking about here, but flagging it so you know it's on our radar.

Thanks!