ChatGPT "Some app settings were rejected" When Connecting to an OAuth MCP Server

Adding a self-hosted, OAuth-protected MCP server to ChatGPT fails with a generic error, even though the same server works from Claude Code or another local MCP client.

Some app settings were rejected. Check the server URL or tunnel ID, icon, and authentication settings, then try again.

Cause

ChatGPT registers itself with your authorisation server using OAuth dynamic client registration (RFC 7591), sending an HTTPS callback on chatgpt.com in redirect_uris. If your /register endpoint only accepts loopback callbacks such as http://localhost:<port>/callback, or a fixed allowlist, the registration fails and ChatGPT reports the generic error above.

Local clients such as Claude Code register a loopback callback, so they pass the same check. That makes the server look healthy when it is not.

Diagnose

Confirm discovery works first. Both documents should return JSON, and an unauthenticated request to the MCP endpoint should return 401 with a WWW-Authenticate header that points at the protected-resource metadata.

curl -s https://<your-domain>/.well-known/oauth-protected-resource
curl -s https://<your-domain>/.well-known/oauth-authorization-server
curl -si -X POST https://<your-domain>/<mcp-path> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' | grep -i www-authenticate

Then probe the registration endpoint with an HTTPS callback. Add a deliberately invalid field, such as response_types: ["token"], so that a request that gets past the redirect check fails later instead of creating a real client.

curl -s -X POST https://<your-domain>/oauth/register \
  -H 'content-type: application/json' \
  -d '{"redirect_uris":["https://example.com/callback"],"response_types":["token"]}'

An error about the redirect URI (for example invalid_redirect_uri) confirms the cause. An error about response_types means the redirect URI was accepted and the problem is elsewhere.

Fix

Accept any HTTPS redirect URI at registration, as well as loopback HTTP for local clients. Keep refusing the forms that are never legitimate: fragments, embedded credentials, missing hosts and other schemes. In Python:

from urllib.parse import urlparse

LOOPBACK_HOSTS = {"localhost", "127.0.0.1", "::1"}


def registrable_redirect_uri(uri: str) -> bool:
    parsed = urlparse(uri)
    if not parsed.hostname or parsed.fragment or parsed.username or parsed.password:
        return False
    if parsed.scheme == "https":
        return True
    return parsed.scheme == "http" and parsed.hostname in LOOPBACK_HOSTS

Open registration means the consent screen becomes the guard against a rogue client. Someone can register a client with their own callback and send you an authorisation link. If you approve it, the code goes to their site. Make the consent page lead with the callback host, because the client name is chosen by the client and can be anything:

<p>Access will be sent to <strong>chatgpt.com</strong></p>
<p>The client calls itself <em>My App</em> (self-reported).</p>

Optionally, also serve the protected-resource metadata at its path-specific location, which the MCP specification allows clients to try:

/.well-known/oauth-protected-resource/<mcp-path>

Verify

Re-run the registration probe with an HTTPS callback. It should now fail only on the deliberately invalid field. Then add the server in ChatGPT again: it should open your consent page, show the callback host and connect after approval.

Notes

• Avoid allowlisting a single exact ChatGPT callback URL. Its format has changed over time, and an exact match breaks when it does.
• Keep the other protections in place: PKCE with S256, short-lived access tokens, rate limiting on /register, and restricting who can approve on the consent page.