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

## 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): ``.
- gh CLI via Homebrew on mac
- Brew install gh
- gh auth status showing green does not fix cowork issue

## Related issues

- #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:
```json
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"oauth": {
"clientId": "",
"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.**

Locate the Engineering plugin's .mcp.json and inspect the github MCP server entry. First verify the reported authentication failure against https://api.githubcopilot.com/mcp/ and confirm whether the connector falls back to unsupported dynamic client registration. Done means the chosen authentication path completes and GitHub tools are exposed in chat and scheduled runs.

索引モデルが issue の本文から書いたものです。