Quickstart: Vite + Supabase

The auth lifecycle API below requires @mordn/chat-widget 0.23.0 or later.

npm install '@mordn/chat-widget@^0.23.0' ai @ai-sdk/react

import { useEffect, useState } from 'react';
import type { Session } from '@supabase/supabase-js';
import { ChatWidget } from '@mordn/chat-widget';
import '@mordn/chat-widget/styles.css';
import { supabase } from '@/lib/supabase'; // your existing browser client
 
export function Assistant() {
  const [auth, setAuth] = useState<{
    session: Session | null;
    revision: number;
    ready: boolean;
  }>({ session: null, revision: 0, ready: false });
 
  useEffect(() => {
    // INITIAL_SESSION supplies the starting session. Keep this callback synchronous.
    const { data: { subscription } } = supabase.auth.onAuthStateChange((_event, session) => {
      setAuth((previous) => {
        // Local transition detection only; these ids are NOT sent to mordn.
        const changed = (previous.session?.user.id ?? null) !== (session?.user.id ?? null);
        return { session, revision: previous.revision + (changed ? 1 : 0), ready: true };
      });
    });
    return () => subscription.unsubscribe();
  }, []);
 
  if (!auth.ready) return null;
 
  return (
    <ChatWidget
      publishableKey="pk_live_…"
      authSessionKey={auth.revision}
      getUserToken={() => auth.session?.access_token ?? null}
    />
  );
}

getUserToken returns the Supabase access token — a JWT your project signed. The widget sends it as Authorization: Bearer …; mordn verifies the signature against your project's JWKS and binds the conversation to the token's sub. It is re-read every few minutes (every four minutes) for token maintenance. Changing the callback identity or re-rendering does not trigger token resolution.

The subscription publishes the session and authSessionKey revision together. It waits for INITIAL_SESSION before mounting, increments on login/logout/account switch, and keeps the revision stable for TOKEN_REFRESHED or repeated SIGNED_IN events for the same user. It still stores every refreshed token. Logout then login as the same user increments twice, even when React batches the state updates. The ids used for this local comparison are never sent as authoritative identity. Do not replace the revision with a token or a constant. If your existing auth provider hides intermediate logout transitions, give each new login a revision or unique session id of its own.

On a lifecycle change, the widget drops old auth/bootstrap/mounted chat state and waits for the latest getter before bootstrapping — it does not temporarily fall back to an anonymous visitor. If you already own the auth state in a provider, publish its session and revision there instead of installing a second auth source.

Alternatively, attach a ChatWidgetHandle ref and call resetAuth() from your existing auth transition handler after updating the getter's session source. Do not reset immediately after setting React state that the getter still closes over; prefer the reactive key shown here. Use one mechanism, never a render or token-refresh reset loop. See the hosted lifecycle reference.

Want signed-out visitors to get a chat too? Add the anonymous prop (and anonymousEnabled on the agent). Each browser gets its own history under an anon: id; when the visitor signs in, the lifecycle revision switches them to their signed-in scope. Reset does not erase persisted history/drafts; call clearChatStorage() on sign-out/account switch if your policy requires erasure (the anonymous visitor id is retained). Also clear/update your own conversationId, initialMessages, and any other user-specific props. Only the server-verified token authorizes access; neither the revision nor reset revokes tokens or replaces server authorization.

npm run dev, sign in, open the assistant, type. Reload — the conversation is still there. Open a second browser profile: a different user, a different history.