fix(mcp): remove cf-portal catalog entry — loopback-only redirect URI policy

[jonnyparris]

What I learned

After 6 PRs of trying to make Dodo connect to cf-portal via OAuth, and finally cross-referencing OpenCode's source (packages/opencode/src/mcp/oauth-provider.ts):

get redirectUrl(): string {
  if (this.config.redirectUri) return this.config.redirectUri
  const port = this.config.callbackPort ?? OAUTH_CALLBACK_PORT  // 19876
  return `http://127.0.0.1:${port}${OAUTH_CALLBACK_PATH}`        // /mcp/oauth/callback
}

OpenCode (and Cursor, Claude Desktop, etc) work with cf-portal because they're local clients using loopback redirect URIs. They spin up an HTTP server on 127.0.0.1:19876 to catch the callback.

cf-portal's authorize endpoint (cf-mcp.cloudflareaccess.com) enforces an allowlist:

• ✅ http://127.0.0.1:*/... — accepted (loopback)
• ✅ Cloudflare-managed domains (e.g. seal-nightly.cloudflare.dev) — accepted (allowlisted)
• ❌ Everything else — rejected with Redirect URI not allowed by application configuration

This is sensible OAuth security: treat third-party hosted apps as untrusted clients, only allow callbacks to locally-controlled URIs or known Cloudflare property.

What this means for Dodo

A hosted Worker can't bind 127.0.0.1 from the user's perspective. cf-portal as an OAuth target from Dodo is infeasible by design, not by bug.

Fix

Remove the cf-portal catalog entry. The comment in mcp-catalog.ts documents the reasoning. Test updated to assert the entry's absence.

Workaround for cf-portal access in Dodo (out of scope)

Run a local mcp-remote proxy on the user's machine that does the loopback OAuth, then expose it to Dodo as a static-headers MCP integration. Defeats the point of Dodo being hosted, but it's how Cursor users do it. Not implementing this here.

What stays in place

All the supporting infrastructure from PRs #82–#88 remains useful for any future OAuth-MCP entry that allows remote redirect URIs:

• OAuth start-auth / delete-auth / refresh-state endpoints
• Popup + polling UX
• Stale-registration cleanup before retry
• getAgentByName fix (workerd#2240)
• Integrations panel moved above Skills/Tools

The browser-rendering and github OAuth entries are still in the catalog. github has its own issue (Incompatible auth server: does not support dynamic client registration — needs a pre-registered client_id which we don't expose yet). browser-rendering has a separate dedicated UI section that wasn't testable in this scope.

Verification

• npm run typecheck clean
• npx vitest run 817/817 pass
• The integrations panel no longer shows cf-portal once redeployed

beep-boop-🤖