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`

3. 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.

Start with the desktop app's `/mcp` OAuth flow and compare its redirect handling with the terminal CLI's loopback flow. Trace how the desktop session stores or discovers MCP authentication, then verify completion by connecting `cloudflare-api` from the desktop and confirming that the authorized CLI connection is visible there.

Escrito por el modelo de indexación a partir del texto del issue.