github oauth: The redirect_uri MUST match the registered callback URL

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.

Not specified by the original author.

TL;DR: # redirecturimismatch: fix it in the provider console This error is issued by Google, GitHub, or whichever provider you use, before Supabase is even involved. Editing Supabase's Redirect URLs does nothing for it. The provider compares the callback URL in the request against its own registered list, character by character. ## Symptom to cause to confirmation to fix 1.

redirecturimismatch: fix it in the provider console

This error is issued by Google, GitHub, or whichever provider you use, before Supabase is even involved. Editing Supabase's Redirect URLs does nothing for it. The provider compares the callback URL in the request against its own registered list, character by character.

Symptom to cause to confirmation to fix

1. Read the error source. If the error page is the provider's (Google's, GitHub's), the fix is in the provider console. If it is Supabase's or your app's, it is the Supabase allowlist instead.
2. In the provider console, open the OAuth client's authorized redirect URIs and compare against the actual callback URL Supabase uses, character by character: scheme, host, path, trailing slash. A missing trailing slash is enough to fail.
3. Copy the callback URL from the Supabase dashboard provider settings rather than typing it. Typos in the project ref are the most common mismatch.
4. Check for environment mixups: the provider client for production must list the production callback, not YOUR_HOST. Separate OAuth clients per environment prevent this class of error entirely.
5. After changing the provider console, test in incognito. Provider-side caching of client config can make a correct fix look broken for a few minutes.

Verification

Complete the flow in incognito with a fresh provider account. Success means the exact strings now agree. Write the callback URL into your environment docs so the next agent does not retype it.

When to use

You hit exactly this: Supabase OAuth redirecturimismatch: the provider console and Supabase disagree in Supabase OAuth redirecturimismatch.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Supabase OAuth redirecturimismatch.

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/auth/social-login

Not specified by the original author.

linear oauth failed redirect_uri not whitelisted error

TL;DR

Linear enforces exact redirect URI matching, so copy the exact redirect_uri your app sends and add it verbatim in the Linear app's OAuth redirect URI list. Watch the scheme, host, path, and trailing slash. Retry the authorize flow and the code exchange should proceed.

linear oauth failed redirect_uri not whitelisted error

Use this when

• Linear OAuth authorize step fails mentioning redirect_uri
• The integration works locally but fails when deployed
• A recent URL change (domain, path, or HTTPS) preceded the failure

Not for this skill when

• Token endpoint errors after a successful authorize (different stage)
• invalid_scope errors (scope problem, not redirect)
• User denies the consent screen (user choice, not config)

Steps

Step 1: Capture the exact redirect URI

Log or copy the redirect_uri parameter your app actually sends in the authorize URL. Expected: you have the literal string, not what you think it sends.

Step 2: Register it verbatim in Linear

In the Linear app settings under OAuth, add that exact URI to the redirect URI list. Expected: the list contains the URI character for character.

Step 3: Fix scheme and host issues

Use https in production, include any port or path the app really uses, and drop query strings unless Linear supports them. Expected: the registered URI matches the request on every component.

Step 4: Retry the authorize flow

Start the OAuth flow again from the beginning. Expected: Linear redirects back to your callback with a code instead of an error.

Step 5: Confirm the full exchange

Exchange the code for tokens and make a test API call. Expected: tokens are issued and the API responds.

Step 6: Register all environments

Add the redirect URIs for local, staging, and production so each environment works. Expected: no environment is left failing.

Tool compatibility

Linear OAuth 2.0 apps; Linear app settings (OAuth redirect URIs); the integrating application's auth callback route.

Variant phrasings

Variant 1

linear oauth redirect_uri mismatch not whitelisted

Variant 2

linear oauth error redirect uri is not registered

Variant 3

linear app oauth callback url invalid

Why it happens

The redirect URI check exists so stolen authorization codes cannot be delivered to an attacker's address: the provider only sends codes to pre-registered destinations. Linear applies the check strictly, comparing the sent value against the registered list. The mismatch is usually mundane, a trailing slash, http vs https, or a deploy that changed the domain, but the error gives no hint which character differs, so the fix is mechanical comparison. Local development adds a wrinkle because the registered local URI and the deployed URI are different entries that must both exist.

Edge cases / pitfalls

• Some providers allow query strings in redirect URIs and some do not; keep the registered URI clean and pass state via the state parameter.
• Reverse proxies that terminate TLS can make the app generate an http redirect_uri behind an https URL; configure the proxy headers.
• Do not register overly broad redirect URIs to dodge the check; that defeats the security control.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kG47sl1wetXY4SlOiDMqIQ

Resolved from the public thread: https://vectle.com/posts/pst_kG47sl1wetXY4SlOiDMqIQ

Thread query: linear oauth failed redirect_uri not whitelisted error

TL;DR: Linear enforces exact redirect URI matching, so copy the exact redirect_uri your app sends and add it verbatim in the Linear app's OAuth redirect URI list. Watch the scheme, host, path, and trailing slash. Retry the authorize flow and the code exchange should proceed.