[GH-ISSUE #1006] useSession() not always triggering a state change #17175

New Issue

GiteaMirror · 2026-04-15T15:10:23-05:00

GiteaMirror commented

2026-04-15 15:10:23 -05:00

Originally created by @k3dom on GitHub (Dec 23, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/1006

Is this suited for github?

Yes, this is suited for github

To Reproduce

Sign in with email and password
Use useSession() in the following component:

export function AuthLayout({ children }: AppLayoutProps) {
  const sidebar = useConfigStore((state) => state.sidebar)
  const { data: session } = useSession()

  return (
    <SidebarProvider defaultOpen={sidebar}>
      <Sidebar collapsible="icon" variant="inset">
        <SidebarHeader>Test</SidebarHeader>
        <SidebarContent>
          <NavMain />
        </SidebarContent>
        <SidebarFooter>
          <NavUser
            name={session?.user.name ?? ''}
            email={session?.user.email ?? ''}
          />
        </SidebarFooter>
        <SidebarRail />
      </Sidebar>
      <SidebarInset>
        <NavHeader />
        <div className="m-4 mt-0 h-full">{children}</div>
      </SidebarInset>
    </SidebarProvider>
  )
}

Current vs. Expected behavior

Current:
The session state always starts with null (as it should). It then does a network request to get-session which succeeds. The problem now is that the state does not update maybe 50% to the time resulting in me not being able to show the user's name in this example. If I then trigger a component rerender by e.g. opening the navbar, the session information is properly reflected in the UI
Expected:
I expect the state to always update after a successfull get-session call

What version of Better Auth are you using?

1.1.1

Provide environment information

OS: Linux 6.12.4-arch1-1
Browser: Chrome 130.0.6723.116

Which area(s) are affected? (Select all that apply)

Client

Auth config (if applicable)

betterAuth({
      trustedOrigins: c.env.BETTER_AUTH_TRUSTED_ORIGINS.split(','),
      database: drizzleAdapter(c.get('db'), {
        provider: 'pg',
        usePlural: true,
      }),
      emailAndPassword: {
        enabled: true,
      },
      advanced: {
        cookiePrefix: 'viaptic',
      },
    })

Additional context

I tested this in both production and development and on both Chrome and Firefox. The issue persists everywhere

Originally created by @k3dom on GitHub (Dec 23, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/1006 ### Is this suited for github? - [X] Yes, this is suited for github ### To Reproduce 1. Sign in with email and password 2. Use `useSession()` in the following component: ```ts export function AuthLayout({ children }: AppLayoutProps) { const sidebar = useConfigStore((state) => state.sidebar) const { data: session } = useSession() return ( <SidebarProvider defaultOpen={sidebar}> <Sidebar collapsible="icon" variant="inset"> <SidebarHeader>Test</SidebarHeader> <SidebarContent> <NavMain /> </SidebarContent> <SidebarFooter> <NavUser name={session?.user.name ?? ''} email={session?.user.email ?? ''} /> </SidebarFooter> <SidebarRail /> </Sidebar> <SidebarInset> <NavHeader /> <div className="m-4 mt-0 h-full">{children}</div> </SidebarInset> </SidebarProvider> ) } ``` ### Current vs. Expected behavior - **Current**: The session state always starts with `null` (as it should). It then does a network request to `get-session` which succeeds. The problem now is that the state does not update maybe 50% to the time resulting in me not being able to show the user's name in this example. If I then trigger a component rerender by e.g. opening the navbar, the session information is properly reflected in the UI - **Expected**: I expect the state to always update after a successfull `get-session` call ### What version of Better Auth are you using? 1.1.1 ### Provide environment information ```bash OS: Linux 6.12.4-arch1-1 Browser: Chrome 130.0.6723.116 ``` ### Which area(s) are affected? (Select all that apply) Client ### Auth config (if applicable) ```typescript betterAuth({ trustedOrigins: c.env.BETTER_AUTH_TRUSTED_ORIGINS.split(','), database: drizzleAdapter(c.get('db'), { provider: 'pg', usePlural: true, }), emailAndPassword: { enabled: true, }, advanced: { cookiePrefix: 'viaptic', }, }) ``` ### Additional context I tested this in both production and development and on both Chrome and Firefox. The issue persists everywhere

GiteaMirror added the locked bug labels 2026-04-15 15:10:24 -05:00

GiteaMirror closed this issue

2026-04-15 15:10:24 -05:00

GiteaMirror commented

2026-04-15 15:10:25 -05:00

@cem2ran commented on GitHub (Dec 25, 2024):

I'm also seeing this. version 1.1.3. Not seeing useSession updating after logging in with apple in expo app.

@cem2ran commented on GitHub (Dec 25, 2024): I'm also seeing this. version 1.1.3. Not seeing useSession updating after logging in with apple in expo app.

GiteaMirror commented

2026-04-15 15:10:25 -05:00

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

Because you should use useEffect to trigger a React rerender when the session object change

@Nicolab commented on GitHub (Dec 30, 2024): Because you should use useEffect to trigger a React rerender when the session object change

GiteaMirror commented

2026-04-15 15:10:26 -05:00

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

Because you should use useEffect to trigger a React rerender when the session object change

Thats not how reactive state works. The session object itself is supposed to be reactive and trigger a rerender on change. If you put the session in useEffect like so:

useEffect(() =>console.log(session), [session])

You will simply get the exact same behaviour which is it getting printed only 50% of the time.

@k3dom commented on GitHub (Dec 30, 2024): > Because you should use useEffect to trigger a React rerender when the session object change Thats not how reactive state works. The session object itself is supposed to be reactive and trigger a rerender on change. If you put the session in `useEffect` like so: ```ts useEffect(() =>console.log(session), [session]) ``` You will simply get the exact same behaviour which is it getting printed only 50% of the time.

GiteaMirror commented

2026-04-15 15:10:26 -05:00

@crackedeng commented on GitHub (Dec 31, 2024):

+1 also happening with expo

@crackedeng commented on GitHub (Dec 31, 2024): +1 also happening with expo

GiteaMirror commented

2026-04-15 15:10:27 -05:00

@statusunknown418 commented on GitHub (Jan 2, 2025):

+1 to this, also the expo adapter is not redirecting the users after signin wih social

@statusunknown418 commented on GitHub (Jan 2, 2025): +1 to this, also the expo adapter is not redirecting the users after signin wih social

GiteaMirror commented

2026-04-15 15:10:27 -05:00

@mbrimmer83 commented on GitHub (Jan 20, 2025):

+1 on Expo 52. I'm running into this as well on expo. I tried debugging, but wasn't able to find anything wrong with how nanostores or the react Store were handling reactivity.

@mbrimmer83 commented on GitHub (Jan 20, 2025): +1 on Expo 52. I'm running into this as well on expo. I tried debugging, but wasn't able to find anything wrong with how `nanostores` or the react `Store` were handling reactivity.

GiteaMirror commented

2026-04-15 15:10:28 -05:00

@eliabexp commented on GitHub (Jan 22, 2025):

+1 here, using tradicional email & password method

@eliabexp commented on GitHub (Jan 22, 2025): +1 here, using tradicional email & password method

GiteaMirror commented

2026-04-15 15:10:28 -05:00

@arxk commented on GitHub (Jan 30, 2025):

+1. This issue is still present.. This should be fixed.

@arxk commented on GitHub (Jan 30, 2025): +1. This issue is still present.. This should be fixed.

GiteaMirror commented

2026-04-15 15:10:29 -05:00

@AkshatKejriwal commented on GitHub (Feb 4, 2025):

+1, can confirm that it is still present.

@AkshatKejriwal commented on GitHub (Feb 4, 2025): +1, can confirm that it is still present.

GiteaMirror commented

2026-04-15 15:10:29 -05:00

@samcxps commented on GitHub (Feb 5, 2025):

+1 on 1.1.16

This issue is a dealbreaker for client-side only applications (i.e. Expo, Vite) where server-side auth checks aren't possible.

@samcxps commented on GitHub (Feb 5, 2025): +1 on 1.1.16 This issue is a dealbreaker for client-side only applications (i.e. Expo, Vite) where server-side auth checks aren't possible.

GiteaMirror commented

2026-04-15 15:10:30 -05:00

@vhondarev commented on GitHub (Feb 8, 2025):

+1 on 1.1.15

This might be overkill but as a workaround try get-session

@vhondarev commented on GitHub (Feb 8, 2025): +1 on 1.1.15 This might be overkill but as a workaround try [get-session](https://github.com/better-auth/better-auth/blob/aaa5c60a037bc7486d45e16264d2672b6e82f064/docs/content/docs/basic-usage.mdx#get-session)

GiteaMirror commented

2026-04-15 15:10:30 -05:00

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

+1 on 1.1.15 also

@ruaanetwork commented on GitHub (Feb 14, 2025): +1 on 1.1.15 also

GiteaMirror commented

2026-04-15 15:10:31 -05:00

@fullyDeepak commented on GitHub (Feb 15, 2025):

Here is the workaround, it is not ideal but it works :)
Paste this in the same component where you are using useSession and it will force a re-render.

const [num, setNum] = useState(1);
  useEffect(() => {
    if (num < 2) {
      setNum(num + 1);
    }
  }, [num]);

@fullyDeepak commented on GitHub (Feb 15, 2025): Here is the workaround, it is not ideal but it works :) Paste this in the same component where you are using useSession and it will force a re-render. ``` const [num, setNum] = useState(1); useEffect(() => { if (num < 2) { setNum(num + 1); } }, [num]); ```

GiteaMirror commented

2026-04-15 15:10:32 -05:00

@amosbastian commented on GitHub (Feb 17, 2025):

This issue is a dealbreaker for client-side only applications (i.e. Expo, Vite) where server-side auth checks aren't possible.

It's not fixed in the beta either and I refuse to use something like Next.js for an app behind auth 😆

@amosbastian commented on GitHub (Feb 17, 2025): > This issue is a dealbreaker for client-side only applications (i.e. Expo, Vite) where server-side auth checks aren't possible. It's not fixed in the beta either and I refuse to use something like Next.js for an app behind auth 😆

GiteaMirror commented

2026-04-15 15:10:33 -05:00

@arthureberledev commented on GitHub (Feb 20, 2025):

I am using react (vite) with react query and this was my solution:

async function getSession() {
  return await authClient.getSession();
}

export function MyComponent() {
  const { data: session } = useQuery({
    queryKey: ["session"],
    queryFn: getSession,
  });

  [...]
}

@arthureberledev commented on GitHub (Feb 20, 2025): I am using react (vite) with react query and this was my solution: ``` async function getSession() { return await authClient.getSession(); } export function MyComponent() { const { data: session } = useQuery({ queryKey: ["session"], queryFn: getSession, }); [...] } ```

GiteaMirror commented

2026-04-15 15:10:33 -05:00

@JosipPardon commented on GitHub (Feb 21, 2025):

I have solution.

When component with useSession is mounted, it always fetches session with api/auth/get-session request, but sometimes it randomly does not update client store of useSession. Because of that, components that depend on that hook are not re-rendered.

Solution is to replace authClient.useSession() with custom hook useAuthSession():

import { authClient } from "@/lib/auth-client";
import { useEffect, useRef } from "react";

function useAuthSession() {
  const {
    data,
    isPending,
    error, //error object
    refetch,
  } = authClient.useSession();

  // Track the latest value of isPending
  const isPendingRef = useRef(isPending);

  useEffect(() => {
    isPendingRef.current = isPending;
  }, [isPending]);

  useEffect(() => {
    if (isPending) {
      const timerNotify = setTimeout(() => {
        if (isPendingRef.current) {
          refetch(); // sends another get-session request to the server
          //authClient.$store.notify("$sessionSignal"); // or this poke store to trigger a re-render
        }
      }, 2500); // after 2.5 seconds of pending, force resetting client store
      const timerReload = setTimeout(() => {
        if (isPendingRef.current) {
          window.location.reload();
        }
      }, 5000); // after 5 seconds of pending, reload the page
      return () => {
        clearTimeout(timerNotify);
        clearTimeout(timerReload);
      };
    }
  }, [isPending]);

  return {
    data,
    isPending,
    error,
  };
}

export default useAuthSession;

@JosipPardon commented on GitHub (Feb 21, 2025): I have solution. When component with `useSession` is mounted, it always fetches session with `api/auth/get-session` request, but sometimes it randomly does not update client store of `useSession.` Because of that, components that depend on that hook are not re-rendered. Solution is to replace `authClient.useSession()` with custom hook `useAuthSession()`: ```tsx import { authClient } from "@/lib/auth-client"; import { useEffect, useRef } from "react"; function useAuthSession() { const { data, isPending, error, //error object refetch, } = authClient.useSession(); // Track the latest value of isPending const isPendingRef = useRef(isPending); useEffect(() => { isPendingRef.current = isPending; }, [isPending]); useEffect(() => { if (isPending) { const timerNotify = setTimeout(() => { if (isPendingRef.current) { refetch(); // sends another get-session request to the server //authClient.$store.notify("$sessionSignal"); // or this poke store to trigger a re-render } }, 2500); // after 2.5 seconds of pending, force resetting client store const timerReload = setTimeout(() => { if (isPendingRef.current) { window.location.reload(); } }, 5000); // after 5 seconds of pending, reload the page return () => { clearTimeout(timerNotify); clearTimeout(timerReload); }; } }, [isPending]); return { data, isPending, error, }; } export default useAuthSession; ```

GiteaMirror commented

2026-04-15 15:10:34 -05:00

@joseph-9900 commented on GitHub (Feb 26, 2025):

Facing the same issue! @kedom1337 have you found a solution?

@joseph-9900 commented on GitHub (Feb 26, 2025): Facing the same issue! @kedom1337 have you found a solution?

GiteaMirror commented

2026-04-15 15:10:35 -05:00

@Bekacru commented on GitHub (Feb 27, 2025):

Hey everyone, sorry for the late reply. I still can’t reproduce the issue. Could someone provide a reproduction or at least share a screen recording of the code and the behavior?

Here’s what I just tried, everything is happening on the client. after the user signed in isPending get triggered and shows the loading icon, and when pending is false and the session is fetched it displays the session.

what i'm essentially doing:

function SessionComp() {
    const { data, isPending, error } = client.useSession();
    return (
        <div>
            {isPending ? (
                <div>
                    <Loader2 />
                </div>
            ) : error ? (
                <div>
                    Error: {error.message}
                </div>
            ) : session ? (
                <div>
                 {/* display the session */}
               </div>
            ) : (
                <div> </div>
            )}
        </div>
    );
}

https://github.com/user-attachments/assets/349eb5c3-c8f9-42e8-8d1b-57adb8cefa5f

@Bekacru commented on GitHub (Feb 27, 2025): Hey everyone, sorry for the late reply. I still can’t reproduce the issue. Could someone provide a reproduction or at least share a screen recording of the code and the behavior? Here’s what I just tried, everything is happening on the client. after the user signed in `isPending` get triggered and shows the loading icon, and when pending is false and the session is fetched it displays the session. what i'm essentially doing: ```tsx function SessionComp() { const { data, isPending, error } = client.useSession(); return ( <div> {isPending ? ( <div> <Loader2 /> </div> ) : error ? ( <div> Error: {error.message} </div> ) : session ? ( <div> {/* display the session */} </div> ) : ( <div> </div> )} </div> ); } ``` https://github.com/user-attachments/assets/349eb5c3-c8f9-42e8-8d1b-57adb8cefa5f

GiteaMirror commented

2026-04-15 15:10:35 -05:00

@AkshatKejriwal commented on GitHub (Feb 27, 2025):

Hey everyone, sorry for the late reply. I still can’t reproduce the issue. Could someone provide a reproduction or at least share a screen recording of the code and the behavior?

Here’s what I just tried, everything is happening on the client. after the user signed in isPending get triggered and shows the loading icon, and when pending is false and the session is fetched it displays the session.

what i'm essentially doing:

function SessionComp() {
const { data, isPending, error } = client.useSession();
return (

{isPending ? (

) : error ? (

Error: {error.message}

) : session ? (

{/* display the session */}

) : (

)}

);
}

Screen.Recording.2025-02-27.at.9.47.00.AM.mov

So, this is in a navbar and the ProfileDropdown has a logout button. Clicking the logout button doesn't update the state in nav and it keeps showing the ProfileDropdown.

Nav:

  const { data: session, isPending } = useSession();
  const user = session?.user as User;
  {
    !session?.user ? (
      <div className="hidden items-center gap-2 lg:flex">
        <LoginButton disabled={isPending} variant="outline">
          {tCommon("buttons.login")}
        </LoginButton>
        <RegisterButton disabled={isPending}>
          {tCommon("buttons.register")}
        </RegisterButton>
      </div>
    ) : (
      <div className="hidden items-center gap-2 lg:flex">
        <Link href="/event/create">
          <Button>{tCommon("buttons.createEvent")}</Button>
        </Link>
        <ProfileDropdown user={user} />
      </div>
    );
  }

Here's the logout button:

    try {
      setPending(true);
      await authClient.signOut({
        fetchOptions: {
          onSuccess: () => {
            toast({
              title: "Logged out",
              description: "You have been logged out",
            });
            // window.location.reload(); // TODO: temporary fix for the session not updating in the navbar
          },
        },
      });
    } catch (error) {
      console.error("Error signing out:", error);
    } finally {
      setPending(false);
    }
  };

@AkshatKejriwal commented on GitHub (Feb 27, 2025): > Hey everyone, sorry for the late reply. I still can’t reproduce the issue. Could someone provide a reproduction or at least share a screen recording of the code and the behavior? > > Here’s what I just tried, everything is happening on the client. after the user signed in `isPending` get triggered and shows the loading icon, and when pending is false and the session is fetched it displays the session. > > what i'm essentially doing: > > function SessionComp() { > const { data, isPending, error } = client.useSession(); > return ( > <div> > {isPending ? ( > <div> > <Loader2 /> > </div> > ) : error ? ( > <div> > Error: {error.message} > </div> > ) : session ? ( > <div> > {/* display the session */} > </div> > ) : ( > <div> </div> > )} > </div> > ); > } > > Screen.Recording.2025-02-27.at.9.47.00.AM.mov So, this is in a navbar and the ProfileDropdown has a logout button. Clicking the logout button doesn't update the state in nav and it keeps showing the ProfileDropdown. Nav: ```jsx const { data: session, isPending } = useSession(); const user = session?.user as User; { !session?.user ? ( <div className="hidden items-center gap-2 lg:flex"> <LoginButton disabled={isPending} variant="outline"> {tCommon("buttons.login")} </LoginButton> <RegisterButton disabled={isPending}> {tCommon("buttons.register")} </RegisterButton> </div> ) : ( <div className="hidden items-center gap-2 lg:flex"> <Link href="/event/create"> <Button>{tCommon("buttons.createEvent")}</Button> </Link> <ProfileDropdown user={user} /> </div> ); } ``` Here's the logout button: ```jsx const handleLogout = async () => { try { setPending(true); await authClient.signOut({ fetchOptions: { onSuccess: () => { toast({ title: "Logged out", description: "You have been logged out", }); // window.location.reload(); // TODO: temporary fix for the session not updating in the navbar }, }, }); } catch (error) { console.error("Error signing out:", error); } finally { setPending(false); } }; ```

GiteaMirror commented

2026-04-15 15:10:37 -05:00

@amitsharma1511 commented on GitHub (Mar 3, 2025):

What I am able to deduce is, the issue is specific to react 19.

To reproduce below versions are required -

"next": "^15.2.0",
"react": "^19.0.0",
"react-dom": "^19.0.0",

Attaching video recording for reference -

https://github.com/user-attachments/assets/b99ae098-9683-4957-af12-e1166091fee0

@amitsharma1511 commented on GitHub (Mar 3, 2025): What I am able to deduce is, the issue is specific to react 19. To reproduce below versions are required - "next": "^15.2.0", "react": "^19.0.0", "react-dom": "^19.0.0", Attaching video recording for reference - https://github.com/user-attachments/assets/b99ae098-9683-4957-af12-e1166091fee0

GiteaMirror commented

2026-04-15 15:10:37 -05:00

@developedbyed commented on GitHub (Mar 4, 2025):

Encountered the same thing, must be related to React 19

@developedbyed commented on GitHub (Mar 4, 2025): Encountered the same thing, must be related to React 19

GiteaMirror commented

2026-04-15 15:10:37 -05:00

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

Hey @Bekacru Please check the issue 🙏

@joseph-9900 commented on GitHub (Mar 4, 2025): Hey @Bekacru Please check the issue 🙏

GiteaMirror commented

2026-04-15 15:10:38 -05:00

@Bekacru commented on GitHub (Mar 4, 2025):

Hey everyone, I still can't seem to reproduce it on my end. Any reproduction code would be great.
You can check the demo here, it's on React 19:
https://github.com/better-auth/better-auth/blob/main/demo/nextjs/package.json#L75

I’ve also added a client-only sign-in/use-session demo here:
https://demo.better-auth.com/client-test

@Bekacru commented on GitHub (Mar 4, 2025): Hey everyone, I still can't seem to reproduce it on my end. Any reproduction code would be great. You can check the demo here, it's on React 19: https://github.com/better-auth/better-auth/blob/main/demo/nextjs/package.json#L75 I’ve also added a client-only sign-in/use-session demo here: https://demo.better-auth.com/client-test

GiteaMirror commented

2026-04-15 15:10:40 -05:00

@lucasaraujonrt commented on GitHub (Mar 5, 2025):

Hey everyone, I still can't seem to reproduce it on my end. Any reproduction code would be great. You can check the demo here, it's on React 19: https://github.com/better-auth/better-auth/blob/main/demo/nextjs/package.json#L75

I’ve also added a client-only sign-in/use-session demo here: https://demo.better-auth.com/client-test

Hey @Bekacru I also tried to reproduce here and I believe I found the problem, if the page is server-side and the data is passed by props to the child, and if the child component is the client hook, the data is not updated.

ex:

Server component

import Content from "@/app/profile/(components)/content";
import { auth } from "@/lib/auth";
import { headers } from "next/headers";
import { redirect } from "next/navigation";

export default async function Page() {
  const [session] = await Promise.all([
    auth.api.getSession({
      headers: await headers(),
    }),
  ]).catch(() => {
    throw redirect("/login");
  });

  return <Content session={session} />;
}

Client component:

const { refetch } = authClient.useSession();

await authClient.updateUser(
    {
      image: await convertImageToBase64(logo),
    },
    {
      onSuccess: () => refetch(), // this not reload the values
    }
  );

I'm not sure if it's the same problem

@lucasaraujonrt commented on GitHub (Mar 5, 2025): > Hey everyone, I still can't seem to reproduce it on my end. Any reproduction code would be great. You can check the demo here, it's on React 19: https://github.com/better-auth/better-auth/blob/main/demo/nextjs/package.json#L75 > > I’ve also added a client-only sign-in/use-session demo here: https://demo.better-auth.com/client-test Hey @Bekacru I also tried to reproduce here and I believe I found the problem, if the page is server-side and the data is passed by props to the child, and if the child component is the client hook, the data is not updated. ex: Server component ```tsx import Content from "@/app/profile/(components)/content"; import { auth } from "@/lib/auth"; import { headers } from "next/headers"; import { redirect } from "next/navigation"; export default async function Page() { const [session] = await Promise.all([ auth.api.getSession({ headers: await headers(), }), ]).catch(() => { throw redirect("/login"); }); return <Content session={session} />; } ``` Client component: ```tsx const { refetch } = authClient.useSession(); await authClient.updateUser( { image: await convertImageToBase64(logo), }, { onSuccess: () => refetch(), // this not reload the values } ); ``` I'm not sure if it's the same problem

GiteaMirror commented

2026-04-15 15:10:41 -05:00

@amitsharma1511 commented on GitHub (Mar 5, 2025):

Hi @lucasaraujonrt, you have got very close I think. The issue is when there is a mix and match of server and client component calls. I am signing in user using server component and server actions, but fetching the session on a client component.

export const signInAction = async (state: FormState, formData: FormData) => {
  const validatedFields = signInSchema.safeParse({
    email: formData.get("email"),
    password: formData.get("password"),
  });
  if (!validatedFields.success) {
    return { errors: validatedFields.error.flatten().fieldErrors };
  }
  const { email, password } = validatedFields.data;
  try {
    const result = await auth.api.signInEmail({
      body: {
        email,
        password,
      },
    });

    console.log("#### DATA ####:", result.user);
  } catch (error) {
    if (error instanceof APIError) {
      console.log("#### ERROR ####", error.message, error.status);
    }
  }

  redirect("/");
};

export const auth = betterAuth({
  baseURL: process.env.NEXT_PUBLIC_BETTER_AUTH_BASE_URL,
  database: drizzleAdapter(db, {
    provider: "sqlite", // or "mysql", "pg"
  }),
 // .......
  plugins: [nextCookies()], // make sure this is the last plugin in the array
});

"use client"
// .......
export function UserNav() {
  const { data: session, isPending, error, refetch } = authClient.useSession();
  console.log("USER NAV SESSION", session);

  return (
    <>
      {session?.session.id ? (
        <DropdownMenu> ) : (
        <Button asChild>
          <Link href="/signin">Sign In</Link>
        </Button>
      )}
    </>
  );
}

@amitsharma1511 commented on GitHub (Mar 5, 2025): Hi @lucasaraujonrt, you have got very close I think. The issue is when there is a mix and match of server and client component calls. I am signing in user using server component and server actions, but fetching the session on a client component. ``` export const signInAction = async (state: FormState, formData: FormData) => { const validatedFields = signInSchema.safeParse({ email: formData.get("email"), password: formData.get("password"), }); if (!validatedFields.success) { return { errors: validatedFields.error.flatten().fieldErrors }; } const { email, password } = validatedFields.data; try { const result = await auth.api.signInEmail({ body: { email, password, }, }); console.log("#### DATA ####:", result.user); } catch (error) { if (error instanceof APIError) { console.log("#### ERROR ####", error.message, error.status); } } redirect("/"); }; ``` ``` export const auth = betterAuth({ baseURL: process.env.NEXT_PUBLIC_BETTER_AUTH_BASE_URL, database: drizzleAdapter(db, { provider: "sqlite", // or "mysql", "pg" }), // ....... plugins: [nextCookies()], // make sure this is the last plugin in the array }); ``` ``` "use client" // ....... export function UserNav() { const { data: session, isPending, error, refetch } = authClient.useSession(); console.log("USER NAV SESSION", session); return ( <> {session?.session.id ? ( <DropdownMenu> ) : ( <Button asChild> <Link href="/signin">Sign In</Link> </Button> )} </> ); } ```

GiteaMirror commented

2026-04-15 15:10:42 -05:00

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

Hey @amitsharma1511 @lucasaraujonrt if you all can create a repo in codesandbox or in github and share it here it would be useful from @Bekacru perspective. He is unable to reproduce the issue. But as so many people including myself is facing the issue that means the issue is still there.

@joseph-9900 commented on GitHub (Mar 5, 2025): Hey @amitsharma1511 @lucasaraujonrt if you all can create a repo in codesandbox or in github and share it here it would be useful from @Bekacru perspective. He is unable to reproduce the issue. But as so many people including myself is facing the issue that means the issue is still there.

GiteaMirror commented

2026-04-15 15:10:42 -05:00

@raburuz commented on GitHub (Mar 5, 2025):

This issue happens with React 19.
I have the same exact code in my app with React 18 and everything works perfectly, but when I update to React 19 this hook doesn't work anymore.

My stack is React with vitejs and nodejs with express

https://www.reddit.com/r/better_auth/s/eCIAQK0luS

@raburuz commented on GitHub (Mar 5, 2025): This issue happens with React 19. I have the same exact code in my app with React 18 and everything works perfectly, but when I update to React 19 this hook doesn't work anymore. My stack is React with vitejs and nodejs with express https://www.reddit.com/r/better_auth/s/eCIAQK0luS

GiteaMirror commented

2026-04-15 15:10:43 -05:00

@natew commented on GitHub (Mar 6, 2025):

I'm hitting this when logging out just doing this:

So not React 19, it never calls this when you log out.

@natew commented on GitHub (Mar 6, 2025): I'm hitting this when logging out just doing this: ![Image](https://github.com/user-attachments/assets/f6556bd6-ec85-48da-ae62-4e76b7a1b30c) So not React 19, it never calls this when you log out.

GiteaMirror commented

2026-04-15 15:10:44 -05:00

@Rudrangg commented on GitHub (Mar 6, 2025):

Removing this seems to work?

session: { cookieCache: { enabled: true, maxAge: 60, }, },

@Rudrangg commented on GitHub (Mar 6, 2025): Removing this seems to work? ` session: { cookieCache: { enabled: true, maxAge: 60, }, },`

GiteaMirror commented

2026-04-15 15:10:45 -05:00

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

Another issue is after google OAuth login it still can't retrieve session and asks for login again. It's really frustrating when you think of this in a production environment. Will drop better-auth for now and check later if they fix this thing up. It's a very good library but with this issue can't deploy app on production!

@joseph-9900 commented on GitHub (Mar 6, 2025): Another issue is after google OAuth login it still can't retrieve session and asks for login again. It's really frustrating when you think of this in a production environment. Will drop better-auth for now and check later if they fix this thing up. It's a very good library but with this issue can't deploy app on production!

GiteaMirror commented

2026-04-15 15:10:46 -05:00

@ChatterjeeArka commented on GitHub (Mar 8, 2025):

Hey @Bekacru, facing the same issue. Is there any solution out now?

@ChatterjeeArka commented on GitHub (Mar 8, 2025): Hey @Bekacru, facing the same issue. Is there any solution out now?

GiteaMirror commented

2026-04-15 15:10:47 -05:00

@asimaranov commented on GitHub (Mar 11, 2025):

Facing same issue, get-session request succeeds but data is empty sometimes. Only force refetching made things work

@asimaranov commented on GitHub (Mar 11, 2025): Facing same issue, get-session request succeeds but data is empty sometimes. Only force refetching made things work

GiteaMirror commented

2026-04-15 15:10:49 -05:00

@lucasaraujonrt commented on GitHub (Mar 12, 2025):

Hi guys, i fixed my problem using the useRoute hook from next/navigation, replacing the refetch from authClient

In my case, the session is passed by props to children component, so refresh work's perfectly

Client component

const router = useRoute();

await authClient.updateUser(
  {
    image: await convertImageToBase64(logo),
  },
  {
    onSuccess: () => router.refresh(), // get the new session values
  }
);

Server component

import Content from "@/app/profile/(components)/content";
import { auth } from "@/lib/auth";
import { headers } from "next/headers";
import { redirect } from "next/navigation";

export default async function Page() {
  const [session] = await Promise.all([
    auth.api.getSession({
      headers: await headers(),
    }),
  ]).catch(() => {
    throw redirect("/login");
  });

  return <Content session={session} />;
}

@lucasaraujonrt commented on GitHub (Mar 12, 2025): Hi guys, i fixed my problem using the `useRoute` hook from `next/navigation`, replacing the refetch from `authClient` In my case, the session is passed by props to children component, so refresh work's perfectly Client component ```ts const router = useRoute(); await authClient.updateUser( { image: await convertImageToBase64(logo), }, { onSuccess: () => router.refresh(), // get the new session values } ); ``` Server component ```tsx import Content from "@/app/profile/(components)/content"; import { auth } from "@/lib/auth"; import { headers } from "next/headers"; import { redirect } from "next/navigation"; export default async function Page() { const [session] = await Promise.all([ auth.api.getSession({ headers: await headers(), }), ]).catch(() => { throw redirect("/login"); }); return <Content session={session} />; } ```

GiteaMirror commented

2026-04-15 15:10:52 -05:00

@Makakusnik commented on GitHub (Mar 12, 2025):

+1 Aswell on 1.2.2..

Refresh does work but refreshing whole page removes bunch of state, which should not be removed just by signing in..

@Makakusnik commented on GitHub (Mar 12, 2025): +1 Aswell on 1.2.2.. Refresh does work but refreshing whole page removes bunch of state, which should not be removed just by signing in..

GiteaMirror commented

2026-04-15 15:10:54 -05:00

@lukasb commented on GitHub (Mar 13, 2025):

+1 on 1.2.3

@lukasb commented on GitHub (Mar 13, 2025): +1 on 1.2.3

GiteaMirror commented

2026-04-15 15:10:56 -05:00

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

The session management issue in pending state is a head scratcher. I moved to clerk for my production project. Hey @Bekacru so many people are facing the same issue, I guess you should seriously see this rather focusing on new features like stripe and all! If the basic feature is only buggy then what is the use of using this.

@joseph-9900 commented on GitHub (Mar 13, 2025): The session management issue in pending state is a head scratcher. I moved to clerk for my production project. Hey @Bekacru so many people are facing the same issue, I guess you should seriously see this rather focusing on new features like stripe and all! If the basic feature is only buggy then what is the use of using this.

GiteaMirror commented

2026-04-15 15:10:57 -05:00

@jtj60 commented on GitHub (Mar 16, 2025):

Is there any plan to fix this? I've loved the library so far but this is gonna force me to switch to something else if not addressed soon...

@jtj60 commented on GitHub (Mar 16, 2025): Is there any plan to fix this? I've loved the library so far but this is gonna force me to switch to something else if not addressed soon...

GiteaMirror commented

2026-04-15 15:10:59 -05:00

@asimaranov commented on GitHub (Mar 17, 2025):

@Bekacru, could you check please?

@asimaranov commented on GitHub (Mar 17, 2025): @Bekacru, could you check please?

GiteaMirror commented

2026-04-15 15:11:00 -05:00

@Bekacru commented on GitHub (Mar 17, 2025):

Hey everyone, could you please confirm me if this is fixed on 1.2.5-beta.4?

@Bekacru commented on GitHub (Mar 17, 2025): Hey everyone, could you please confirm me if this is fixed on `1.2.5-beta.4`?

GiteaMirror commented

2026-04-15 15:11:01 -05:00

@Rudrangg commented on GitHub (Mar 18, 2025):

Hey everyone, could you please confirm me if this is fixed on 1.2.5-beta.4?

It is working fine for me! Thank you!!

@Rudrangg commented on GitHub (Mar 18, 2025): > Hey everyone, could you please confirm me if this is fixed on `1.2.5-beta.4`? It is working fine for me! _Thank you!!_

GiteaMirror commented

2026-04-15 15:11:01 -05:00

@Bekacru commented on GitHub (Mar 21, 2025):

Hey everyone, just figured out the root issue here after someone sent me a poc. It's due to object reference and destructuring. If you try to use a destructured object from the auth client, you need to use the destructured useSession instead of authClient.useSession and vice versa.

const authClient = createAuthClient();
const { signIn, useSession } = authClient;

// Method 1: Using destructured methods - This works
signIn(...);
useSession();
// When you use both destructured methods together, the session updates properly


// Method 2: Using direct object methods - This works too
authClient.signIn(...);
authClient.useSession();
// When you use both direct object methods together, the session updates properly


// Method 3: Mixing styles - This breaks! :x:
authClient.signIn(...);
useSession();
// When you mix direct object access with destructured methods, it breaks because it disrupts the object reference needed to trigger atoms.

We'll try to investigate on how we potentially support them interchangeably. But we'll document this in the meantime

@Bekacru commented on GitHub (Mar 21, 2025): Hey everyone, just figured out the root issue here after someone sent me a poc. It's due to object reference and destructuring. If you try to use a destructured object from the auth client, you need to use the destructured useSession instead of authClient.useSession and vice versa. ```ts const authClient = createAuthClient(); const { signIn, useSession } = authClient; // Method 1: Using destructured methods - This works signIn(...); useSession(); // When you use both destructured methods together, the session updates properly // Method 2: Using direct object methods - This works too authClient.signIn(...); authClient.useSession(); // When you use both direct object methods together, the session updates properly // Method 3: Mixing styles - This breaks! :x: authClient.signIn(...); useSession(); // When you mix direct object access with destructured methods, it breaks because it disrupts the object reference needed to trigger atoms. ``` We'll try to investigate on how we potentially support them interchangeably. But we'll document this in the meantime

GiteaMirror commented

2026-04-15 15:11:02 -05:00

@ChatterjeeArka commented on GitHub (Mar 21, 2025):

Hey everyone, just figured out the root issue here after someone sent me a poc. It's due to object reference and destructuring. If you try to use a destructured object from the auth client, you need to use the destructured useSession instead of authClient.useSession and vice versa.

const authClient = createAuthClient();
const { signIn, useSession } = authClient;

// Method 1: Using destructured methods - This works
signIn(...);
useSession();
// When you use both destructured methods together, the session updates properly

// Method 2: Using direct object methods - This works too
authClient.signIn(...);
authClient.useSession();
// When you use both direct object methods together, the session updates properly

// Method 3: Mixing styles - This breaks! ❌
authClient.signIn(...);
useSession();
// When you mix direct object access with destructured methods, it breaks because it disrupts the object reference needed to trigger atoms.
We'll try to investigate on how we potentially support them interchangeably. But we'll document this in the meantime

Hey @Bekacru you are correct, I just checked my old code which was giving error on github before using custom session hook and I was using this code

For getting session

const {
        data: session,
        isPending, //loading state
    } = authClient.useSession();

    console.log("session: ", session);

And for login with google

<Button
   variant="outline"
    className="flex items-center gap-2"
    onClick={async () => {
    setSignInClicked(true);
    toast.promise(
       signIn.social({
            provider: "google",
             callbackURL: "/",
        }),
       {
          loading: "Redirecting...",
           success: "Redirected successfully!",
            error: "Login failed",
         },
      );
     }}
>
   <GoogleLogo /> Sign in with Google

</Button>

@ChatterjeeArka commented on GitHub (Mar 21, 2025): > Hey everyone, just figured out the root issue here after someone sent me a poc. It's due to object reference and destructuring. If you try to use a destructured object from the auth client, you need to use the destructured useSession instead of authClient.useSession and vice versa. > > const authClient = createAuthClient(); > const { signIn, useSession } = authClient; > > // Method 1: Using destructured methods - This works > signIn(...); > useSession(); > // When you use both destructured methods together, the session updates properly > > > // Method 2: Using direct object methods - This works too > authClient.signIn(...); > authClient.useSession(); > // When you use both direct object methods together, the session updates properly > > > // Method 3: Mixing styles - This breaks! :x: > authClient.signIn(...); > useSession(); > // When you mix direct object access with destructured methods, it breaks because it disrupts the object reference needed to trigger atoms. > We'll try to investigate on how we potentially support them interchangeably. But we'll document this in the meantime Hey @Bekacru you are correct, I just checked my old code which was giving error on github before using custom session hook and I was using this code For getting session ``` const { data: session, isPending, //loading state } = authClient.useSession(); console.log("session: ", session); ``` And for login with google ``` <Button variant="outline" className="flex items-center gap-2" onClick={async () => { setSignInClicked(true); toast.promise( signIn.social({ provider: "google", callbackURL: "/", }), { loading: "Redirecting...", success: "Redirected successfully!", error: "Login failed", }, ); }} > <GoogleLogo /> Sign in with Google </Button> ```

GiteaMirror commented

2026-04-15 15:11:03 -05:00

@kawpii commented on GitHub (Mar 21, 2025):

I do not know how you guys use useSession it just throws me a type error

Edit:

Just closing and opening VS Code error disappeared not I'm getting two more errors

It seems like Better Auth only support SSR.

@kawpii commented on GitHub (Mar 21, 2025): I do not know how you guys use `useSession` it just throws me a type error ![Image](https://github.com/user-attachments/assets/10ff5925-463a-4c6b-94e1-b4882024f251) Edit: Just closing and opening VS Code error disappeared not I'm getting two more errors ![Image](https://github.com/user-attachments/assets/02dc8dd5-9786-4979-afc6-6352e3c63923) It seems like Better Auth only support SSR.

GiteaMirror commented

2026-04-15 15:11:03 -05:00

@Rudrangg commented on GitHub (Mar 21, 2025):

Edit:

Just closing and opening VS Code error disappeared not I'm getting two more errors

It seems like Better Auth only support SSR.

You cannot use await in a client component...
Correct usage

@Rudrangg commented on GitHub (Mar 21, 2025): > Edit: > > Just closing and opening VS Code error disappeared not I'm getting two more errors > > ![Image](https://github.com/user-attachments/assets/02dc8dd5-9786-4979-afc6-6352e3c63923) > > It seems like Better Auth only support SSR. You cannot use await in a client component... [Correct usage](https://www.better-auth.com/docs/concepts/session-management#use-session)

GiteaMirror commented

2026-04-15 15:11:03 -05:00

@kawpii commented on GitHub (Mar 21, 2025):

Edit:
Just closing and opening VS Code error disappeared not I'm getting two more errors

It seems like Better Auth only support SSR.

You cannot use await in a client component... Correct usage

Thanks, I just forgot to remove it.

Edit:

Still could not figure out why the useSession hook gives a type error.

@kawpii commented on GitHub (Mar 21, 2025): > > Edit: > > Just closing and opening VS Code error disappeared not I'm getting two more errors > > ![Image](https://github.com/user-attachments/assets/02dc8dd5-9786-4979-afc6-6352e3c63923) > > It seems like Better Auth only support SSR. > > You cannot use await in a client component... [Correct usage](https://www.better-auth.com/docs/concepts/session-management#use-session) Thanks, I just forgot to remove it. Edit: Still could not figure out why the `useSession` hook gives a type error.

GiteaMirror commented

2026-04-15 15:11:04 -05:00

@xaliz-06 commented on GitHub (Mar 23, 2025):

Hey guys, I'm facing the same issue here. I tried to go to 1.2.5-beta.4 but that returns null too. Anyone got a fix?

"use client";

import React from "react";
import { Button } from "@/components/ui/button";
import { ModeToggle } from "@/components/mode-toggle";
import { useRouter } from "next/navigation";
import { authClient } from "@/lib/auth-client";

const Navbar = () => {
  const navigation = useRouter();
  const {
    data: session,
    isPending, //loading state
    error, //error object
    refetch, //refetch the session
  } = authClient.useSession();

  console.log("Error: ", error);
  console.log("Session: ", session);

  const handleCreateAccount = () => {
    navigation.push("/auth/sign-up");
  };
// ...

I have not destructed the client object also. I wonder why client-side session fetching doesn't work. I can see that a call to api/auth/get-session is made that returns with a status code 200 (but no response or nothing in the request body for that matter)

@xaliz-06 commented on GitHub (Mar 23, 2025): Hey guys, I'm facing the same issue here. I tried to go to `1.2.5-beta.4` but that returns null too. Anyone got a fix? ```js "use client"; import React from "react"; import { Button } from "@/components/ui/button"; import { ModeToggle } from "@/components/mode-toggle"; import { useRouter } from "next/navigation"; import { authClient } from "@/lib/auth-client"; const Navbar = () => { const navigation = useRouter(); const { data: session, isPending, //loading state error, //error object refetch, //refetch the session } = authClient.useSession(); console.log("Error: ", error); console.log("Session: ", session); const handleCreateAccount = () => { navigation.push("/auth/sign-up"); }; // ... ``` I have not destructed the client object also. I wonder why client-side session fetching doesn't work. I can see that a call to `api/auth/get-session` is made that returns with a status code 200 (but no response or nothing in the request body for that matter)

GiteaMirror commented

2026-04-15 15:11:04 -05:00

@Bekacru commented on GitHub (Mar 23, 2025):

Still could not figure out why the useSession hook gives a type error.

@kaushalyap make sure you're importing createAuthClient from "/react" not "/client"

@Bekacru commented on GitHub (Mar 23, 2025): > Still could not figure out why the `useSession` hook gives a type error. @kaushalyap make sure you're importing `createAuthClient` from "/react" not "/client"

GiteaMirror commented

2026-04-15 15:11:05 -05:00

@Bekacru commented on GitHub (Mar 23, 2025):

Hey guys, I'm facing the same issue here. I tried to go to 1.2.5-beta.4 but that returns null too. Anyone got a fix?

@xaliz-06 this isn't related to to this issue. getSession could return null for differnt reasons. But for a start make sure there is a cookie in your browser

@Bekacru commented on GitHub (Mar 23, 2025): > Hey guys, I'm facing the same issue here. I tried to go to `1.2.5-beta.4` but that returns null too. Anyone got a fix? @xaliz-06 this isn't related to to this issue. `getSession` could return null for differnt reasons. But for a start make sure there is a cookie in your browser

GiteaMirror commented

2026-04-15 15:11:06 -05:00

@derek-rein commented on GitHub (Apr 1, 2025):

A hack fix:

// Define session data type
interface SessionData {
    user?: {
        id?: string;
        email?: string;
        name?: string;
    };
    expires?: string;
}

// Custom hook for safely fetching session data
export function useSafeSession() {
    const [sessionData, setSessionData] = useState<SessionData | null>(null);
    const [isLoading, setIsLoading] = useState(true);
    const [error, setError] = useState<Error | null>(null);

    useEffect(() => {
        const fetchSession = async () => {
            try {
                setIsLoading(true);
                const { data, error: sessionError } = await authClient.getSession();
                
                if (sessionError) {
                    setError(new Error(sessionError.message));
                } else {
                    setSessionData(data);
                }
            } catch (err) {
                setError(err instanceof Error ? err : new Error('Failed to fetch session'));
                console.error("Error fetching session:", err);
            } finally {
                setIsLoading(false);
            }
        };

        fetchSession();
    }, []);

    // Method to refresh the session data
    const refresh = async () => {
        try {
            setIsLoading(true);
            const { data, error: sessionError } = await authClient.getSession();
            
            if (sessionError) {
                setError(new Error(sessionError.message));
            } else {
                setSessionData(data);
            }
        } catch (err) {
            setError(err instanceof Error ? err : new Error('Failed to fetch session'));
            console.error("Error refreshing session:", err);
        } finally {
            setIsLoading(false);
        }
    };

    return {
        data: sessionData,
        isLoading,
        error,
        refresh
    };
}

I was previously getting this when using the supplied better-auth/react hook.

TypeError: Cannot read properties of null (reading 'useRef')
    at useRef2 (http://localhost:5173/node_modules/.vite/deps/better-auth_react.js?v=5bb48250:1075:29)
    at useStore (http://localhost:5173/node_modules/.vite/deps/better-auth_react.js?v=5bb48250:3127:45)
    at resolvedHooks.<computed> (http://localhost:5173/node_modules/.vite/deps/better-auth_react.js?v=5bb48250:3161:44)
    at UserProfile (http://localhost:5173/src/components/UserProfile.tsx?t=1743525472584:21:10)
    at react-stack-bottom-frame (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:17424:20)
    at renderWithHooks (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:4206:24)
    at updateFunctionComponent (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:6619:21)
    at beginWork (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:7654:20)
    at runWithFiberInDEV (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:1485:72)
    at performUnitOfWork (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:10868:98)

@derek-rein commented on GitHub (Apr 1, 2025): A hack fix: ``` // Define session data type interface SessionData { user?: { id?: string; email?: string; name?: string; }; expires?: string; } // Custom hook for safely fetching session data export function useSafeSession() { const [sessionData, setSessionData] = useState<SessionData | null>(null); const [isLoading, setIsLoading] = useState(true); const [error, setError] = useState<Error | null>(null); useEffect(() => { const fetchSession = async () => { try { setIsLoading(true); const { data, error: sessionError } = await authClient.getSession(); if (sessionError) { setError(new Error(sessionError.message)); } else { setSessionData(data); } } catch (err) { setError(err instanceof Error ? err : new Error('Failed to fetch session')); console.error("Error fetching session:", err); } finally { setIsLoading(false); } }; fetchSession(); }, []); // Method to refresh the session data const refresh = async () => { try { setIsLoading(true); const { data, error: sessionError } = await authClient.getSession(); if (sessionError) { setError(new Error(sessionError.message)); } else { setSessionData(data); } } catch (err) { setError(err instanceof Error ? err : new Error('Failed to fetch session')); console.error("Error refreshing session:", err); } finally { setIsLoading(false); } }; return { data: sessionData, isLoading, error, refresh }; } ``` I was previously getting this when using the supplied better-auth/react hook. ``` TypeError: Cannot read properties of null (reading 'useRef') at useRef2 (http://localhost:5173/node_modules/.vite/deps/better-auth_react.js?v=5bb48250:1075:29) at useStore (http://localhost:5173/node_modules/.vite/deps/better-auth_react.js?v=5bb48250:3127:45) at resolvedHooks.<computed> (http://localhost:5173/node_modules/.vite/deps/better-auth_react.js?v=5bb48250:3161:44) at UserProfile (http://localhost:5173/src/components/UserProfile.tsx?t=1743525472584:21:10) at react-stack-bottom-frame (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:17424:20) at renderWithHooks (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:4206:24) at updateFunctionComponent (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:6619:21) at beginWork (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:7654:20) at runWithFiberInDEV (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:1485:72) at performUnitOfWork (http://localhost:5173/node_modules/.vite/deps/react-dom_client.js?v=5bb48250:10868:98) ```

GiteaMirror commented

2026-04-15 15:11:06 -05:00

@cadinhoruf commented on GitHub (Apr 25, 2025):

+1 to this, also the expo adapter is not redirecting the users after signin wih social

you need to put hook config at auth.ts

import { betterAuth } from "better-auth";
import { prismaAdapter } from "better-auth/adapters/prisma";
import { db } from "./prisma";
import { createAuthMiddleware } from "better-auth/api";

export const auth = betterAuth({
database: prismaAdapter(db, {
provider: "postgresql",
}),
socialProviders:{
github:{
clientId: process.env.GITHUB_CLIENT_ID as string,
clientSecret: process.env.GITHUB_CLIENT_SECRET as string,
},
},
session:{
cookieCache: {
enabled: true,
maxAge: 5 * 60
},
},
hooks:{
after: createAuthMiddleware(async (ctx) => {
if(ctx.path.startsWith("/sign-up")){
const newSession = ctx.context.newSession;
if(newSession){
throw ctx.redirect(/dashboard)
}
}
}),
}
});

export type Session = typeof auth.$Infer.Session

@cadinhoruf commented on GitHub (Apr 25, 2025): > +1 to this, also the expo adapter is not redirecting the users after signin wih social you need to put hook config at auth.ts import { betterAuth } from "better-auth"; import { prismaAdapter } from "better-auth/adapters/prisma"; import { db } from "./prisma"; import { createAuthMiddleware } from "better-auth/api"; export const auth = betterAuth({ database: prismaAdapter(db, { provider: "postgresql", }), socialProviders:{ github:{ clientId: process.env.GITHUB_CLIENT_ID as string, clientSecret: process.env.GITHUB_CLIENT_SECRET as string, }, }, session:{ cookieCache: { enabled: true, maxAge: 5 * 60 }, }, **hooks:{ after: createAuthMiddleware(async (ctx) => { if(ctx.path.startsWith("/sign-up")){ const newSession = ctx.context.newSession; if(newSession){ throw ctx.redirect(`/dashboard`) } } }), }** }); export type Session = typeof auth.$Infer.Session

GiteaMirror commented

2026-04-15 15:11:07 -05:00

@widavies commented on GitHub (May 4, 2025):

@Bekacru
I've written a short utility function that makes use of React's suspense boundaries so that I don't have to check isPending in all of my components. I see this issue happen frequently.

I don't destructure authClient anywhere
I import from React: import { createAuthClient } from 'better-auth/react';
I'm on Next canary 15.4.0-canary.19 better-auth 1.2.7
Both cookies are present better-auth.session_data and better-auth.session_token
I name my function useSession - does this matter? (the issue is still present if I rename it useAuthSession, etc.)

I can provide a repo to reproduce this issue if necessary.

function useSession(options: { or: 'redirect' | 'throw' }): {
  session: Session;
  refetch: () => void;
};
function useSession(options?: { or?: never }): {
  session: Session;
  refetch: () => void;
};

function useSession(options?: {
  or?: 'redirect' | 'throw';
}): { session: Session; refetch: () => void } | null {
  suspendIfSsr('useSession');

  const router = useRouter();
  const { data, error, isPending, refetch } = authClient.useSession();

  // isPending=true is stuck! Never makes it past this if statement
  if (isPending) {
    suspend();
  }

  if (error) throw error;

  if (data === null) {
    switch (options?.or) {
      case 'redirect':
        router.push('/auth/signin');
        suspend();
        throw new Error('User is not signed in');
      case 'throw':
      default:
        throw new Error('User is not signed in');
    }
  } else {
    return {
      session: data,
      refetch,
    };
  }
}

// Helper functions

export function isBrowserLike() {
  return (
    typeof window !== 'undefined' &&
    typeof document !== 'undefined' &&
    typeof document.createElement !== 'undefined'
  );
}

export function suspendIfSsr(caller?: string) {
  if (!isBrowserLike()) {
    throw new NoSuspenseBoundaryError({ caller });
  }
}

export function suspend(): never {
  // This will never resolve!
  throw new Promise(() => {});
}

@widavies commented on GitHub (May 4, 2025): @Bekacru I've written a short utility function that makes use of React's suspense boundaries so that I don't have to check isPending in all of my components. I see this issue happen frequently. - I don't destructure `authClient` anywhere - I import from React: `import { createAuthClient } from 'better-auth/react';` - I'm on Next canary `15.4.0-canary.19` better-auth `1.2.7` - Both cookies are present `better-auth.session_data` and `better-auth.session_token` - I name my function `useSession` - does this matter? (the issue is still present if I rename it `useAuthSession`, etc.) I can provide a repo to reproduce this issue if necessary. ```ts function useSession(options: { or: 'redirect' | 'throw' }): { session: Session; refetch: () => void; }; function useSession(options?: { or?: never }): { session: Session; refetch: () => void; }; function useSession(options?: { or?: 'redirect' | 'throw'; }): { session: Session; refetch: () => void } | null { suspendIfSsr('useSession'); const router = useRouter(); const { data, error, isPending, refetch } = authClient.useSession(); // isPending=true is stuck! Never makes it past this if statement if (isPending) { suspend(); } if (error) throw error; if (data === null) { switch (options?.or) { case 'redirect': router.push('/auth/signin'); suspend(); throw new Error('User is not signed in'); case 'throw': default: throw new Error('User is not signed in'); } } else { return { session: data, refetch, }; } } // Helper functions export function isBrowserLike() { return ( typeof window !== 'undefined' && typeof document !== 'undefined' && typeof document.createElement !== 'undefined' ); } export function suspendIfSsr(caller?: string) { if (!isBrowserLike()) { throw new NoSuspenseBoundaryError({ caller }); } } export function suspend(): never { // This will never resolve! throw new Promise(() => {}); } ```

GiteaMirror commented

2026-04-15 15:11:08 -05:00

@faca69 commented on GitHub (May 14, 2025):

any news on this?

@faca69 commented on GitHub (May 14, 2025): any news on this?

GiteaMirror commented

2026-04-15 15:11:09 -05:00

@Muhammed-Rahif commented on GitHub (May 25, 2025):

A quick workaround I’m using, a component that refetches the session when the pathname changes, in case useSession() doesn’t update as expected.

src\components\session-updater.tsx:

"use client";

import { useEffect } from "react";
import { usePathname } from "next/navigation";

import { useSession } from "@/utils/client/auth-utils";

/**
 * This component is a temporary fix for the `useSession() not always triggering a state change` issue:
 * - https://github.com/better-auth/better-auth/issues/1006
 * - https://www.reddit.com/r/nextjs/comments/1jfnj59/help_betterauth_clientside_session_return_null/
 * 
 * This component should be removed once any of the above issues are resolved.
 */
export default function SessionUpdater() {
  const { data: session, refetch } = useSession();
  const pathname = usePathname();

  useEffect(() => {
    if (session) return;
    refetch(); // Refetch session data when the pathname changes
  }, [refetch, pathname, session]);
  return null;
}

Can be removed once the issue is resolved.

@Muhammed-Rahif commented on GitHub (May 25, 2025): A quick workaround I’m using, a component that refetches the session when the pathname changes, in case `useSession()` doesn’t update as expected. `src\components\session-updater.tsx`: ```tsx "use client"; import { useEffect } from "react"; import { usePathname } from "next/navigation"; import { useSession } from "@/utils/client/auth-utils"; /** * This component is a temporary fix for the `useSession() not always triggering a state change` issue: * - https://github.com/better-auth/better-auth/issues/1006 * - https://www.reddit.com/r/nextjs/comments/1jfnj59/help_betterauth_clientside_session_return_null/ * * This component should be removed once any of the above issues are resolved. */ export default function SessionUpdater() { const { data: session, refetch } = useSession(); const pathname = usePathname(); useEffect(() => { if (session) return; refetch(); // Refetch session data when the pathname changes }, [refetch, pathname, session]); return null; } ``` Can be removed once the issue is resolved.

GiteaMirror commented

2026-04-15 15:11:09 -05:00

@Nikola-Milovic commented on GitHub (Jun 2, 2025):

@Bekacru I can confirm that what you stated is not the case, at least for me.

import { createAuthClient } from "better-auth/react";

const authClient = createAuthClient({
  baseURL:"...",
  plugins: [],
});

export const {
  useSession,
  signIn,
  signUp,
  signOut,
  forgetPassword,
  resetPassword,
} = authClient;

export type Session = typeof authClient.$Infer.Session;
export type User = typeof authClient.$Infer.Session.user;

Only the destructed methods are used.

Latest version 1.28.0, this bug should probably be higher on the priority list considering how breaking it is

Here is how it manifests

isAuthenticated = !!session?.user <- we check if we have the session and the user

isAuthenticated false true <- first render is loading the session

session useEffect triggered {userId: null, location: '/'} <- initial effect trigger

No session or user id, not setting userId <- we have no session

isAuthenticated false true  <- we're still loading, another rerender

isAuthenticated true false <- we got the session, everythings working, but even though session changed use effect hasn't triggered

I am I missing something obvious or?

export function AuthProvider({ children }: { children: ReactNode }) {
  const { data, isPending } = useSession();
  const setUserId = useAppStore((state) => state.setUserId);

  const value = {
    session: data,
    isLoading: isPending,
    isAuthenticated: !!data?.user,
  };

  useEffect(() => {
    console.log('session useEffect triggered', {
      userId: data, location: location.pathname
    });

    if (data?.user?.id) {
      console.log('Setting userId in store:', data.user.id);
      setUserId(data.user.id);
    } else {
      console.log('No session or user id, not setting userId');
    }
  }, [data, setUserId]);

  return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;
}

@Nikola-Milovic commented on GitHub (Jun 2, 2025): @Bekacru I can confirm that what you stated is not the case, at least for me. ```typescript import { createAuthClient } from "better-auth/react"; const authClient = createAuthClient({ baseURL:"...", plugins: [], }); export const { useSession, signIn, signUp, signOut, forgetPassword, resetPassword, } = authClient; export type Session = typeof authClient.$Infer.Session; export type User = typeof authClient.$Infer.Session.user; ``` Only the destructed methods are used. Latest version `1.28.0`, this bug should probably be higher on the priority list considering how breaking it is Here is how it manifests ``` isAuthenticated = !!session?.user <- we check if we have the session and the user isAuthenticated false true <- first render is loading the session session useEffect triggered {userId: null, location: '/'} <- initial effect trigger No session or user id, not setting userId <- we have no session isAuthenticated false true <- we're still loading, another rerender isAuthenticated true false <- we got the session, everythings working, but even though session changed use effect hasn't triggered ``` I am I missing something obvious or? ```typescript export function AuthProvider({ children }: { children: ReactNode }) { const { data, isPending } = useSession(); const setUserId = useAppStore((state) => state.setUserId); const value = { session: data, isLoading: isPending, isAuthenticated: !!data?.user, }; useEffect(() => { console.log('session useEffect triggered', { userId: data, location: location.pathname }); if (data?.user?.id) { console.log('Setting userId in store:', data.user.id); setUserId(data.user.id); } else { console.log('No session or user id, not setting userId'); } }, [data, setUserId]); return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>; } ```

GiteaMirror commented

2026-04-15 15:11:11 -05:00

@iLambda commented on GitHub (Jun 17, 2025):

Can also confirm that it still happens to me that using the useSession() hook does not rerender some components properly.

I have a very basic setup with a component that mounts only if a session exists, and the user can disconnect if prompted by a dialog coming from somewhere else. If I unlog using the dialog, my other component never unmounts, unless I trigger a full page reload.

I've made sure that I've been using the latest versions, and I don't even export deconstructed methods from the authClient, so it's not that. The client is also coming from 'better-auth/react', so no problem there.

@iLambda commented on GitHub (Jun 17, 2025): Can also confirm that it still happens to me that using the `useSession()` hook does not rerender some components properly. I have a very basic setup with a component that mounts only if a session exists, and the user can disconnect if prompted by a dialog coming from somewhere else. If I unlog using the dialog, my other component never unmounts, unless I trigger a full page reload. I've made sure that I've been using the latest versions, and I don't even export deconstructed methods from the authClient, so it's not that. The client is also coming from 'better-auth/react', so no problem there.

GiteaMirror commented

2026-04-15 15:11:11 -05:00

@pranavp10 commented on GitHub (Jun 21, 2025):

check imports if you are using react then the import will be
import { createAuthClient } from "better-auth/react";

@pranavp10 commented on GitHub (Jun 21, 2025): check imports if you are using react then the import will be `import { createAuthClient } from "better-auth/react"; `

GiteaMirror commented

2026-04-15 15:11:13 -05:00

@wayne4o312 commented on GitHub (Jun 24, 2025):

the bug still exist

@wayne4o312 commented on GitHub (Jun 24, 2025): the bug still exist

GiteaMirror commented

2026-04-15 15:11:13 -05:00

@xn1cklas commented on GitHub (Jul 1, 2025):

I had this issue when navigating to an authenticated page after sign-in. Before redirecting to the authenticated pages, after successful sign-in, I ran a refetch from the useSession hook. This fixed the problem.

It seems like local session state is not refetched after session creation.

@xn1cklas commented on GitHub (Jul 1, 2025): I had this issue when navigating to an authenticated page after sign-in. Before redirecting to the authenticated pages, after successful sign-in, I ran a refetch from the useSession hook. This fixed the problem. It seems like local session state is not refetched after session creation.

GiteaMirror commented

2026-04-15 15:11:14 -05:00

@bcheung commented on GitHub (Jul 2, 2025):

I used react query to manually refetch and periodically refetch the session to get around this useSession hook issue not triggering a rerender.
However, I am randomly getting a null session when calling get-session even though cookies are set. Something tells me it might be related to this useSession hook issue.
For more context and repro of the null session issue without using this useSession hook:
https://github.com/better-auth/better-auth/issues/2055#issuecomment-3017746698

@bcheung commented on GitHub (Jul 2, 2025): I used react query to manually refetch and periodically refetch the session to get around this useSession hook issue not triggering a rerender. However, I am randomly getting a null session when calling get-session even though cookies are set. Something tells me it might be related to this useSession hook issue. For more context and repro of the null session issue without using this useSession hook: https://github.com/better-auth/better-auth/issues/2055#issuecomment-3017746698

GiteaMirror commented

2026-04-15 15:11:15 -05:00

@harveylee commented on GitHub (Jul 10, 2025):

I had been having an issue with similar symptoms, which seemed to resolve when I disabled the cookieCache in the session options. Hope this helps someone else too.

@harveylee commented on GitHub (Jul 10, 2025): I had been having an issue with similar symptoms, which seemed to resolve when I disabled the `cookieCache` in the `session` options. Hope this helps someone else too.

GiteaMirror commented

2026-04-15 15:11:15 -05:00

@arjunsajeev commented on GitHub (Jul 15, 2025):

@Bekacru Please let us know if there are any updates. It seems the useSession hook is not getting the refreshed session when login is done using server actions. Several users seem to have reported this.

@arjunsajeev commented on GitHub (Jul 15, 2025): @Bekacru Please let us know if there are any updates. It seems the `useSession` hook is not getting the refreshed session when login is done using server actions. Several users seem to have reported this.

GiteaMirror commented

2026-04-15 15:11:16 -05:00

@einsteinsbrd commented on GitHub (Jul 16, 2025):

@Bekacru Please let us know if there are any updates. It seems the useSession hook is not getting the refreshed session when login is done using server actions. Several users seem to have reported this.

+1

@einsteinsbrd commented on GitHub (Jul 16, 2025): > [@Bekacru](https://github.com/Bekacru) Please let us know if there are any updates. It seems the `useSession` hook is not getting the refreshed session when login is done using server actions. Several users seem to have reported this. +1

GiteaMirror commented

2026-04-15 15:11:17 -05:00

@kawpii commented on GitHub (Jul 17, 2025):

I recently saw BetterAuth on HN, saying it received funding, hope they focus on resolving this issue soon, since this seems like a deal breaker for us developers.

@kawpii commented on GitHub (Jul 17, 2025): I recently saw BetterAuth on HN, saying it received funding, hope they focus on resolving this issue soon, since this seems like a deal breaker for us developers.

GiteaMirror commented

2026-04-15 15:11:18 -05:00

@SorooshGb commented on GitHub (Jul 21, 2025):

It’s been over a year and a half since this issue was opened — still no resolution?

For context: I’m using Better Auth with both the server and client setup.

When I sign in using authClient.signIn.email on the client, useSession() updates correctly.
But when I sign in using auth.api.signInEmail on the server (e.g. in a server action), the client session returned from useSession() doesn’t react to the updated auth state. I have to manually refresh the page for it to pick up the new session.

👉 The core issue seems to be: signing in with the server auth object doesn’t trigger a session update on the client authClient object.

@SorooshGb commented on GitHub (Jul 21, 2025): **It’s been over a year and a half since this issue was opened — still no resolution?** For context: I’m using Better Auth with both the server and client setup. When I sign in using **authClient**.signIn.email on the client, useSession() updates correctly. But when I sign in using **auth**.api.signInEmail on the server (e.g. in a server action), the client session returned from useSession() doesn’t react to the updated auth state. I have to manually refresh the page for it to pick up the new session. 👉 The **core issue** seems to be: signing in with the server auth object doesn’t trigger a session update on the client authClient object.

GiteaMirror commented

2026-04-15 15:11:19 -05:00

@vojtech-cerveny commented on GitHub (Jul 21, 2025):

I found a solution in the official Prisma documentation.
I think the tricky part is waiting for the session — and most of the time, it fails for all of us.

It fixed my problem where I had useSession() in layout.tsx, and the session wasn’t updating after logging in.
Only a page refresh worked.

With this piece of code, it works as expected — the session updates properly after sign-in and sign-out.

Try this approach:


"use client";

import {
  DropdownMenu,
  DropdownMenuContent,
  DropdownMenuItem,
  DropdownMenuLabel,
  DropdownMenuTrigger,
} from "@/components/ui/dropdown-menu";
import { useSession } from "@/lib/auth-client";
import Link from "next/link";
import { useRouter } from "next/navigation";
import { useEffect } from "react";
import { Button } from "../ui/button";
import { UserAvatar } from "../user/avatar";
import { SignOut } from "./sign-out";

export default function UserButton() {
  const router = useRouter();
  const { data: session, isPending } = useSession();

  useEffect(() => {
    if (!isPending && !session?.user) {
      router.push("/signin");
    }
  }, [isPending, session, router]);

  if (isPending) return <p className="mt-8 text-center">Loading...</p>;
  if (!session?.user) return <Link href="/signin">Sign in</Link>;

  return (
    <DropdownMenu>
      <DropdownMenuTrigger asChild>
        <div className="rounded-full border-2 border-solid border-slate-500 hover:border-slate-200">
          <UserAvatar image={session.user.image ?? null} size={8} />
        </div>
      </DropdownMenuTrigger>
      <DropdownMenuContent className="w-56" align="end" forceMount>
        <DropdownMenuLabel className="font-normal">
          <div className="flex flex-col space-y-1">
            <p className="leading-none">{session.user.name}</p>
            <p className="text-xs leading-none text-muted-foreground">{session.user.email}</p>
          </div>
        </DropdownMenuLabel>
        <DropdownMenuItem>
          <Link href="/profile" className="w-full">
            <Button className="w-full">Profile</Button>
          </Link>
        </DropdownMenuItem>
        <DropdownMenuItem>
          <SignOut className="w-full" />
        </DropdownMenuItem>
      </DropdownMenuContent>
    </DropdownMenu>
  );
}

@vojtech-cerveny commented on GitHub (Jul 21, 2025): I found a solution in the [official Prisma documentation](https://www.prisma.io/docs/guides/betterauth-nextjs#53-dashboard-page). I think the tricky part is **waiting for the session** — and most of the time, it fails for all of us. It fixed my problem where I had `useSession()` in `layout.tsx`, and the session **wasn’t updating after logging in**. Only a page refresh worked. With this piece of code, it works as expected — the session updates properly after sign-in and sign-out. **Try this approach:** ```typescript "use client"; import { DropdownMenu, DropdownMenuContent, DropdownMenuItem, DropdownMenuLabel, DropdownMenuTrigger, } from "@/components/ui/dropdown-menu"; import { useSession } from "@/lib/auth-client"; import Link from "next/link"; import { useRouter } from "next/navigation"; import { useEffect } from "react"; import { Button } from "../ui/button"; import { UserAvatar } from "../user/avatar"; import { SignOut } from "./sign-out"; export default function UserButton() { const router = useRouter(); const { data: session, isPending } = useSession(); useEffect(() => { if (!isPending && !session?.user) { router.push("/signin"); } }, [isPending, session, router]); if (isPending) return <p className="mt-8 text-center">Loading...</p>; if (!session?.user) return <Link href="/signin">Sign in</Link>; return ( <DropdownMenu> <DropdownMenuTrigger asChild> <div className="rounded-full border-2 border-solid border-slate-500 hover:border-slate-200"> <UserAvatar image={session.user.image ?? null} size={8} /> </div> </DropdownMenuTrigger> <DropdownMenuContent className="w-56" align="end" forceMount> <DropdownMenuLabel className="font-normal"> <div className="flex flex-col space-y-1"> <p className="leading-none">{session.user.name}</p> <p className="text-xs leading-none text-muted-foreground">{session.user.email}</p> </div> </DropdownMenuLabel> <DropdownMenuItem> <Link href="/profile" className="w-full"> <Button className="w-full">Profile</Button> </Link> </DropdownMenuItem> <DropdownMenuItem> <SignOut className="w-full" /> </DropdownMenuItem> </DropdownMenuContent> </DropdownMenu> ); } ```

GiteaMirror commented

2026-04-15 15:11:20 -05:00

@ping-maxwell commented on GitHub (Aug 8, 2025):

To my knowledge, useSession will refetch session data if any session related endpoints were called on the same client. There's a listener part of useSession that will refetch that data once any one of those endpoints were hit.
If the session/user were to be updated on the server, the useSession's internal listener wouldn't know that and thus wouldn't trigger a session refetch.

It's a tricky problem to solve, as it would require the server to tell the client to refetch the session. This would require something like web-sockets which is definitely not a good solution.
Alternatively polling from the client side to check if a session update is due is possibly another solution, but isn't the greatest either.

@ping-maxwell commented on GitHub (Aug 8, 2025): To my knowledge, useSession will refetch session data if any session related endpoints were called on the same client. There's a listener part of useSession that will refetch that data once any one of those endpoints were hit. If the session/user were to be updated on the server, the useSession's internal listener wouldn't know that and thus wouldn't trigger a session refetch. It's a tricky problem to solve, as it would require the server to tell the client to refetch the session. This would require something like web-sockets which is definitely not a good solution. Alternatively polling from the client side to check if a session update is due is possibly another solution, but isn't the greatest either.

GiteaMirror commented

2026-04-15 15:11:20 -05:00

@widavies commented on GitHub (Aug 8, 2025):

I agree with @ping-maxwell here, you can't do anything about a server side session refresh unless you poll or push from the server to the client.

I have found however that not every client request actually updates the store. I had to do this to one of my requests to make it actually update the store:

await authClient
      .getSession({
        query: {
          disableCookieCache: true,
        },
        fetchOptions: {
          throw: true,
          onSuccess: (ctx) => {
            authClient.$store.atoms['session'].set({
              ...authClient.$store.atoms['session'].get(),
              data: ctx.data,
              headers: ctx.response.headers,
              isPending: false,
              isRefetching: false,
            });
          },
        },
      })
      .catch(() => {
        // Fallback to the old store value
        return authClient.$store.atoms['session'].get();
      });

@widavies commented on GitHub (Aug 8, 2025): I agree with @ping-maxwell here, you can't do anything about a server side session refresh unless you poll or push from the server to the client. I have found however that not every client request actually updates the store. I had to do this to one of my requests to make it actually update the store: ```ts await authClient .getSession({ query: { disableCookieCache: true, }, fetchOptions: { throw: true, onSuccess: (ctx) => { authClient.$store.atoms['session'].set({ ...authClient.$store.atoms['session'].get(), data: ctx.data, headers: ctx.response.headers, isPending: false, isRefetching: false, }); }, }, }) .catch(() => { // Fallback to the old store value return authClient.$store.atoms['session'].get(); }); ```

GiteaMirror commented

2026-04-15 15:11:21 -05:00

@widavies commented on GitHub (Aug 30, 2025):

@ping-maxwell One random thing to consider is that useSession (as I understand) only reacts to session changes in the current tab - not between tabs. This may be one reason that people perceive it as not reacting.

This also got me thinking about multi-device sessions. Changing the active session will update cookies across all tabs, but useSession is not aware of this and won't react. This also ends up splitting the session state - some is in the session nanostore, and some in the site cookies. This can be a problem in multi-device sessions for example, it might be nice to have one account signed in on one tab and another account on a different tab but as far as I understand it, this is not possible yet because of the cookies applying to all tabs.

@widavies commented on GitHub (Aug 30, 2025): @ping-maxwell One random thing to consider is that `useSession` (as I understand) only reacts to session changes in the current tab - not between tabs. This may be one reason that people perceive it as not reacting. This also got me thinking about multi-device sessions. Changing the active session will update cookies across all tabs, but `useSession` is not aware of this and won't react. This also ends up splitting the session state - some is in the session nanostore, and some in the site cookies. This can be a problem in multi-device sessions for example, it might be nice to have one account signed in on one tab and another account on a different tab but as far as I understand it, this is not possible yet because of the cookies applying to all tabs.

GiteaMirror commented

2026-04-15 15:11:22 -05:00

@ping-maxwell commented on GitHub (Aug 31, 2025):

@widavies Yeah.
One thing we have also considered is to refetch the session on tab focus, I don't believe this is already a feature but shouldn't be too hard to implement on each devs end if needed ASAP.
Essentially it's just a window.addEventListener("focus", () => refetch())

@ping-maxwell commented on GitHub (Aug 31, 2025): @widavies Yeah. One thing we have also considered is to refetch the session on tab focus, I don't believe this is already a feature but shouldn't be too hard to implement on each devs end if needed ASAP. Essentially it's just a `window.addEventListener("focus", () => refetch())`

GiteaMirror commented

2026-04-15 15:11:25 -05:00

@markaljhon commented on GitHub (Sep 23, 2025):

In my case, the issue was useSession or getSession weren't passing cookies to the header.

// auth.ts
import { betterAuth } from "better-auth";

export const auth = betterAuth({
  // ...other better-auth config
  advanced: {
    defaultCookieAttributes: {
      sameSite: "none", // this works for me
      secure: true
    }
  }
});

@markaljhon commented on GitHub (Sep 23, 2025): In my case, the issue was `useSession` or `getSession` weren't passing cookies to the header. ```ts // auth.ts import { betterAuth } from "better-auth"; export const auth = betterAuth({ // ...other better-auth config advanced: { defaultCookieAttributes: { sameSite: "none", // this works for me secure: true } } }); ```

GiteaMirror commented

2026-04-15 15:11:26 -05:00

@ptts commented on GitHub (Oct 3, 2025):

(Context: TanStack Router Client-Side Only Setup, better-auth v1.3.25)

In my case, authClient.signIn.passkey({}) fails to properly update the session, but authClient.signIn.email() works fine.

As a workaround, I did:

const session = authClient.useSession();
// ...
const { data, error } = await authClient.signIn.passkey({
  fetchOptions: {
    onResponse: () => session.refetch(), // ⬅️
  },
});

@ptts commented on GitHub (Oct 3, 2025): _(Context: TanStack Router Client-Side Only Setup, better-auth v1.3.25)_ In my case, `authClient.signIn.passkey({})` fails to properly update the session, but `authClient.signIn.email()` works fine. As a workaround, I did: ```ts const session = authClient.useSession(); // ... const { data, error } = await authClient.signIn.passkey({ fetchOptions: { onResponse: () => session.refetch(), // ⬅️ }, }); ```

GiteaMirror commented

2026-04-15 15:11:27 -05:00

@ping-maxwell commented on GitHub (Oct 3, 2025):

@ptts I think your issue is related to https://github.com/better-auth/better-auth/issues/858

@ping-maxwell commented on GitHub (Oct 3, 2025): @ptts I think your issue is related to https://github.com/better-auth/better-auth/issues/858

GiteaMirror commented

2026-04-15 15:11:29 -05:00

@m-umar-ch commented on GitHub (Nov 22, 2025):

@kaushalyap is right. This worked for me too. Its problem of importing form client and not from react

We'all are importing like import { createAuthClient } from "better-auth/client"; . This will only work on the server side.

also make another instance of auth client like import { createAuthClient as reactCreateAuthClient } from "better-auth/react";. This will work in client side.

@m-umar-ch commented on GitHub (Nov 22, 2025): @kaushalyap is right. This worked for me too. Its problem of importing form `client` and not from `react` We'all are importing like `import { createAuthClient } from "better-auth/client";` . This will only work on the server side. also make another instance of auth client like `import { createAuthClient as reactCreateAuthClient } from "better-auth/react";`. This will work in client side.

GiteaMirror commented

2026-04-15 15:11:29 -05:00

@ping-maxwell commented on GitHub (Nov 22, 2025):

@m-umar-ch this is not the issue everyone is facing.

Unfortunately this github issue title is too general that it captures several different issues into the same thread.

@ping-maxwell commented on GitHub (Nov 22, 2025): @m-umar-ch this is not the issue everyone is facing. Unfortunately this github issue title is too general that it captures several different issues into the same thread.

GiteaMirror commented

2026-04-15 15:11:30 -05:00

@hartbit commented on GitHub (Jan 8, 2026):

I have found however that not every client request actually updates the store. I had to do this to one of my requests to make it actually update the store:

await authClient
      .getSession({
        query: {
          disableCookieCache: true,
        },
        fetchOptions: {
          throw: true,
          onSuccess: (ctx) => {
            authClient.$store.atoms['session'].set({
              ...authClient.$store.atoms['session'].get(),
              data: ctx.data,
              headers: ctx.response.headers,
              isPending: false,
              isRefetching: false,
            });
          },
        },
      })
      .catch(() => {
        // Fallback to the old store value
        return authClient.$store.atoms['session'].get();
      });

I've had the exact same issue (in Vue.js) where a client call to getSession after a user update on the server returns the correctly updated user in the response payload but other component's useSession reference don't get updated. I confirm that the workaround above resolved the issue. But I'd love for a better fix.

@hartbit commented on GitHub (Jan 8, 2026): > I have found however that not every client request actually updates the store. I had to do this to one of my requests to make it actually update the store: > > ```js > await authClient > .getSession({ > query: { > disableCookieCache: true, > }, > fetchOptions: { > throw: true, > onSuccess: (ctx) => { > authClient.$store.atoms['session'].set({ > ...authClient.$store.atoms['session'].get(), > data: ctx.data, > headers: ctx.response.headers, > isPending: false, > isRefetching: false, > }); > }, > }, > }) > .catch(() => { > // Fallback to the old store value > return authClient.$store.atoms['session'].get(); > }); > ``` I've had the exact same issue (in Vue.js) where a client call to `getSession` after a user update on the server returns the correctly updated user in the response payload but other component's `useSession` reference don't get updated. I confirm that the workaround above resolved the issue. But I'd love for a better fix.

GiteaMirror commented

2026-04-15 15:11:31 -05:00

@ping-maxwell commented on GitHub (Jan 9, 2026):

Hello all, this issue has been open since version 1.1.1 which is quite some time ago now, several fixes have been made since and lots have changed. This specific issue being very broad in the title/description has caught a lot of different cases which are unrelated to the OPs case. I'll be closing this issue as for most cases this should be solved, any new recent issues about this please open a new issue detailing your case - this will help us debug your situation easier.

Regarding a common issue I see appearing in this thread being related to the client's useSession not updating whenever user data changes when updating on the server. This is because there was no way for Better Auth to communicate to your front-end to alert changes and trigger state changes accordingly. This has now changed, and the auth-client now has polling functionality built-in to refetch session data periodically.

@ping-maxwell commented on GitHub (Jan 9, 2026): Hello all, this issue has been open since version 1.1.1 which is quite some time ago now, several fixes have been made since and lots have changed. This specific issue being very broad in the title/description has caught a lot of different cases which are unrelated to the OPs case. I'll be closing this issue as for most cases this should be solved, any new recent issues about this please open a new issue detailing your case - this will help us debug your situation easier. Regarding a common issue I see appearing in this thread being related to the client's `useSession` not updating whenever user data changes when updating on the server. This is because there was no way for Better Auth to communicate to your front-end to alert changes and trigger state changes accordingly. This has now changed, and the auth-client now has polling functionality built-in to refetch session data periodically.

Sign in to join this conversation.

Branches Tags

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

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

dependabot/npm_and_yarn/uuid-14.0.0

dependabot/npm_and_yarn/turbo-2.9.14

changeset-release/main

main

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

dependabot/npm_and_yarn/samlify-2.13.0

dependabot/npm_and_yarn/ws-8.20.1

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

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

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#17175

[GH-ISSUE #1006] useSession() not always triggering a state change #17175

Is this suited for github?

To Reproduce

Current vs. Expected behavior

What version of Better Auth are you using?

Provide environment information

Which area(s) are affected? (Select all that apply)

Auth config (if applicable)

Additional context

[GH-ISSUE #1006] `useSession()` not always triggering a state change #17175