[Bug] GitHub plugin fails: 'Incompatible auth server: does not support dynamic client registration'

[eugenio]

Description

The GitHub plugin (github@claude-plugins-official) fails to authenticate with the following error:

Plugin: github:github MCP Server

Status: ✘ failed
Auth: ✘ not authenticated
URL: https://api.githubcopilot.com/mcp/
Config location: Dynamically configured

Error: Incompatible auth server: does not support dynamic client registration

Expected Behavior

The GitHub plugin should either:

1. Successfully authenticate with the GitHub Copilot MCP endpoint, or
2. Provide clear instructions on how to configure authentication (e.g., using a PAT or different auth method)

Environment

• OS: Windows 11
• Claude Code: Latest version

Workaround

Users can use the GitHub CLI (gh) instead, which works well for all GitHub operations:

1. Install: winget install GitHub.cli
2. Authenticate: gh auth login
3. Disable the failing plugin in settings

Notes

The GitHub Copilot MCP endpoint (https://api.githubcopilot.com/mcp/) appears to require a specific authentication flow that isn't compatible with dynamic OAuth client registration used by Claude Code's plugin system.

[Ekhrapykin]

@eugenio
Please refer to anthropics/claude-code#3433 for more details

[eugenio]

Thanks, I'll look it up! Il giorno gio 26 feb 2026 alle ore 06:59 Eugene K ***@***.***> ha scritto:

…

*Ekhrapykin* left a comment (anthropics/claude-plugins-official#283) <#283 (comment)> @eugenio <https://github.com/eugenio> Please refer to anthropics/claude-code#3433 <anthropics/claude-code#3433> for more details — Reply to this email directly, view it on GitHub <#283 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHMZDDEFN63XP5XSIFOXD4N2DVNAVCNFSM6AAAAACS26RB4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNRUGMYDAOJVGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[axisrow]

Confirming on macOS (Darwin 25.3.0), Claude Code Opus 4.6 — same failure mode. Adds a third platform to the report (original is Windows 11, linked anthropics/claude-code#3433 is Ubuntu).

Symptoms reproduced exactly:

1. After installing github@claude-plugins-official, the MCP server fails at startup with:

   Invalid MCP server config for "github": Missing environment variables: GITHUB_PERSONAL_ACCESS_TOKEN
   

2. Clicking "Authenticate" in the plugin UI triggers:

   SDK auth failed: Incompatible auth server: does not support dynamic client registration
   

Two independent gaps

• Plugin-side (fixable in this repo). external_plugins/github/ ships a .mcp.json that depends on ${GITHUB_PERSONAL_ACCESS_TOKEN} but has no README, no setup docs, and no note that the UI "Authenticate" button will not work. A minimum README explaining (a) that interactive OAuth is currently blocked on Claude Code cannot connect to GitHub's remote MCP server using OAuth authentication claude-code#3433, (b) how to create a classic PAT, (c) how to inject it via ~/.claude/settings.json env block would unblock most users immediately. Could also point those who don't want the Copilot-hosted remote server at the local stdio alternative github/github-mcp-server.
• CC-side (tracked in Claude Code cannot connect to GitHub's remote MCP server using OAuth authentication claude-code#3433). Claude Code's plugin auth path assumes RFC 7591 DCR. GitHub's Copilot MCP server uses pre-registered OAuth clients. Until CC supports that flow, the plugin cannot authenticate interactively.

Happy to open a PR against external_plugins/github/ with a README + setup instructions if that's a welcome contribution.

[dustin-flow]

Also affects Cowork (Claude desktop, knowledge-work-plugins marketplace), macOS 14.x — same root cause. Reproduces against the engineering plugin's bundled GitHub MCP (cowork_plugins/marketplaces/knowledge-work-plugins/engineering/.mcp.json → https://api.github.com/mcp, which 30x's to api.githubcopilot.com/mcp/). Adding to the Windows 11 / Ubuntu / macOS Claude Code reports already in the thread, that's four surfaces now.

A few extra observations from a long debug session that the thread doesn't already cover — flagging in case they help locate the failure mode in shared SDK code:

1. Misleading "success" path in Cowork. Cowork exposes a Connect button on the GitHub connector that opens a claude.ai web view. OAuth completes successfully on the web side and the connector reports as authenticated. Despite that, every new local session continues to expose only the mcp__plugin_engineering_github__authenticate / __complete_authentication stubs — never the real tool list. The user is told auth worked when functionally nothing changed. (Calling authenticate returns the canonical SDK auth failed: Incompatible auth server: does not support dynamic client registration.)

2. Stale cache is not the cause. ~/Library/Application Support/Claude/local-agent-mode-sessions/<.../>/.claude/mcp-needs-auth-cache.json exists per-session and does not contain a plugin:engineering:github entry — yet the stub tools appear in every new session anyway. So the stubs aren't driven by a cached "needs auth" flag; they're created at server-init time when the DCR probe against the well-known URL fails. Cache deletion is not a workaround.

3. No local credential is written after the web OAuth succeeds. Post-auth Keychain dump shows gh:github.com (GitHub CLI), Claude Safe Storage, and Claude Code-credentials* — but nothing labelled for the Cowork-side GitHub MCP. The OAuth state appears to live entirely on the claude.ai backend with no path to the local MCP subprocess. That explains why restart/relogin cycles can't help: there's no local token to read.

4. Cowork has no escape hatch. The PAT workaround documented for Claude Code (claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer <PAT>") isn't reachable from Cowork — the UI exposes no custom-header field, and cowork_plugins/marketplaces/knowledge-work-plugins/engineering/.mcp.json is read-only from the user's perspective (and the app may overwrite it). So Cowork users genuinely have no workaround other than abandoning the plugin's GitHub connector and shelling out to gh.

5. Dead ends I can confirm (for the next person who lands here): Disconnect/Connect in Connectors panel, toggling the engineering plugin off/on, full Cmd-Q + relaunch, clearing Claude Code-credentials* from Keychain and signing back into Cowork. None changed the stub-tool state.

Net: the user-visible "fix" surfaces in Cowork (Connect button, web OAuth) all complete successfully and accomplish nothing locally. Strong vote for either (a) shipping a Cowork-side proxy for GitHub like *.mcp.claude.com does for Google, or (b) plumbing through pre-registered client credentials per the existing feature request at claude-code#26675.

[tiennguyen1293]

i'm facing this issue too

[axisrow]

When are they going to fix it?

[trek-e]

Adding a root-cause diagnosis from inspecting the plugin's .mcp.json.

The github server entry has no oauth block / no registered clientId, unlike connectors that authenticate fine (e.g. slack):

"slack": {
  "type": "http",
  "url": "https://mcp.slack.com/mcp",
  "oauth": { "clientId": "<registered-id>", "callbackPort": 3118 }
},
"github": {
  "type": "http",
  "url": "https://api.githubcopilot.com/mcp/"
}

With no pre-registered client, the SDK falls back to dynamic client registration (RFC 7591), which api.githubcopilot.com/mcp rejects — hence the error. Re-running /mcp can't help because there's no registered app to present.

Two concrete fixes (either works):

1. Register an OAuth client and add the oauth block to the github entry, mirroring slack.
2. Support a PAT auth header (Authorization: Bearer <token>) sourced from a user-configured secret, so users can supply a token once instead of per session.

Impact worth emphasizing: in sandboxed/isolated environments (e.g. Cowork) there's no host Keychain access, so the only workaround is pasting a PAT into chat every session.

[raph-p]

Any (human) news on this?