I built an open-source CLI to diagnose Supabase Auth/OAuth configuration issues

[alalmaiesa-glitch]

I kept running into the same class of Supabase Auth problems across projects: disabled OAuth providers, incorrect redirect URLs, Site URL mismatches, SSR/PKCE callback issues, and environment configuration mistakes.
So I built supabase-auth-doctor, a small open-source, read-only CLI that checks the project itself and reports clear PASS / WARN / FAIL / UNKNOWN results with actionable fixes.
Run it with:
npx supabase-auth-doctor

It currently checks:

• Supabase project URL and public key configuration
• OAuth provider availability
• /auth/v1/settings
• provider callback URLs
• redirectTo usage
• @supabase/ssr
• missing exchangeCodeForSession(code) in PKCE flows
• Site URL mismatches
• Vercel production / preview configuration
• .env.local vs .env.example
• optional dashboard Auth configuration through a scoped Management API token
  The tool does not modify the project and is designed not to print secrets.
  GitHub:
  https://github.com/alalmaiesa-glitch/supabase-auth-doctor
  npm:
  https://www.npmjs.com/package/supabase-auth-doctor
  I’d especially like to hear about real Supabase Auth failures it does not detect yet. Those cases will drive the next version.

[elijahbrownsk-png]

A few failures I've run into that might be worth checking for:

• Email templates still using {{ .ConfirmationURL }} while the app uses the SSR/PKCE flow with a /auth/confirm route that expects token_hash. The confirmation link works in some setups and quietly fails in others.
• No custom SMTP on a project that's about to go live. The built-in sender only delivers to your team's addresses and has a low hourly limit, so real users sign up, never get the email, and nothing errors on the client.
• Auth hooks switched on in the dashboard (Before User Created, Custom Access Token) pointing at an endpoint that's down or slow. Every signup or token refresh fails and the error the user sees doesn't point at the hook. Just listing which hooks are enabled and where they point would save people time.
• Confirmation and magic links opened by corporate mail scanners before the person clicks, which uses up the one-time token and shows up as "link expired". You can't detect that from config, but a WARN when templates link straight to the verify endpoint would point people at the cause.