How to Do Supabase Auth Setup on Claude Code

Claude Code can scaffold a complete Supabase Auth integration, including client setup, email/OAuth providers, Row Level Security (RLS) policies, and protected API routes, using a handful of focused prompts. This guide is for developers building on Next.js, SvelteKit, or similar frameworks who want to stay in flow without bouncing between docs. Use Usagebar to monitor your Claude Code usage while running multi-step scaffolding sessions like this one, so a 5-hour lockout never interrupts a critical auth PR.

• Supabase Auth supports email/password, magic links, OAuth providers, and phone OTP out of the box.
• RLS policies are the most common source of auth bugs and deserve their own focused Claude Code prompt.
• A full auth scaffold (client, middleware, RLS, protected routes) typically consumes a meaningful token budget, making usage visibility essential.

What is Supabase Auth and why set it up with Claude Code?

Supabase Auth is the managed authentication layer built into every Supabase project. It handles user sessions via JWTs, stores users in a dedicated auth.users table, and exposes a JavaScript/TypeScript client through @supabase/supabase-js. Setting it up correctly means configuring the client, enabling providers, writing RLS policies, and wiring session handling into your framework's middleware.

That's four distinct surfaces. Claude Code excels here because it can hold the full context of your project structure, generate boilerplate, explain policy logic, and iterate on errors, all without you leaving the terminal. The key is knowing which prompts to use in which order.

How to set up Supabase Auth in Claude Code: step by step

1. Install dependencies and initialize the Supabase client

Start a Claude Code session in your project root and give it a clear starting prompt:

Install @supabase/supabase-js and @supabase/ssr. Create a Supabase client utility at lib/supabase/client.ts for browser usage and lib/supabase/server.ts for server-side usage, reading NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY from environment variables.

Claude Code will generate the files, import correctly from @supabase/ssr (the modern server-safe package), and flag which env vars need to be set. If you are using SvelteKit or Remix, specify your framework explicitly so it generates the right module pattern.

2. Enable authentication providers in Supabase dashboard

This step is manual: go to your Supabase project dashboard, navigate to Authentication > Providers, and enable the providers you need (Email, Google, GitHub, etc.). Once done, tell Claude Code which providers are active so it generates matching UI and callback logic:

I've enabled Email and GitHub OAuth in the Supabase dashboard. Generate a sign-in page with both options and the corresponding OAuth callback route at /auth/callback.

Claude Code will produce the callback handler that exchanges the auth code for a session using Supabase's server-side auth helpers.

3. Add middleware for session management

Session refresh must happen at the middleware layer to keep server components and API routes in sync. Prompt Claude Code directly:

Add a middleware.ts file that refreshes the Supabase session on every request and protects /dashboard and /account routes by redirecting unauthenticated users to /login.

This generates a Next.js middleware.ts (or equivalent) that calls supabase.auth.getUser() server-side, which is the recommended approach for protecting routes without relying on the less secure getSession().

4. Write Row Level Security (RLS) policies

RLS is where most auth setups break in subtle ways. Give Claude Code the schema context it needs:

I have a `profiles` table with columns: id (uuid, references auth.users), username (text), avatar_url (text). Write RLS policies so users can only read and update their own row. Also write a policy allowing public read access to username and avatar_url.

Claude Code will output SQL CREATE POLICY statements using auth.uid(). You can paste these directly into the Supabase SQL editor or include them in a migration file. Ask it to also generate the migration file if you're using Supabase CLI migrations.

5. Test the auth flow end to end

Once the scaffold is in place, use Claude Code to generate a quick smoke-test script or ask it to review your implementation for common mistakes:

Review the auth implementation for common Supabase mistakes: missing RLS enablement, using getSession() instead of getUser() server-side, and missing cookie options in the SSR client.

This acts as a checklist pass and often catches issues before they reach production.

Useful Claude Code slash commands for this workflow

Claude Code's slash commands help keep long sessions organized. The most relevant ones for a Supabase Auth setup:

• /clear: Reset context between major phases (client setup vs. RLS vs. middleware) to avoid prompt drift.
• /memory: Store your Supabase project URL, enabled providers, and table schema so you don't repeat them every prompt.
• /usage: Check your current token consumption mid-session. Essential when running a multi-step scaffold like this one.
• /review: Ask Claude Code to do a final review pass on the entire auth implementation before committing.

See the full Claude Code slash commands list for more options.

Common mistakes when using Claude Code for Supabase Auth

• Using getSession() server-side: This reads from cookies without re-validating with the Supabase Auth server. Always use getUser() on the server. Claude Code will use the correct one if you specify "server-side" in your prompt.
• Forgetting to enable RLS on tables: RLS policies do nothing if RLS is not enabled on the table. Prompt Claude Code to include ALTER TABLE profiles ENABLE ROW LEVEL SECURITY; in the migration.
• Not configuring the site URL: OAuth and magic link callbacks will fail if your site URL isn't set in Supabase dashboard under Authentication > URL Configuration. Claude Code won't configure this for you since it's a dashboard setting.
• Mixing browser and server clients: The @supabase/ssr package exports separate helpers for browser and server. Prompt Claude Code to generate both and be explicit about which context each file runs in.

How to track Claude Code usage during long auth sessions

A full Supabase Auth setup, covering client init, multiple providers, middleware, RLS policies, and a test pass, is a multi-step session that consumes a meaningful portion of your usage window. Running into a usage limit mid-session means a 5-hour wait before you can continue, right when you're in the middle of debugging a policy.

You can check usage at any point with the /usage command in Claude Code or at claude.ai/settings/usage. For real-time awareness without context switching, Usagebar sits in your macOS menu bar and shows live usage with smart alerts at 50%, 75%, and 90% thresholds. It stores your credentials securely in the macOS Keychain and shows you exactly when your usage window resets, so you can plan which steps to tackle before the limit hits.

Pricing is pay-what-you-want, with a free tier available for students.

Key takeaways

• Break the setup into four focused prompts: client init, middleware, OAuth callback, and RLS policies. One prompt per surface keeps Claude Code's output clean and reviewable.
• Always specify "server-side" when generating session-handling code to get getUser() instead of getSession().
• Provide your table schema upfront when asking for RLS policies, so Claude Code generates correct auth.uid() references.
• Use /usage or Usagebar to track token consumption before starting the RLS and middleware phases, which are the most token-intensive.
• Check the JWT authentication guide if you need custom token claims on top of Supabase Auth.

Sources

• Supabase Auth documentation
• Supabase server-side auth for Next.js
• Protecting routes with middleware (Supabase)
• Supabase CLI migration reference