fix(mcp): remove github catalog entry + render orphaned OAuth servers - #93
Merged
Conversation
Two cleanup fixes for the OAuth integrations UI: 1. Remove GitHub from CORE_MCP_CATALOG (api.githubcopilot.com/mcp/) GitHub Copilot's MCP server returns 'Incompatible auth server: does not support dynamic client registration' when the SDK-managed OAuth path attempts DCR. The catalog entry was advertising a Connect with OAuth button that could never succeed. Users who want GitHub MCP should add a github_token secret instead — the existing static- headers path already handles it and the UI hides any GitHub catalog suggestion when a github_token is present. The fallback github_token-hides-suggestion code path in dodo-settings.js (`if(cat.id==="github"&&hasGithubToken)return`) becomes dead with this change but is harmless to leave in place. 2. Always render orphaned OAuth servers Before this commit, renderOAuthCard was only called for catalog entries with auth_type='oauth' that had a matching SDK-managed hub-DO record. When a catalog entry was removed (e.g. cf-portal in PR #89) but the user already had a failed/stuck server record from a previous attempt, the record was invisible in the UI → no way to clear it without poking /api/mcp/delete-auth manually. Fix: track which oauthServers got rendered alongside a catalog entry; render any unmatched ones via the new renderOrphanedOAuthCard with a 'Clear' button (calls existing /api/mcp/delete-auth). Also improve renderOAuthCard for non-ready states: - 'Refresh' button only shows for state=ready (it was retrying against a broken config in other states, which was useless) - The remove button reads 'Disconnect' when ready, 'Clear' otherwise. Tests: 832/832 pass. Catalog test count updated to reflect the removed github entry; new assertions confirm github and cf-portal are NOT in the catalog so the next person doesn't accidentally re-add them without reading the history. Stale UI rendering of an orphaned cf-portal 'authenticating' entry that surfaced this issue was already wiped manually via /api/mcp/delete-auth. beep-boop-🤖
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two cleanups for the OAuth integrations UI
1. GitHub catalog entry removed
api.githubcopilot.com/mcp/returns:…when the SDK-managed OAuth path attempts DCR. The catalog entry was advertising a 'Connect with OAuth' button that could never succeed. Users who want GitHub MCP should add a
github_tokensecret — the static-headers path already handles it.2. Orphaned OAuth servers now render with a 'Clear' button
Before this commit,
renderOAuthCardwas only invoked for catalog entries withauth_type='oauth'that had a matching hub-DO record. When a catalog entry got removed (e.g. cf-portal in #89) but the user already had a stuck/failed hub-DO record from a previous attempt, the record was invisible in the UI. The user had no way to clear it without poking/api/mcp/delete-authdirectly.Fix: track which oauthServers got rendered alongside a catalog entry; render any unmatched ones via the new
renderOrphanedOAuthCardwith a 'Clear' button (calls existing/api/mcp/delete-auth).Also tighten
renderOAuthCardfor non-ready states: 'Refresh' only appears forstate=ready, and the destructive action reads 'Clear' for non-ready states and 'Disconnect' only when actually connected.Background
I saw 'Cloudflare Portal · Authenticating…' stuck in the integrations panel with no actionable button. Investigation: the per-user hub DO had two zombie OAuth entries (
portal.mcp.cfdata.orgfrom an old failed authorize attempt,api.githubcopilot.comfrom the DCR rejection). Both invisible because cf-portal's catalog entry was removed in #89 and GitHub's catalog entry would've showed Connect-with-OAuth which would fail again.Cleared the two zombies via
/api/mcp/delete-authmanually. This PR prevents the situation from recurring.Verification
npm run typecheckcleannpx vitest run832/832 passbeep-boop-🤖