[BUG] Cowork — GitHub connector unusable: OAuth DCR unsupported, UI shows misleading state, Disconnect button dead

Running into this too. First time trying Cowork and it suggested installing plugin:engineering:github, but it can't authenticate: the authenticate tool fails with the error in this issue, and reconnecting from the Connectors UI does nothing (lands on a claude.ai page, reports connected, never redirects to GitHub).

I already have a working standalone github MCP server in my Claude Code CLI (claude mcp list shows it connected, 43 tools, at https://api.githubcopilot.com/mcp) but Cowork can't use it, the Cowork session only loads plugin:engineering:github and ignores the CLI-scope server, even though both point at the same endpoint. So there are two GitHub registrations that don't talk to each other, and the only one Cowork loads is the one that can't auth.

Inspecting the engineering plugin's .mcp.json, the github entry has no oauth.clientId (unlike the slack entry, which does) — so it falls back to DCR, which GitHub's MCP server rejects. Adding a pre-registered clientId to that entry like slack has would likely fix it.

Env: Claude desktop app (Cowork mode), macOS. Same account works fine for GitHub in Claude Code CLI and claude.ai web.

I am also hitting the same issue running claude on a Mac and using the desktop app

Confirming this is still broken as of today (2026-07-10, macOS desktop app). Tested the disconnect/reconnect workaround on two connectors from Settings → Connectors.

Tavily: disconnect then reconnect fixed it cleanly — tools loaded, list_connectors shows it.

GitHub Integration: same disconnect then reconnect sequence, but no change — Settings still shows a checkmark next to "GitHub Integration," yet the connector never appears in the session's list_connectors output and no GitHub tools load. Confirms the reconnect flow itself works fine in Cowork; GitHub's connector specifically doesn't recover from it, consistent with the missing oauth.clientId root cause flagged above.

Happy to provide app version / logs if useful.

Confirming this is still broken today (2026-07-10, macOS desktop app). Went further down the troubleshooting path than most of the comments here: created a fine-grained PAT scoped to the target org with Pull requests and Issues read/write, no manual way to enter it in Cowork. Then checked whether it was actually an org-install problem: installed the "Claude" GitHub App directly on the org with the correct read/write scopes and repos selected, saved it, then disconnected/reconnected the GitHub connector in Cowork settings (twice, with a full app relaunch in between).

Still getting Permission Denied: Resource not accessible by personal access token on every write call (create_pull_request_review, update_issue), even though the org-side permissions are provably correct now. Reads work fine the whole time.
This lines up with what's already flagged above: no oauth.clientId on the github entry means it's falling back to DCR, and no amount of reconnecting or org-level app config fixes that from the user side. Would be great to get the pre-registered clientId fix in, this one blocks any PR review or issue-labeling workflow in Cowork entirely.

Adding a data point that lines up with the DCR/registration_endpoint root cause identified above.

On the Claude desktop app (macOS), I found the identical failure signature in the local renderer log (~/Library/Logs/Claude/claude.ai-web.log):

GET .../mcp/start-auth/{connector-id}?...&mcp_auth_source=settings_connect...
error: "Failed to start MCP authorization"
error_code: "registration_endpoint_missing"

(That specific log line was for a different connector on my account, not GitHub -- but it's the exact same start-auth failure mode, on the same account, which supports this being a general DCR/registration-endpoint issue rather than something isolated to GitHub's MCP server.)

Independently confirming the rest of this issue's symptoms as of today (2026-07-30, macOS desktop app):

• Settings > Plugins > Engineering > Connectors > GitHub shows "Disconnect" (implying connected).
• Clicking Disconnect does nothing -- no confirmation, no error, and no network request fires at all (checked the local log immediately after clicking -- nothing was recorded for that click).
• No GitHub MCP tools are reachable in a session despite the "connected" state shown.
• This is independent of local gh CLI auth -- I separately verified gh is fully authenticated on this machine (native hosts.yml + keychain populated, gh auth status succeeds), which made no difference to the connector's state. Rules out local-machine GitHub auth as a factor.

Still reproducing today, so this remains open/unresolved.