mcp: CIMD client.json redirect_uris don't match the loopback callback, breaking Turso MCP OAuth #54421

Description

Remote MCP OAuth against Turso (https://mcp.turso.ai/mcp) fails before sign-in with:

Invalid request
The redirect URI is not permitted for this client - it must be a loopback address, an allowed hosted callback, or listed in the client's metadata document.

Turso's authorization server advertises client_id_metadata_document_supported: true, so OpenCode selects CIMD registration (registration=cimd) and identifies as https://opencode.ai/oauth/opencode/client.json. That hosted document lists only:

"redirect_uris": ["http://127.0.0.1/callback", "http://localhost/callback"]

but OpenCode sends redirect_uri=http://127.0.0.1:19876/mcp/oauth/callback (dynamic/fixed port + /mcp/oauth/callback path). OAuth redirect matching is exact-string, so the authorization server rejects the request before the user can sign in.

This is the same root cause as #50510 (Exa), reproduced against a different authorization server (api.turso.tech), which suggests the problem is general to any CIMD-capable AS and not Exa-specific.

Turso AS metadata (https://mcp.turso.ai/.well-known/oauth-authorization-server):

{"authorization_endpoint":"https://app.turso.tech/oauth/mcp/authorize","client_id_metadata_document_supported":true,"code_challenge_methods_supported":["S256"],"grant_types_supported":["authorization_code"],"issuer":"https://api.turso.tech","registration_endpoint":"https://api.turso.tech/v1/oauth/register","response_types_supported":["code"],"token_endpoint":"https://api.turso.tech/v1/oauth/token","token_endpoint_auth_methods_supported":["none"]}

Plugins

None

OpenCode version

2.0.22

Steps to reproduce

1. Add a remote MCP server: {"type":"remote","url":"https://mcp.turso.ai/mcp"} with no oauth.redirect_uri and no oauth.client_id.
2. Run opencode mcp auth turso.
3. Open the printed authorization URL in the browser.
4. Turso returns: "The redirect URI is not permitted for this client - it must be a loopback address, an allowed hosted callback, or listed in the client's metadata document."

Expected: sign-in page is shown and authorization completes.
Actual: rejected before sign-in.

Suggested fix

Either declare the loopback callback OpenCode actually sends (port + /mcp/oauth/callback path) in the hosted client.json, or fall back to Dynamic Client Registration when the CIMD document's redirect_uris do not cover the callback actually in use. The AS publishes a registration_endpoint, so DCR is viable.

Workaround

Set an explicit redirect URI (and callback port) in config, which forces DCR instead of CIMD:

"turso": {
  "type": "remote",
  "url": "https://mcp.turso.ai/mcp",
  "oauth": {
    "callback_port": 19876,
    "redirect_uri": "http://127.0.0.1:19876/mcp/oauth/callback"
  }
}

Screenshot and/or share link

n/a - the error is returned by the browser redirect to the authorization server.

Operating System

Windows 10 (10.0.19045)

Terminal

xterm-256color (Windows Terminal)