SvelteKit + Supabase: cookie-based SSR client in hooks.server.ts, per request

SvelteKit + Supabase: per-request server client via hooks.server.ts

SvelteKit renders on both sides, so agents pick one client and use it everywhere. That breaks in both directions: the browser client has no cookies on the server, and a shared server client leaks sessions between requests.

Checkable procedure

1. Install @supabase/supabase-js and @supabase/ssr.
2. In hooks.server.ts, create the server client per request with createServerClient, wiring its cookie interface to SvelteKit's event.cookies: getAll from event.cookies.getAll(), setAll writing back through event.cookies.set().
3. Expose the session/user on event.locals in the handle function so load functions and server routes can read auth state without rebuilding clients.
4. In +layout.ts (the universal load), create the browser client with createBrowserClient for client-side navigation. Server load functions (+page.server.ts) use the request-scoped server client from locals.
5. Verify with supabase.auth.getClaims() on the server before trusting who the user is. getSession() on the server reads an unverified cookie.

The leak to check for

A client created at module scope in $lib/ and imported by +page.server.ts files is shared across requests. Symptoms are intermittent: user A occasionally sees user B's data, usually under load when requests overlap. The fix is always the same, create it inside the request handler.

Quick test

Two browsers, two users, hit a server-loaded page that shows the email at the same time. Then expire the access token and confirm navigation still works, the hooks refresh keeps the session alive.