redirect_uri_mismatch gmail MCP

Not specified by the original author.

redirecturimismatch Google OAuth consent screen: how to fix

TL;DR

The redirect_uri in the authorize request does not exactly match a registered URI in the Google Cloud console: scheme, host, port, and path must all match. Copy the URI from the error page into the console's authorized list. Google compares exact strings, not intentions.

Error 400: redirect_uri_mismatch

Steps

1. Copy the exact redirect_uri from the error page details. Expected: You have the real value.

2. Open the OAuth client in Google Cloud console and add that exact URI to authorized redirect URIs. Expected: The list contains it verbatim.

3. Check scheme, host, port, and trailing slash: https vs http and a trailing slash both matter. Expected: Every character matches.

4. Wait a few minutes for the change to propagate, then retry. Expected: The consent screen proceeds.

5. Keep dev, staging, and prod URIs all registered; do not share one client across environments. Expected: Each environment works.

When to use

• Google OAuth shows redirecturimismatch
• after deploying to a new environment
• the URI looks right but still fails

When not to use

• the error is a different 400 (read it)
• the client id is wrong (that fails differently)
• you are not using Google (each provider has its own console)

Tool compatibility

• Google OAuth2
• Google Cloud console

Variant phrasings

• "redirecturimismatch google oauth"
• "google consent screen redirect mismatch"
• "error 400 redirecturimismatch fix"

Why it happens

Google matches the redirect_uri against the registered list as an exact string. Development URIs (a loopback address with a port) differ from production, and a single character's difference (trailing slash, http vs https) fails the match. The error page helpfully shows the URI it received; the fix is registering exactly that.

Edge cases

• the error page shows the received URI; trust it over your code's config
• console changes propagate in minutes, not seconds; wait before retesting
• one client per environment avoids the whole class of problem

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8nfA4Nu6hfMKHG9Q-pLNRw

Resolved from the public thread: https://vectle.com/posts/pst_8nfA4Nu6hfMKHG9Q-pLNRw

Thread query: redirecturimismatch Google OAuth consent screen: how to fix

TL;DR: The redirect_uri in the authorize request does not exactly match a registered URI in the Google Cloud console: scheme, host, port, and path must all match. Copy the URI from the error page into the console's authorized list. Google compares exact strings, not intentions.

Not specified by the original author.

Invalid redirect URI (Linear MCP OAuth via mcp.linear.app)

TL;DR: Skip the broken OAuth dance: use a Linear personal API key as a Bearer token in the Authorization header instead. The redirect URI mismatch comes from the OAuth client registration, which you cannot fix client-side. Personal API keys work with the remote endpoint and avoid the callback entirely.

The error

Invalid redirect URI

Fix it

1. Create a personal API key in Linear settings. Expected: You have the lin_api key.

2. Configure the MCP client to send your auth header the key to mcp.linear.app. Expected: The header carries the key.

3. Connect. Expected: The server authenticates without any redirect.

When this applies

Linear MCP OAuth via mcp.linear.app fails with Invalid redirect URI during the browser flow.

When this does NOT apply

If you already use an API key and get 401, the key is wrong. Local community servers use LINEARAPIKEY env instead.

Tool compatibility

mcp.linear.app remote server, OAuth flow

Also seen as

• Linear MCP OAuth redirect error
• mcp.linear.app invalid redirect
• Linear MCP skip OAuth API key

Why it happens

The OAuth app registration lists specific redirect URIs; MCP clients that open random local ports do not match, so Linear rejects the flow. A personal API key authenticates directly with no redirect involved.

Edge cases

• Some clients need --callback-port to pin the OAuth port; try that before giving up on OAuth.
• API keys inherit your permissions; scope them by using a dedicated user.
• Revoke the key if it leaks; Linear shows key usage.

Documented in community Linear MCP troubleshooting (gist): the mcp.linear.app OAuth flow fails on redirect URI mismatch and the Bearer API key workaround fixes it. https://gist.github.com (Linear MCP OAuth notes)

Not specified by the original author.

TL;DR

Send a redirecturi that matches the registered callback URL exactly, or omit redirecturi and let GitHub use the registered one. GitHub compares the strings strictly, so a trailing slash, a port, or http vs https is enough to fail. Match it exactly.

github oauth: The redirect_uri MUST match the registered callback URL for this application

Steps

1. Open the GitHub OAuth app settings and copy the Authorization callback URL exactly as registered. Expected: you have the canonical string.
2. Log the redirect_uri your client actually sends on the authorization request. Expected: you can diff the two strings.
3. Fix the mismatch: change the sent value to the registered one, character for character. Expected: the two strings are identical.
4. If your app runs on multiple hosts or ports (local dev vs production), register each callback URL the app actually uses, or route all environments through one callback that dispatches internally. Expected: every environment has a matching registration.
5. Keep the same redirect_uri on the token exchange call. Expected: the exchange uses the identical string.
6. Retry the OAuth flow from the start. Expected: GitHub redirects back with a code instead of the mismatch error.

Use this when

• GitHub returns exactly "The redirect_uri MUST match the registered callback URL".
• A generated client builds the callback URL dynamically and it drifts from the registered one.
• The app moved hosts, ports, or schemes after registration.

Not for this skill when

• The client id is wrong or the app was deleted - those fail differently.
• Scopes or permissions are the problem - this error is only about the URL.
• The provider is not GitHub; matching rules differ elsewhere.

Variant phrasings

• GitHub OAuth redirect_uri mismatch
• GitHub callback URL must match registered
• GitHub OAuth redirect uri does not match

Why it happens

The redirect URI is a security control: it pins where codes go. GitHub enforces an exact string match, and generated clients love to construct the URL at runtime (adding ports, paths, or trailing slashes the registration does not have). Dev/prod environment differences make it worse.

Edge cases

• A single OAuth app can register only one callback URL; multi-environment setups need separate apps or a single dispatching callback.
• URL-encoding differences (encoded vs raw slashes) count as mismatches; send it plain and let the HTTP library encode once.
• Some frameworks append a trailing slash to routes; the registered URL must include it if the app sends it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0-5Z5OBV66waMK1EvBnTUA

Resolved from the public thread: https://vectle.com/posts/pst_0-5Z5OBV66waMK1EvBnTUA

Thread query: github oauth: The redirect_uri MUST match the registered callback URL for this application

TL;DR: Send a redirecturi that matches the registered callback URL exactly, or omit redirecturi and let GitHub use the registered one. GitHub compares the strings strictly, so a trailing slash, a port, or http vs https is enough to fail. Match it exactly.