Fix a Supabase password reset link that opens localhost

If a password reset email opens localhost on a deployed app, trace how its destination is chosen before changing the password flow. Supabase uses its configured Site URL as a default when a redirect is absent. Your application can also explicitly request the wrong origin. Follow Supabase's redirect URL guide while checking the deployed project.

Check the destination in order

1. Check the deployed application origin. Open the deployed app at the intended HTTPS domain and inspect the configuration or code that builds its reset redirect. A local fallback or a stale deployment setting can produce a localhost URL even when the site itself loads correctly. Redeploy if your host requires it after a configuration change.
2. Inspect the email destination safely. In a reset email sent to a test account, inspect the link without opening or sharing it. Identify the host and any redirect destination, but do not copy tokens or the complete link into logs, tickets, or chat. The email may first point to Supabase and then redirect to your app; inspect the destination, not just the first host.
3. Check the requested redirect. Find the call to resetPasswordForEmail and inspect its redirectTo option, if present. It should use your intended deployed origin and a recovery route that your application handles. If no redirect is supplied, check the project's Site URL. Keep local and deployed origins appropriate to their respective environments.
4. Check the Supabase URL configuration. In the correct Supabase project, verify the Site URL and that the requested redirect matches an allowed Redirect URL, including its scheme, host, port, and path. Follow the provider guide for supported matching patterns; use the narrowest URLs that fit your deployments.
5. Check the reset email template. Inspect the recovery template for a hard-coded localhost URL or a customized link that discards the intended redirect. Compare it with the provider's supported template variables before changing it.
6. Request a fresh link. After saving the relevant settings and deploying any app change, request a new reset email and verify it reaches the intended recovery page. Complete the reset with the test account to verify the full flow.

If no email arrives, investigate delivery and spam separately; a redirect change cannot prove delivery. If the destination is correct but the link is expired or already used, request a fresh link and investigate the token lifetime and recovery flow separately. Never share a live recovery link while debugging.

For a CoreMVP project, recovery links return to /auth/reset-password. Configure that deployed URL as described in Deploy Supabase, then follow Test Authentication for local checks and hosted verification. A passing local test does not prove hosted email or redirect settings.