[GH-ISSUE #986] useSession on client return cached session instead of fetching #25858

New Issue

GiteaMirror · 2026-04-17T16:08:42-05:00

GiteaMirror commented

2026-04-17 16:08:42 -05:00

Originally created by @daveycodez on GitHub (Dec 21, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/986

Is this suited for github?

Yes, this is suited for github

No response

Describe the solution you'd like

If I'm using the useSession hook, whenever I refresh the page it sends an API request to get-session. We should already have the session locally, though. A comparison would be Supabase, their useSession hook does not send any requests unless the session is expired. Having to fetch the session when it already exists locally will make sites feel slower on initial load, and incur unnecessary bandwidth on the API. useSession needs to return the cached session on mount

Describe alternatives you've considered

useSession hook return cached session immediately on client, only fetch get-session if it is expired.

Additional context

No response

Originally created by @daveycodez on GitHub (Dec 21, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/986 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. _No response_ ### Describe the solution you'd like If I'm using the useSession hook, whenever I refresh the page it sends an API request to get-session. We should already have the session locally, though. A comparison would be Supabase, their useSession hook does not send any requests unless the session is expired. Having to fetch the session when it already exists locally will make sites feel slower on initial load, and incur unnecessary bandwidth on the API. useSession needs to return the cached session on mount ### Describe alternatives you've considered useSession hook return cached session immediately on client, only fetch get-session if it is expired. ### Additional context _No response_

GiteaMirror added the locked label 2026-04-17 16:08:42 -05:00

GiteaMirror closed this issue

2026-04-17 16:08:43 -05:00

GiteaMirror commented

2026-04-17 16:08:44 -05:00

@Bekacru commented on GitHub (Dec 22, 2024):

The session cache is stored as an HTTP-only cookie, and the server needs to validate that the token is properly signed before sending back the session data. If there is no API request, it would mean storing the session in a way that js can read it, which isn’t ideal and is not recommended. Supabase do this mostly cause they don't have any other option since 3rd party cookies nowdays get blocked by browsers.

@Bekacru commented on GitHub (Dec 22, 2024): The session cache is stored as an HTTP-only cookie, and the server needs to validate that the token is properly signed before sending back the session data. If there is no API request, it would mean storing the session in a way that js can read it, which isn’t ideal and is not recommended. Supabase do this mostly cause they don't have any other option since 3rd party cookies nowdays get blocked by browsers.

GiteaMirror commented

2026-04-17 16:08:44 -05:00

@daveycodez commented on GitHub (Dec 22, 2024):

Makes sense. I'm also seeing that it's unsafe to store JWT in localStorage so I need to update some things there. Is it possible to have get-session return the jwt as well? I also saw examples of storing Bearer in localStorage, isn't that vulnerable to XSS attacks?

@daveycodez commented on GitHub (Dec 22, 2024): Makes sense. I'm also seeing that it's unsafe to store JWT in localStorage so I need to update some things there. Is it possible to have get-session return the jwt as well? I also saw examples of storing Bearer in localStorage, isn't that vulnerable to XSS attacks?

GiteaMirror commented

2026-04-17 16:08:45 -05:00

@Bekacru commented on GitHub (Dec 22, 2024):

Yeah, it’s vulnerable to XSS, but it’s all about trade-offs. If an attacker manages to pull off an XSS attack, they can already send requests directly to your server, so stealing tokens might not even be even that important. They can do a lot of things. So, locking down your site against XSS should be the first priorit and it’s pretty straightforward these days. And, JWTs can easily get too large for cookies, so local storage makes more sense. It’s not perfect, but as long as you’re aware of the risks and have proper security measures in place, it’s a workable option.

@Bekacru commented on GitHub (Dec 22, 2024): Yeah, it’s vulnerable to XSS, but it’s all about trade-offs. If an attacker manages to pull off an XSS attack, they can already send requests directly to your server, so stealing tokens might not even be even that important. They can do a lot of things. So, locking down your site against XSS should be the first priorit and it’s pretty straightforward these days. And, JWTs can easily get too large for cookies, so local storage makes more sense. It’s not perfect, but as long as you’re aware of the risks and have proper security measures in place, it’s a workable option.

GiteaMirror commented

2026-04-17 16:08:45 -05:00

@daveycodez commented on GitHub (Dec 22, 2024):

In this case wouldn't it also be fine to store the sessionData cached on localStorage so it can be used immediately on page load, so other requests (e.g. getMyProfile /api/profile/me) aren't dependent on waiting for that first getSession API request to resolve. Something like useOptimisticSession that returns it from localStorage and gets revalidated instead of starting as null.

Right now it goes like ->

(Slow Network example on edit-profile page)

Wait for Page Load (300ms)
Wait for getSession API Request (network latency - 300ms)
Get Current Profile from API (custom profiles sql table) (300ms)
Total time to render - 900ms

Whereas if we had it cached it would be...

Wait for Page Load (300ms)
Load cached sessionData (disk read latency) (~0ms)
Fire getSession (revalidate) and getCurrentProfile simultaneously (~300ms)
Total time to render - ~600ms

Another example is headers with Avatars (image field).

Use cached sessionData (~0ms)
Render avatar (~0ms after page load) & revalidate getSession

vs currently

Wait for getSession(300ms)
Render Avatar (300ms time to render after page load)

I know I could make my own useOptimisticSession hook and cache it in localStorage but wouldn't it be better for all sites using better-auth to have faster perceived load times, or maybe even a config option for optimisticSessions (boolean)

@daveycodez commented on GitHub (Dec 22, 2024): In this case wouldn't it also be fine to store the sessionData cached on localStorage so it can be used immediately on page load, so other requests (e.g. getMyProfile /api/profile/me) aren't dependent on waiting for that first getSession API request to resolve. Something like useOptimisticSession that returns it from localStorage and gets revalidated instead of starting as null. Right now it goes like -> **(Slow Network example on edit-profile page)** 1. Wait for Page Load (300ms) 2. Wait for getSession API Request (network latency - 300ms) 3. Get Current Profile from API (custom profiles sql table) (300ms) Total time to render - 900ms **Whereas if we had it cached it would be...** 1. Wait for Page Load (300ms) 2. Load cached sessionData (disk read latency) (~0ms) 3. Fire getSession (revalidate) and getCurrentProfile simultaneously (~300ms) Total time to render - ~600ms ### Another example is headers with Avatars (image field). 1. Use cached sessionData (~0ms) 2. Render avatar (~0ms after page load) & revalidate getSession **vs currently** 1. Wait for getSession(300ms) 2. Render Avatar (300ms time to render after page load) I know I could make my own useOptimisticSession hook and cache it in localStorage but wouldn't it be better for all sites using better-auth to have faster perceived load times, or maybe even a config option for optimisticSessions (boolean)

GiteaMirror commented

2026-04-17 16:08:46 -05:00

@daveycodez commented on GitHub (Dec 22, 2024):

The only concern I think with using localStorage is storing PII like email? But storing the JWT would also do that in its current state?

use-optimistic-session.ts

import { useEffect, useState } from "react"
import { useSession } from "@/lib/auth-client"

export function useOptimisticSession() {
    const { data: sessionData, isPending: sessionPending } = useSession()
    const [session, setSession] = useState(sessionData)
    const [isPending, setIsPending] = useState(true)

    // Load session from localStorage
    useEffect(() => {
        if (session) return

        const cachedSession = localStorage.getItem("session")

        if (cachedSession) {
            const sessionData = JSON.parse(cachedSession)
            if (new Date(sessionData.session.expiresAt) < new Date()) {
                localStorage.removeItem("session")
                return
            }

            setSession(sessionData)
            setIsPending(false)
        }
    }, [session])

    // Update session on revalidation
    useEffect(() => {
        if (isPending) setIsPending(sessionPending)
        if (sessionPending) return

        setSession(sessionData)

        if (sessionData) {
            localStorage.setItem("session", JSON.stringify(sessionData))
        } else {
            localStorage.removeItem("session")
        }
    }, [isPending, sessionData, sessionPending])

    return { session, isPending }
}

@daveycodez commented on GitHub (Dec 22, 2024): The only concern I think with using localStorage is storing PII like email? But storing the JWT would also do that in its current state? use-optimistic-session.ts ```ts import { useEffect, useState } from "react" import { useSession } from "@/lib/auth-client" export function useOptimisticSession() { const { data: sessionData, isPending: sessionPending } = useSession() const [session, setSession] = useState(sessionData) const [isPending, setIsPending] = useState(true) // Load session from localStorage useEffect(() => { if (session) return const cachedSession = localStorage.getItem("session") if (cachedSession) { const sessionData = JSON.parse(cachedSession) if (new Date(sessionData.session.expiresAt) < new Date()) { localStorage.removeItem("session") return } setSession(sessionData) setIsPending(false) } }, [session]) // Update session on revalidation useEffect(() => { if (isPending) setIsPending(sessionPending) if (sessionPending) return setSession(sessionData) if (sessionData) { localStorage.setItem("session", JSON.stringify(sessionData)) } else { localStorage.removeItem("session") } }, [isPending, sessionData, sessionPending]) return { session, isPending } } ```

GiteaMirror commented

2026-04-17 16:08:46 -05:00

@Bekacru commented on GitHub (Dec 23, 2024):

I think this should currently be handled by users rather than from the lib. Specifically, revalidating the cache becomes a problem. for example, if the user updates their info, the cookie cache will get overridden by the server. To do the same on the client, we would then need to track which endpoint is being calle and invalidate it which introduces a lot of complexity.

@Bekacru commented on GitHub (Dec 23, 2024): I think this should currently be handled by users rather than from the lib. Specifically, revalidating the cache becomes a problem. for example, if the user updates their info, the cookie cache will get overridden by the server. To do the same on the client, we would then need to track which endpoint is being calle and invalidate it which introduces a lot of complexity.

GiteaMirror commented

2026-04-17 16:08:47 -05:00

@daveycodez commented on GitHub (Dec 23, 2024):

Since I'm just caching sessionData and refreshing it wouldn't it be the same outcome though? It still calls getSession on page load, which gets the latest session data and overrides the localStorage cache with the new data.

Another thing I think we need is a way to manually refresh the session coming from useSession hook. Like a refresh or reload function. In SWR they have revalidations trigger on page focus. Currently the useSession hook won't show you an updated email address or any other updated field to the user unless you do a hard refresh.

I definitely think default built in functionality for caching sessionData, revalidating on page focus, and proper retry on network failure is a necessity for any modern web application

@daveycodez commented on GitHub (Dec 23, 2024): Since I'm just caching sessionData and refreshing it wouldn't it be the same outcome though? It still calls getSession on page load, which gets the latest session data and overrides the localStorage cache with the new data. Another thing I think we need is a way to manually refresh the session coming from useSession hook. Like a refresh or reload function. In SWR they have revalidations trigger on page focus. Currently the useSession hook won't show you an updated email address or any other updated field to the user unless you do a hard refresh. I definitely think default built in functionality for caching sessionData, revalidating on page focus, and proper retry on network failure is a necessity for any modern web application

GiteaMirror commented

2026-04-17 16:08:48 -05:00

@Bekacru commented on GitHub (Dec 23, 2024):

If you need to control how session is cached and how and when refetch is triggered including onFocus and other advanced functionalities, you can use getSession with swr or react query instead. Said that, the session is cached in memory as it's with swr. Meaning calling useSession in two components doesn't trigger 2 different fetch requests. But local storage caching is a different story. We should probably mention using those libraries for advanced use cases for fetching session on the client.

@Bekacru commented on GitHub (Dec 23, 2024): If you need to control how session is cached and how and when refetch is triggered including onFocus and other advanced functionalities, you can use `getSession` with swr or react query instead. Said that, the session is cached in memory as it's with swr. Meaning calling `useSession` in two components doesn't trigger 2 different fetch requests. But local storage caching is a different story. We should probably mention using those libraries for advanced use cases for fetching session on the client.

GiteaMirror commented

2026-04-17 16:08:48 -05:00

@daveycodez commented on GitHub (Dec 23, 2024):

Yea I know I can write the hooks, but I was kind of hoping to see this built in since everyone would benefit from the useSession hook having these features, both devs and all users of any site that has better-auth. Optimized out of the box without needing custom hooks on top of it. If there's no chance of this getting added to the library itself then I may just make a better-auth-swr package that can be used alongside it, but I feel like anyone using better-auth on a React based project definitely needs these features

@daveycodez commented on GitHub (Dec 23, 2024): Yea I know I can write the hooks, but I was kind of hoping to see this built in since everyone would benefit from the useSession hook having these features, both devs and all users of any site that has better-auth. Optimized out of the box without needing custom hooks on top of it. If there's no chance of this getting added to the library itself then I may just make a better-auth-swr package that can be used alongside it, but I feel like anyone using better-auth on a React based project definitely needs these features

GiteaMirror commented

2026-04-17 16:08:49 -05:00

@Bekacru commented on GitHub (Dec 23, 2024):

Oh yeah, the library idea would be great. And if we had a dedicated React package, this would definitely make sense. The only thing we do for each framework (Vue, React, Svelte...) is provide a very lightweight adapter. For example, for the client, we just call the nanostore atoms with the respective useStore hooks and nothing else. In the future, we may have a dedicated adapter, but for now, since we're keeping better-auth as a single package, we try to avoid framework-specific code as much as possible.

@Bekacru commented on GitHub (Dec 23, 2024): Oh yeah, the library idea would be great. And if we had a dedicated React package, this would definitely make sense. The only thing we do for each framework (Vue, React, Svelte...) is provide a very lightweight adapter. For example, for the client, we just call the nanostore atoms with the respective `useStore` hooks and nothing else. In the future, we may have a dedicated adapter, but for now, since we're keeping `better-auth` as a single package, we try to avoid framework-specific code as much as possible.

GiteaMirror commented

2026-04-17 16:08:49 -05:00

@Nicolab commented on GitHub (Dec 28, 2024):

Better-auth agnostic, it's great. I think also this should currently be handled by users (or another lib) rather than from better-auth lib.

I use Vue.js and React, the two have a different logic. If it can be useful to someone, here's how I do it with Vue.js:

watch(() => currentSession.value, (newVal) => {
    if (newVal.session.isPending || newVal.session.isRefetching) {
      appStore.user.value = null
      return
    }

    appStore.user.value = newVal?.user
}, { immediate: true })

By the way, from there, it's possible to synchronize the localStorage ;)

@Nicolab commented on GitHub (Dec 28, 2024): Better-auth agnostic, it's great. I think also this should currently be handled by users (or another lib) rather than from better-auth lib. I use Vue.js and React, the two have a different logic. If it can be useful to someone, here's how I do it with Vue.js: ```ts watch(() => currentSession.value, (newVal) => { if (newVal.session.isPending || newVal.session.isRefetching) { appStore.user.value = null return } appStore.user.value = newVal?.user }, { immediate: true }) ``` By the way, from there, it's possible to synchronize the localStorage ;)

GiteaMirror commented

2026-04-17 16:08:50 -05:00

@daveycodez commented on GitHub (Dec 28, 2024):

I don't think Vue uses the useSession React hook, the feature suggestion was for the React hook itself to reduce amount of "auth code" in the application. Plug and play with necessary features that every React app using better-auth would benefit from without having to re-write it manually and document it for every application. Yes we could all write our own logic to do these things. But we could also roll our own auth, right.

A feature like this is better to have built in than to Google through GitHub issues to figure out how to self implement, or just have a separate "official" better-auth-react library that might even be community managed. I think a lot of devs might not think of this issue even, so the users of those applications suffer the extra latency

@daveycodez commented on GitHub (Dec 28, 2024): I don't think Vue uses the useSession React hook, the feature suggestion was for the React hook itself to reduce amount of "auth code" in the application. Plug and play with necessary features that every React app using better-auth would benefit from without having to re-write it manually and document it for every application. Yes we could all write our own logic to do these things. But we could also roll our own auth, right. A feature like this is better to have built in than to Google through GitHub issues to figure out how to self implement, or just have a separate "official" better-auth-react library that might even be community managed. I think a lot of devs might not think of this issue even, so the users of those applications suffer the extra latency

GiteaMirror commented

2026-04-17 16:08:50 -05:00

@Nicolab commented on GitHub (Dec 29, 2024):

UseSession() is a Nanostore, not a React hook. So Vue.js use also useSession() provided by Better-auth.
Yes like you say, a different package for React would be relevant. That also open the door for Vue.js, Solid.js, Angular, htmx, Alpine, Astro, etc. So a list of external adapters is more clean, instead of bloat the main package with several useless dependencies.

@Nicolab commented on GitHub (Dec 29, 2024): UseSession() is a Nanostore, not a React hook. So Vue.js use also useSession() provided by Better-auth. Yes like you say, a different package for React would be relevant. That also open the door for Vue.js, Solid.js, Angular, htmx, Alpine, Astro, etc. So a list of external adapters is more clean, instead of bloat the main package with several useless dependencies.

GiteaMirror commented

2026-04-17 16:08:51 -05:00

@daveycodez commented on GitHub (Dec 29, 2024):

In this case isn't localStorage agnostic, and can be used within useSession as an option to benefit every framework. Just a simple option in createAuthClient options enableLocalStorageCache Boolean. This doesn't add any dependencies and should only be a few lines of code inside of useSession and/or getSession and will make all sites in every framework using better-auth snappier on initial render

@daveycodez commented on GitHub (Dec 29, 2024): In this case isn't localStorage agnostic, and can be used within useSession as an option to benefit every framework. Just a simple option in createAuthClient options enableLocalStorageCache Boolean. This doesn't add any dependencies and should only be a few lines of code inside of useSession and/or getSession and will make all sites in every framework using better-auth snappier on initial render

GiteaMirror commented

2026-04-17 16:08:51 -05:00

@reslear commented on GitHub (Dec 30, 2024):

yeah that would be cool for Offline First (pwa/capacitor) applications
also i found wrap solution af7e404900/packages/better-auth
but only for React but I think it could easily be adapted for vue.

@reslear commented on GitHub (Dec 30, 2024): yeah that would be cool for Offline First (pwa/capacitor) applications also i found wrap solution https://github.com/onejs/one/tree/af7e4049000f60e41a7b231d56f16d0393f72abc/packages/better-auth but only for React but I think it could easily be adapted for vue.

GiteaMirror commented

2026-04-17 16:08:52 -05:00

@daveycodez commented on GitHub (Feb 14, 2025):

@reslear

https://github.com/daveyplate/better-auth-tanstack

I use my Tanstack library with a persistClient for offline auth now, in Capacitor

@daveycodez commented on GitHub (Feb 14, 2025): @reslear https://github.com/daveyplate/better-auth-tanstack I use my Tanstack library with a persistClient for offline auth now, in Capacitor

GiteaMirror commented

2026-04-17 16:08:53 -05:00

@reslear commented on GitHub (Feb 14, 2025):

@daveycodez react 🤢

@reslear commented on GitHub (Feb 14, 2025): @daveycodez react 🤢

GiteaMirror commented

2026-04-17 16:08:53 -05:00

@joseph-9900 commented on GitHub (Mar 3, 2025):

@daveycodez Have you found any solution? Seeing the same result, on refresh the database is getting hit everytime! I have turned on cookieCache still

session: {
        expiresIn: 60 * 60 * 24 * 7, // 7 days
        updateAge: 60 * 60 * 24, // 1 day (every 1 day the session expiration is updated)
        cookieCache: {
            enabled: true,
            maxAge: 5 * 60 // Cache duration in seconds
        }
    },

@joseph-9900 commented on GitHub (Mar 3, 2025): @daveycodez Have you found any solution? Seeing the same result, on refresh the database is getting hit everytime! I have turned on cookieCache still ``` session: { expiresIn: 60 * 60 * 24 * 7, // 7 days updateAge: 60 * 60 * 24, // 1 day (every 1 day the session expiration is updated) cookieCache: { enabled: true, maxAge: 5 * 60 // Cache duration in seconds } }, ```

GiteaMirror commented

2026-04-17 16:08:54 -05:00

@Nikola-Milovic commented on GitHub (Apr 20, 2025):

Any news? I want to have offline capabilities and it would be beneficial to have session persist even if network is not available. Can this be solved via the plugin system?

@Nikola-Milovic commented on GitHub (Apr 20, 2025): Any news? I want to have offline capabilities and it would be beneficial to have session persist even if network is not available. Can this be solved via the plugin system?

GiteaMirror commented

2026-04-17 16:08:55 -05:00

@daveycodez commented on GitHub (Apr 20, 2025):

Any news? I want to have offline capabilities and it would be beneficial to have session persist even if network is not available. Can this be solved via the plugin system?

https://github.com/daveyplate/better-auth-tanstack

Use this with a TS Query Persist Client https://tanstack.com/query/latest/docs/framework/react/plugins/persistQueryClient

@daveycodez commented on GitHub (Apr 20, 2025): > Any news? I want to have offline capabilities and it would be beneficial to have session persist even if network is not available. Can this be solved via the plugin system? https://github.com/daveyplate/better-auth-tanstack Use this with a TS Query Persist Client https://tanstack.com/query/latest/docs/framework/react/plugins/persistQueryClient

Sign in to join this conversation.

Branches Tags

2026-05-13/ci/stabilize-docker-startup

dependabot/npm_and_yarn/samlify-2.13.0

changeset-release/main

main

2026-05-22/chore/adopt-agents-md

2026-05-22/refactor/string-case-utils

2026-05-14/fix/passkey-verify-error-and-claim

changeset-release/next

dependabot/npm_and_yarn/demo/electron/demo-minor-patch-519ef7475f

dependabot/github_actions/github-actions-98f3470200

client-assertions-main

2026-05-15/ci/fix-sqlite-abi-mismatch

2026-05-15/fix/organization-team-add-cascade

2026-05-15/fix/parse-set-cookie-value-validation

2026-05-13/feat/captcha-wildcard-endpoints

fix/i18n-before-hook-translation

fix/disable-migration-generate

2026-05-07/fix/admin-set-password-upsert

2026-05-10/fix/cookie-drain-order

2026-05-10/feat/hooks-finally

2026-05-09/fix/cookie-drain-order

2026-05-09/feat/hooks-finally

2026-05-08/feat/register-before-send

fix/stripe/subscription-data-merge

2026-05-01/chore/pnpm-v11-harden

chore/pnpm-v11

2026-04-29/feat/google-include-granted-scopes

2026-04-29/fix/oauth-account-scope-semantics

2026-04-27/fix/nextcookies-idempotent-writes

2026-04-26/fix/harden-proxy-host-validation

2026-04-26/refactor/stripe-callback-signature-cleanup

2026-04-26/fix/stripe-subscription-callback-timing

2026-04-11/fix/sveltekit-app-modules

feat/open-api-zod-contract

feat/oauth-provider-backchannel-logout-next

feat/oauth-idp-initiated-bounce

refactor/sign-in-challenges

2026-04-21/fix/oauth-rfc-input-validation

fix/release-notes-new-packages

fix/two-factor-identity-guard

fix/resource

feat/emailpassword-authorize

2026-04-12/security/dynamic-baseurl-proxy-trust-default

feat/oauth-provider-at-hash-v2

fix/release-grep-fallback

claude/address-review-comments-JhFLr

claude/slack-update-stripe-docs-consistency-8Sc0w

feat/async-auth

fix/two-factor-totp-verified-enrollment

feat/plugin-ui

codex/blog-1-6-release-post

2026-04-06/fix/type-any-guards

2026-04-05/chore/downgrade-better-call

2026-04-04/ci/skip-vercel-fork-prs

2026-03-28/ci/add-autofix-ci

chore/release-preview-script

himself65/2026/02/19/role

2026-03-24/fix/update-user-info-on-link

2026-03-20/docs/improve-website

2026-03-20/fix/anonymous-onlinkaccount-expo

2026-02-17/fix/anonymous-link-state

fix/8607-saml-inresponseto

fix/8549-scim-patch-noop

v1.4.x

refactor/migration-snapshot-tests

worktree-magic-link-additional-data

chore/migrate-build-to-rollup

worktree-fix-dynamic-baseurl-8447

2026-03-06/chore/public-api-check

fix/close-8156-regression-test

fix/secondary-storage-json-error-handling

himself65/verification-namespace

cursor/issue-8307-validation-79a3

himself65/2026/01/30/error-mdx

v1.4.x-staging

fix/email-otp-user

fix/restrict-full-organization-access-roles

himself65/2026/02/12/count

himself65/2026/02/04/define-plugin

2026-02-04/feat/add-pluralize

cursor/better-auth-js-integration-ec21

cursor/expo-state-mismatch-394c

2026-02-01/fix/org-update-role-sync-members

cursor/issue-7607-investigation-e146

cursor/email-generation-helper-0ff6

himself65/2026/01/21/avoid-spread-operator

himself65/2026/01/14/cli

claude/slack-add-docs-pr-NMvgO

claude/slack-add-advanced-useplural-WHKYL

feat/hooks-pos

feat/2fa-phone

feat/2fa

fix/rotation

fix/username-check

v1.3.x

refactor/organization

feat/multiple-client-ids-social-providers

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/better-auth#25858