[BUG] Engineering plugin GitHub connector can never authenticate — no OAuth clientId (falls back to unsupported DCR)

[Newport1]

After GitHub was repackaged into the Engineering plugin, its bundled MCP connector (plugin:engineering:github) can never complete authentication. The connector shows a "Connected / Disconnect" state in the UI, but no tools are ever exposed. Anything that depends on the GitHub connector — chat tool calls and scheduled/automated runs — therefore fails or silently skips.

Environment

• Product: Claude Desktop — Cowork mode
• OS: macOS 27 Golden Gate Beta 3
• App version: Claude 1.19367.0 (1a5be1)
• Plugin: engineering (knowledge-work-plugins)
• Connector: github (plugin:engineering:github)

Root cause (best assessment)

The github MCP server entry in the plugin's .mcp.json has no oauth block / no pre-registered clientId. With no client ID, the MCP client SDK falls back to dynamic client registration (DCR) against https://api.githubcopilot.com/mcp/, which does not support DCR. The handshake never completes, so no token is issued and no tools load.

Steps to reproduce

1. Install/enable the Engineering plugin.
2. Open Customize → Connectors and attempt to connect GitHub.
3. Observe the connector appears connected (a "Disconnect" button shows).
4. Try to use GitHub in chat (e.g., "list my open PRs"), or let a scheduled task that uses the GitHub connector run.

Expected

OAuth completes and GitHub MCP tools (list pull requests, list commits, etc.) become available.

Actual

• No GitHub tools are ever exposed; tool lookups for GitHub return nothing.
• The connector cycles between "connecting" and "requires authentication" but never finishes.
• The Disconnect button is inert — it can't reset the connector to a clean state.

Impact

• Any chat request needing GitHub fails.
• Automated/scheduled runs that depend on the connector silently skip their GitHub steps (e.g., a daily open-PR digest and a weekly review that lists open PRs), so the breakage is invisible unless you inspect the generated reports.

Workarounds tried

• Relaunch / new windows / full quit + reopen — no change.
• Disconnect + reconnect — Disconnect button does nothing.
• Adding the connector via claude.ai in a browser instead of the desktop app (reportedly works for some — see #47819): <Workaround did not work for me Macos 27 Golden Gate Beta 3>.
• gh CLI via Homebrew on mac
• Brew install gh
• gh auth status showing green does not fix cowork issue

Related issues

• engineering plugin GitHub connector can never authenticate (no OAuth clientId) #3157 — engineering plugin GitHub connector can never authenticate (no OAuth clientId)
• #59854 — Cowork GitHub connector unusable (OAuth DCR unsupported, dead Disconnect)
• #61682 — GitHub connector "Connected" but exposes no tools in Cowork
• #47819 — custom plugin MCP connector works after adding via claude.ai

Suggested fix

Ship a registered OAuth clientId (with a proper oauth config / endpoints) for the github entry in the Engineering plugin's .mcp.json, instead of relying on DCR against an endpoint that doesn't support it.

Further Investigation

What’s actually broken
Issue #283 is not really a user-side setup mistake. The GitHub MCP endpoint is being contacted at:
https://api.githubcopilot.com/mcp/
and Claude’s plugin auth flow is trying dynamic client registration, but that auth server does not support DCR, so auth fails with:
Incompatible auth server: does not support dynamic client registration
That matches the GitHub issue body and your uploaded bug report: connected-looking UI state, but no real GitHub tools exposed.
Anthropic / the plugin maintainer has to change the plugin config. The GitHub entry needs either:

Option A — registered OAuth client

"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"oauth": {
"clientId": "",
"callbackPort": 3118
}
}

This is the proper fix if they want the connector to work like Slack or other OAuth-backed connectors.

Option B — PAT header support

"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN}"
}
}

That would let users set a token once instead of getting stuck in the broken OAuth flow. Related issue #285 says the external GitHub plugin expects GITHUB_PERSONAL_ACCESS_TOKEN, but lacks clear auth documentation.

Comment to add to #283 / #3157

This still appears to be broken because the GitHub MCP endpoint does not support dynamic client registration, while the plugin config does not provide a registered OAuth clientId.
The fix likely needs to be one of:

1. Add a registered OAuth config for the GitHub MCP entry:

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

2. Or support PAT-based auth:

"github": {
  "type": "http",
  "url": "https://api.githubcopilot.com/mcp/",
  "headers": {
    "Authorization": "Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN}"
  }
}

Without one of those, the client falls back to DCR and fails with:

Incompatible auth server: does not support dynamic client registration

The UI can appear connected while exposing no usable GitHub tools, which makes this especially confusing for automated/scheduled runs.

Bottom line: **you can work around it with `gh` / PAT in Claude Code, but the official plugin connector itself needs a maintainer-side config fix.**