Custom remote MCP OAuth fails before sign-in with: redirect_uri is not allowed by the account configuration. Existing connector Owner Google Tasks MCP remains needsAuth / authentication_required, tools=0. Endpoint: Sign in ・ Cloudflare Access . The server uses Streamable HTTP protected by Cloudflare Access Managed OAuth. Bot diagnostics do not expose the DCR redirect_uris array.
Steps to Reproduce
Add the remote MCP through Grok Bot.
Request OAuth authorization on that existing connector.
Registration fails with the redirect_uri error before the sign-in card opens.
Allowlisting the exact /agents/ and then /bot/ callbacks in Cloudflare did not resolve it. No duplicate connector was added; retries have stopped.
Expected Behavior
OAuth should open the owner sign-in flow, then load MCP tools. Please inspect the failing DCR request and provide the exact redirect_uris array, or correct unintended callback entries. Please confirm the supported callback list for current Grok Bot remote MCP.
Operating System
MacOS
Version Information
Grok Bot version: 0.53.0
OS: macOS (darwin)
Additional Information
Cloudflare allows the following exact HTTPS callback paths on the www subdomain of Cursor:
/agents/mcp/oauth/callback
/bot/mcp/oauth/callback
The existing Grok web callback is also allowed. Localhost and 127.0.0.1 callback options are enabled. Both added Cursor callbacks saved successfully. No wildcard or custom scheme was added.
The official MCP SDK completed token exchange, tools listing, read-only Google calls, refresh and reconnect. Grok web also completed OAuth and actual read-only tool calls. This does not prove Bot compatibility: Bot has not invoked connection_status or list_tasklists because tools never load.
Possibly related: AWS MCP callback URL issue . We have not established that our request has the same root cause.
No credentials, authorization codes, full authorization URLs, private task contents or raw logs are included.
Grok Bot desktop authorizes via entry 3 (localhost loopback), so your Cloudflare settings for entries 2 and 3 are already correct. The /bot/ callback you added isn’t related to desktop registrations. It’s harmless, but not needed.
The issue is entry 1. Cloudflare Managed OAuth only allows https in “Allowed redirect URIs”, so you can’t allowlist cursor:// there at all, and Cloudflare rejects the entire registration with redirect_uri is not allowed by the account configuration. This isn’t caused by your setup. Your server and config aren’t the problem here. This is an issue on our side that we’re tracking. The goal is for registration to only send https and localhost callbacks. Once that ships, your current Cloudflare configuration should work without any changes. I’ll post an update here when we have one.
Workaround for now: since it’s your server, you can bypass OAuth using a Cloudflare Access service token. In Zero Trust, create a service token, add a Service Auth policy to the app, and connect MCP using the CF-Access-Client-Id and CF-Access-Client-Secret headers instead of OAuth (the server needs to accept identity from the Access JWT via the service token). If you try it, let me know whether the tools load.
Grok Bot confirms that AddMcpServer.headers supports custom HTTP headers. However, we cannot find a secure way for the owner to enter CF-Access-Client-Secret: the connector UI only offers OAuth authentication and account renaming, and the tool schema exposes no secret/vault reference.
How can I securely configure this header without putting the secret into chat or model-visible tool arguments?
Is there an owner-only settings page, secure credential form, or supported secret reference? Please provide the exact steps for Grok Bot, rather than Cursor editor’s mcp.json.
If this is not supported, is there an update on removing the legacy cursor:// callback from the Bot’s OAuth registration?
Hey, you dug in the right direction, and I need to correct my previous recommendation.
Right now, there’s no safe way in Grok Bot to set a custom HTTP header like CF-Access-Client-Secret. Connectors in Grok Bot authenticate only via OAuth. Tokens are stored on the connector backend, and the Bot calls tools without receiving them. There are no owner-only settings, no separate secrets form, and no secret reference for arbitrary headers in the Grok Bot UI. AddMcpServer.headers does exist at the API level, but there’s currently nowhere to enter a secret there safely, not via chat and not via model-visible tool args.
So the service token via headers approach I suggested applies to the mcp.json editor, but not to the current Grok Bot. Sorry about the confusion, that workaround isn’t available in the Bot yet.
So the practical path for you is to remove the legacy cursor:// callback from the OAuth registration. This is on our side, and we’re tracking it. The goal is still the same, only https and localhost callbacks should be sent during registration, and then your current Cloudflare setup will work without changes. I can’t share an exact timeline, but I’ll reply in this thread when there’s an update.
@deanrieRFC 8252: OAuth 2.0 for Native Apps | RFC Editor says that sending localhost in the list of redirect URIs is NOT recommended, and that the corresponding loopback IPs (127.0.0.1 for IPv4, [::1] for IPv6) should be used instead. Any idea if that is going to be part of the upcoming improvements? We’re running into this while trying to implement DCR in our own MCP.
Same issue with Grok Bot connecting to a Cloudflare Access Managed OAuth MCP server.
Cloudflare rejects the whole DCR request because redirect_uris includes
cursor://anysphere.cursor-mcp/oauth/callback. Cloudflare only allows https
URIs plus localhost/127.0.0.1 toggles, and has no option for custom schemes.
I have allowlisted https://www.cursor.com/* and enabled localhost; registration
still returns 400 “redirect_uri is not allowed by the account configuration”.
Cloudflare Access is a common gate for internal MCP servers, so this blocks
Grok Bot for any business using Zero Trust. Is there a target version?
@Vaughan-g-aus - yep, this is the exact same issue described above. Cloudflare Access Managed OAuth only accepts https in Allowed redirect URIs, plus the localhost or loopback toggles, and you can’t allowlist cursor://anysphere.cursor-mcp/oauth/callback there. Because of that, Cloudflare rejects the whole DCR registration. This is on our side, not your config, and we’re tracking it. The goal is that registration only sends https and localhost callbacks, and then your current Cloudflare setup will work with no changes. I can’t share a target version yet, but I’ll update this thread when there’s news.
@Charles_Wood - thanks, great callout on RFC 8252 §8.3. I passed it to the team as input for the registration flow work, and we’ll keep it in mind when revisiting what we send in redirect_uris. I can’t promise a specific implementation yet, like switching from localhost to 127.0.0.1 or [::1], but the team has it noted. If your own MCP can accept loopback in the IP form, that’s the most compatible option right now.