You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GitHub org-based publish returns 403 despite confirmed-public org membership, even after full OAuth revoke and re-auth #1537
mcp-publisher publish fails with a 403 claiming I have no permission to publish under my GitHub organization's namespace, even though I've verified — through three independent methods, including the exact API endpoint the registry itself uses — that my org membership is public. The failure persists identically across 4 separate attempts, including after a full OAuth revoke and fresh re-authorization.
Set org membership visibility to Public via github.com/orgs/icedq-tools/people.
Confirmed publicly visible via an incognito browser session at github.com/mrmclickstream — icedq-tools appears under Organizations.
Called the exact endpoint documented as the one the registry uses to discover org namespaces, GET https://api.github.com/users/mrmclickstream/orgs, and confirmed icedq-tools is present in the returned array.
Fully revoked the app's OAuth grant at github.com/settings/applications, then ran a completely fresh mcp-publisher login github (new device code, new consent screen).
Retried mcp-publisher publish — identical 403, unchanged, across 4 attempts spanning roughly 30+ minutes, including both before and after the OAuth revoke.
Expected behavior
Given confirmed-public org membership (verified against the registry's own documented data source), mcp-publisher publish should authorize io.github.icedq-tools/* and allow the publish.
Actual behavior
Consistently 403s, only ever authorizing io.github.mrmclickstream/*, regardless of re-authentication.
Update: found a working path around this. Rather than the interactive mcp-publisher login github device flow (which reliably 403s on org namespaces per this thread), authenticating via mcp-publisher login github-oidc from inside a GitHub Actions workflow running in the org's own repo works fine — it verifies the workflow's repo identity via GitHub's OIDC claims rather than checking which orgs the human account is a member of, so it doesn't appear to hit the same code path as the bug here at all.
Concretely: a workflow with permissions: { id-token: write } running in meridian-silkdev/meridian-mcp, doing mcp-publisher login github-oidc then mcp-publisher publish, successfully published io.github.meridian-silkdev/meridian-mcp on the first try — same org, same account, same server.json shape that 403'd repeatedly via the interactive flow minutes earlier.
Root cause identified + working workaround posted on #1649. Short version: the device-flow GitHub App (MCP Registry Login (Prod)) does not request read:org scope, so the token cannot see org memberships — even public ones. Workaround: exchange a read:org-scoped token directly via POST /v0/auth/github-at.
Closing this as a duplicate of #1468, which tracks the same inability to publish to organization namespaces using interactive GitHub device login and is now linked from the authentication docs. I cross-linked this report there to preserve its diagnostics and workaround reports.
#1483 corrected the misleading error guidance and documented PAT/GitHub Actions OIDC alternatives; it did not fix interactive organization authentication. #1468 remains open for that underlying problem. Please continue tracking the fix there.
Activity
ci: add MCP Registry publish via GitHub OIDC (bypasses org-membership…
bedouijesser commentedon Sep 4, 2026
Update: found a working path around this. Rather than the interactive
mcp-publisher login githubdevice flow (which reliably 403s on org namespaces per this thread), authenticating viamcp-publisher login github-oidcfrom inside a GitHub Actions workflow running in the org's own repo works fine — it verifies the workflow's repo identity via GitHub's OIDC claims rather than checking which orgs the human account is a member of, so it doesn't appear to hit the same code path as the bug here at all.Concretely: a workflow with
permissions: { id-token: write }running inmeridian-silkdev/meridian-mcp, doingmcp-publisher login github-oidcthenmcp-publisher publish, successfully publishedio.github.meridian-silkdev/meridian-mcpon the first try — same org, same account, same server.json shape that 403'd repeatedly via the interactive flow minutes earlier.Doesn't fix the underlying interactive-login bug, but it's a full workaround for anyone who can run their publish from GitHub Actions (which is the recommended approach in the docs anyway: https://modelcontextprotocol.io/registry/github-actions). Hope this helps unblock others on this thread.
docs: document the live MCP Registry listing and the OIDC workaround
ci: add MCP Registry publish via GitHub OIDC (bypasses org-membership…
docs: document the live MCP Registry listing and the OIDC workaround
eudoroolivares2016 commentedon Sep 11, 2026
Yea also seemingly running into the same issue
jcolvin1056 commentedon Oct 11, 2026
Root cause identified + working workaround posted on #1649. Short version: the device-flow GitHub App (
MCP Registry Login (Prod)) does not requestread:orgscope, so the token cannot see org memberships — even public ones. Workaround: exchange aread:org-scoped token directly viaPOST /v0/auth/github-at.rdimitrov commentedon Oct 23, 2026
Closing this as a duplicate of #1468, which tracks the same inability to publish to organization namespaces using interactive GitHub device login and is now linked from the authentication docs. I cross-linked this report there to preserve its diagnostics and workaround reports.
#1483 corrected the misleading error guidance and documented PAT/GitHub Actions OIDC alternatives; it did not fix interactive organization authentication. #1468 remains open for that underlying problem. Please continue tracking the fix there.