Skip to main content
Applicable to: All customers — both SaaS and on-prem — trying to re-initiate authentication for MCP servers that were added to their IDE or desktop app (Cursor, Claude Desktop, Claude Code, OpenCode) before v0.148.0. MCPs that are already connected and working continue to work; only re-authentication with credentials cached before the change fails — those clients must re-register.
The following are not required and will not fix the issue on their own:
  • Rotating your Personal Access Token
  • Disconnecting / reconnecting MCP servers from the TrueFoundry UI
  • Clearing browser cookies or cache

​
What Is Changing

MCP OAuth Dynamic Client Registration (DCR) now enforces strict validation of the client_id and redirect URL on every authorization request. Previously, a client_id obtained during an earlier registration could be reused across sessions without re-validation. Starting with v0.148, the control plane will reject any authorization request that presents:
  • A client_id that does not match an active, in-scope registration, or
  • A redirect URL that was not registered as part of the original DCR flow.

​
Why This Change

MCP OAuth now applies stricter security validation of the client_id and redirect URL on every authorization request, instead of trusting a previously issued client_id indefinitely. This closes credential-reuse gaps and keeps each authorization tightly scoped. The trade-off is that credentials cached before the upgrade are no longer valid and must be re-registered through a fresh DCR handshake.

​
Who Is Affected

Some MCP clients may not work after upgrading — specifically those that cache the client_id from a previous session and reuse it for subsequent authorizations. This includes:
  • Cursor (IDE)
  • Claude Desktop
  • Claude Code (CLI)
  • Any other OAuth 2.0 client that persists DCR credentials locally
Typical error symptoms after upgrading. The primary symptom is a stale client_id failing validation at GET /:tenant/:server/authorize: 
{ "statusCode": 400, "message": "Invalid client_id" }
A redirect URL that was not registered during the original DCR flow returns: 
{ "statusCode": 400, "message": "redirect_uri '<uri>' is not registered for this client" }
You may also see { "statusCode": 400, "message": "Invalid state" } if a client replays a stale OAuth state blob, but this is a separate, secondary case from the client_id validation above.

​
What You Need to Do

​
1. Make sure the gateway is using the V2 OAuth flow

The strict client_id and redirect validation is enforced by the control plane (v0.148+). The gateway plane is what selects whether MCP clients use the older V1 flow or the new V2 flow. The two are versioned and shipped separately. This is the root of the broken connections: once the control plane is on v0.148 or later, the old V1 OAuth flow no longer works — so the gateway must be switched to the V2 flow. V2 is the default in gateway v0.148.2+, and can be enabled on earlier gateways via an env var. What you need to do depends on your deployment model:
TrueFoundry hosts both the control plane and the gateway.No action needed — TrueFoundry keeps the control plane on v0.148+ and the gateway on the V2 flow.

​
2. Reset cached credentials on each client

This step applies to every affected user across all deployment models, regardless of how the new flow was enabled. After upgrading, every client must drop the client_id it cached before the upgrade and re-register. The exact steps differ by client — for some, a restart is not enough.
  1. Open the Command Palette (Cmd+Shift+P / Ctrl+Shift+P) and run MCP: Clear All MCP Tokens to remove the cached OAuth credentials.
  2. Quit Cursor completely and relaunch it (tokens are cached at runtime, so a restart is required for the clear to take effect).
  3. Re-initiate the MCP connection so the client performs a fresh DCR handshake.
If you continue to experience issues after following the steps for your client, reach out and we’ll be happy to assist.