Desktop app /mcp OAuth sends a claude:// redirect URI that mcp.cloudflare.com rejects (Redirect URI must use HTTPS or a local loopback address); CLI connection not shared with the desktop session

Summary

Connecting the Cloudflare MCP server (mcp.cloudflare.com/mcp, the cloudflare-api server of the Cloudflare plugin) from the desktop app's /mcp flow fails at Cloudflare's authorize page. The app sends a custom-scheme redirect URI and the server refuses it. The same server connects from the terminal CLI, whose flow uses a loopback redirect, but that connection is not visible to the desktop session afterwards, so the desktop session has no way to reach this server at all.

Environment

• Claude desktop app, Code tab, Windows 11 Pro (10.0.26200)
• Claude Code 2.1.268 (bundled skills path shows 2.1.260 in the session)
• Plugin: plugin:cloudflare:cloudflare-api (remote MCP, OAuth)

Steps

1. In the desktop app's Code tab, run /mcp, choose the cloudflare-api server, start the OAuth connection.
2. The browser opens Cloudflare's authorize page with (values elided):

https://mcp.cloudflare.com/authorize?response_type=code&client_id=...&code_challenge=...&code_challenge_method=S256&redirect_uri=claude%3A%2F%2Fclaude.ai%2Fmcp-auth-callback%2Fsdk&state=...&resource=https%3A%2F%2Fmcp.cloudflare.com%2Fmcp

1. Cloudflare answers, before any login:

> Invalid Request
> Redirect URI must use HTTPS or a local loopback address
> Error code: invalid_request

What narrows it

• The redirect URI the app sends is claude://claude.ai/mcp-auth-callback/sdk, a custom scheme. Cloudflare's authorization server for this host accepts only https:// or loopback redirects.
• Cloudflare's other MCP host in the same plugin (cloudflare-observability) connected fine from the same desktop /mcp flow on the same day, so the custom scheme is accepted by one Cloudflare server and refused by another. Cloudflare's inconsistency is their bug; the app's dependence on a custom scheme is what it exposes.
• Running claude in a terminal and connecting the same server via /mcp there succeeds (loopback redirect). But the desktop session started afterwards still lists cloudflare-api as requiring authentication and exposes none of its tools, and /mcp in the desktop app fails the same way again. The two clients do not share the connection.

Expected

Either the desktop flow offers an https:// or loopback redirect for servers that require one, or a connection authorized from the CLI is picked up by the desktop app's sessions.

Impact

Any remote MCP server whose OAuth implementation enforces the RFC 8252 redirect rule cannot be connected from the desktop app. In this case it blocks reading Cloudflare Access policies from a session that is otherwise doing the account's operations work.