auth.api.getSession returns null in RSC Layout.tsx with valid session #947

@Kinfe123 commented on GitHub (Mar 30, 2025):

before adding what? next-intl works fine without adding the getSession call inside it or what do you mean exactly?

i mean before adding next-intl and additionalFields.

@Kinfe123 commented on GitHub (Mar 30, 2025): > before adding what? next-intl works fine without adding the getSession call inside it or what do you mean exactly? i mean before adding next-intl and additionalFields.

GiteaMirror commented

@BjoernRave commented on GitHub (Mar 30, 2025):

ahh, in general better-auth works fine for me. I added it to an existing application so next-intl was already there. My only issue was getting the session inside the getRequestConfig call, which is (I am 95% certain) done on the server, so related to the issue. Btw. this is my core, I use the customSession plugin:

import { prisma } from "@scoutello/db"
import { sendMail } from "@scoutello/mail"
import { getLanguages } from "@scoutello/shared/constants"
import { userSelect } from "@scoutello/shared/includes"
import { trustedOrigins } from "@scoutello/shared/trusted-origins"
import { getFullUrl } from "@scoutello/shared/utils"
import acceptLanguageParser from "accept-language-parser"
import { betterAuth } from "better-auth"
import { prismaAdapter } from "better-auth/adapters/prisma"
import {
  anonymous,
  createAuthMiddleware,
  customSession,
  emailOTP,
} from "better-auth/plugins"

const formatUser = (user) => ({
  ...user,
  images: user.images
    .sort((a, b) => a.order - b.order)
    .map((i) => ({
      ...i,
      image: {
        ...i.image,
        fullUrl: getFullUrl(i.image.url),
      },
    })),
  description: user?.descriptions?.find((d) => d.language === user.language)
    ?.text,
  organizations: user.organizations.map((p) => ({
    ...p.organization,
    permissions: p.permissions.split(","),
  })),
  email: user.email,
  guideInTours: user.guideInTours,
})

export const auth = betterAuth({
  appName: "Scoutello",
  database: prismaAdapter(prisma, {
    provider: "postgresql",
  }),
  account: {
    accountLinking: {
      trustedProviders: ["google", "apple", "linkedin"],
    },
  },
  emailAndPassword: {
    enabled: true,
  },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID || "",
      clientSecret: process.env.GOOGLE_CLIENT_SECRET || "",
      redirectURI: `${process.env.NEXT_PUBLIC_DASHBOARD_URL}/api/auth/callback/google`,
      mapProfileToUser: async (profile) => {
        console.log(profile, "goggle")

        return {
          email: profile.email,
          firstName: profile.given_name,
          lastName: profile.family_name,
        }
      },
    },
    apple: {
      clientId: process.env.APPLE_CLIENT_ID || "",
      clientSecret: process.env.APPLE_CLIENT_SECRET || "",
      redirectURI: `${process.env.NEXT_PUBLIC_DASHBOARD_URL}/api/auth/callback/apple`,
      mapProfileToUser: async (profile) => {
        console.log(profile, "apple")

        return {
          email: profile.email,
        }
      },
    },
    linkedin: {
      clientId: process.env.LINKEDIN_CLIENT_ID || "",
      clientSecret: process.env.LINKEDIN_CLIENT_SECRET || "",
      redirectURI: `${process.env.NEXT_PUBLIC_DASHBOARD_URL}/api/auth/callback/linkedin`,
      mapProfileToUser: async (profile) => {
        console.log(profile, "linkedin")

        return {
          email: profile.email,
        }
      },
    },
  },
  trustedOrigins: trustedOrigins,
  hooks: {
    after: createAuthMiddleware(async (ctx) => {
      if (ctx.path?.includes("/sign-in/anonymous")) {
        const language = acceptLanguageParser.pick(
          getLanguages.map((l) => l.value),
          ctx.headers.get("accept-language"),
          {
            loose: true,
          },
        )

        await prisma.user.update({
          where: {
            id: (ctx.context.returned as any).user.id,
          },
          data: {
            language,
          },
        })
      }
    }),
  },
  plugins: [
    customSession(async ({ user, session }) => {
      const richUser = await prisma.user.findUnique({
        where: {
          id: user.id,
        },
        select: userSelect,
      })

      return {
        session,
        user: formatUser(richUser),
      }
    }),
    emailOTP({
      async sendVerificationOTP({ email, otp, type }) {
        await sendMail({
          to: email,
          type: "send-otp",
          variables: {
            otp,
            username: email,
          },
          language: "de",
        })
      },
    }),
    anonymous(),
  ],
})

@BjoernRave commented on GitHub (Mar 30, 2025): ahh, in general better-auth works fine for me. I added it to an existing application so next-intl was already there. My only issue was getting the session inside the getRequestConfig call, which is (I am 95% certain) done on the server, so related to the issue. Btw. this is my core, I use the customSession plugin: ```typescript import { prisma } from "@scoutello/db" import { sendMail } from "@scoutello/mail" import { getLanguages } from "@scoutello/shared/constants" import { userSelect } from "@scoutello/shared/includes" import { trustedOrigins } from "@scoutello/shared/trusted-origins" import { getFullUrl } from "@scoutello/shared/utils" import acceptLanguageParser from "accept-language-parser" import { betterAuth } from "better-auth" import { prismaAdapter } from "better-auth/adapters/prisma" import { anonymous, createAuthMiddleware, customSession, emailOTP, } from "better-auth/plugins" const formatUser = (user) => ({ ...user, images: user.images .sort((a, b) => a.order - b.order) .map((i) => ({ ...i, image: { ...i.image, fullUrl: getFullUrl(i.image.url), }, })), description: user?.descriptions?.find((d) => d.language === user.language) ?.text, organizations: user.organizations.map((p) => ({ ...p.organization, permissions: p.permissions.split(","), })), email: user.email, guideInTours: user.guideInTours, }) export const auth = betterAuth({ appName: "Scoutello", database: prismaAdapter(prisma, { provider: "postgresql", }), account: { accountLinking: { trustedProviders: ["google", "apple", "linkedin"], }, }, emailAndPassword: { enabled: true, }, socialProviders: { google: { clientId: process.env.GOOGLE_CLIENT_ID || "", clientSecret: process.env.GOOGLE_CLIENT_SECRET || "", redirectURI: `${process.env.NEXT_PUBLIC_DASHBOARD_URL}/api/auth/callback/google`, mapProfileToUser: async (profile) => { console.log(profile, "goggle") return { email: profile.email, firstName: profile.given_name, lastName: profile.family_name, } }, }, apple: { clientId: process.env.APPLE_CLIENT_ID || "", clientSecret: process.env.APPLE_CLIENT_SECRET || "", redirectURI: `${process.env.NEXT_PUBLIC_DASHBOARD_URL}/api/auth/callback/apple`, mapProfileToUser: async (profile) => { console.log(profile, "apple") return { email: profile.email, } }, }, linkedin: { clientId: process.env.LINKEDIN_CLIENT_ID || "", clientSecret: process.env.LINKEDIN_CLIENT_SECRET || "", redirectURI: `${process.env.NEXT_PUBLIC_DASHBOARD_URL}/api/auth/callback/linkedin`, mapProfileToUser: async (profile) => { console.log(profile, "linkedin") return { email: profile.email, } }, }, }, trustedOrigins: trustedOrigins, hooks: { after: createAuthMiddleware(async (ctx) => { if (ctx.path?.includes("/sign-in/anonymous")) { const language = acceptLanguageParser.pick( getLanguages.map((l) => l.value), ctx.headers.get("accept-language"), { loose: true, }, ) await prisma.user.update({ where: { id: (ctx.context.returned as any).user.id, }, data: { language, }, }) } }), }, plugins: [ customSession(async ({ user, session }) => { const richUser = await prisma.user.findUnique({ where: { id: user.id, }, select: userSelect, }) return { session, user: formatUser(richUser), } }), emailOTP({ async sendVerificationOTP({ email, otp, type }) { await sendMail({ to: email, type: "send-otp", variables: { otp, username: email, }, language: "de", }) }, }), anonymous(), ], }) ```

GiteaMirror commented

@ian commented on GitHub (Mar 30, 2025):

@BjoernRave this is not a next-intl issue, there are some strange behaviors with the get-session endpoint. Sometimes it refuses to return a response body but includes a 200 status.

@ian commented on GitHub (Mar 30, 2025): @BjoernRave this is not a next-intl issue, there are some strange behaviors with the get-session endpoint. Sometimes it refuses to return a response body but includes a 200 status.

GiteaMirror commented

2026-03-13 08:11:13 -05:00

@ian commented on GitHub (Mar 30, 2025):

I've found that I can make the /auth/get-session call manually and it works fine, it's just when using the auth.api.getSession helper it doesn't work at all.

Layout:

export default async function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  const { user } = await withAuth();

  console.debug('RootLayout', { user });

  return (
    <html lang="en" suppressHydrationWarning>
      <body
        className={cn(
          fontSans.variable,
          fontMono.variable,
          fontSerif.variable,
          'antialiased',
        )}
      >
        <Providers user={user}>{children}</Providers>
        <Analytics />
      </body>
    </html>
  );
}

WORKING:

export const withAuth = async () => {
  const headersList = await headers();
  const cookie = headersList.get('cookie');

  const session = await fetch(getWebUrl('/auth/get-session'), {
    headers: {
      'Content-Type': 'application/json',
      cookie: cookie ?? '',
    },
  }).then((res) => res.json());

  return session ?? { user: null, session: null };
};

DOES NOT WORK:

export const withAuth = async () => {
  const session = await auth.api.getSession({
    headers: await headers(),
  });

  return session ?? { user: null, session: null };
};

@ian commented on GitHub (Mar 30, 2025): I've found that I can make the /auth/get-session call manually and it works fine, it's just when using the auth.api.getSession helper it doesn't work at all. Layout: ```ts export default async function RootLayout({ children, }: Readonly<{ children: React.ReactNode; }>) { const { user } = await withAuth(); console.debug('RootLayout', { user }); return ( <html lang="en" suppressHydrationWarning> <body className={cn( fontSans.variable, fontMono.variable, fontSerif.variable, 'antialiased', )} > <Providers user={user}>{children}</Providers> <Analytics /> </body> </html> ); } ``` WORKING: ```ts export const withAuth = async () => { const headersList = await headers(); const cookie = headersList.get('cookie'); const session = await fetch(getWebUrl('/auth/get-session'), { headers: { 'Content-Type': 'application/json', cookie: cookie ?? '', }, }).then((res) => res.json()); return session ?? { user: null, session: null }; }; ``` DOES NOT WORK: ```ts export const withAuth = async () => { const session = await auth.api.getSession({ headers: await headers(), }); return session ?? { user: null, session: null }; }; ```

GiteaMirror commented

@BjoernRave commented on GitHub (Mar 31, 2025):

this is how the response looks like: session { "data": null, "error": { "status": 0, "statusText": "" } }

@BjoernRave commented on GitHub (Mar 31, 2025): this is how the response looks like: ```session { "data": null, "error": { "status": 0, "statusText": "" } }```

GiteaMirror commented

2026-03-13 08:11:14 -05:00

@serv commented on GitHub (Apr 1, 2025):

I'm facing the same issue.

One thing I am noticing is that the session is populated on the serverside when I am opening a page that use client.

But when the page doesn't have that, this issue happens and session is null for me. Not sure why this is the case.

@serv commented on GitHub (Apr 1, 2025): I'm facing the same issue. One thing I am noticing is that the session is populated on the serverside when I am opening a page that `use client`. But when the page doesn't have that, this issue happens and session is null for me. Not sure why this is the case.

GiteaMirror commented

2026-03-13 08:11:14 -05:00

@ian commented on GitHub (Apr 1, 2025):

Have added better-auth to second application and it's the same exact problem.

@ian commented on GitHub (Apr 1, 2025): Have added better-auth to second application and it's the same exact problem.

GiteaMirror commented

2026-03-13 08:11:14 -05:00

@Kinfe123 commented on GitHub (Apr 1, 2025):

@ian can you please send us the code sandbox or github link for more clarified reproduction

@Kinfe123 commented on GitHub (Apr 1, 2025): @ian can you please send us the code sandbox or github link for more clarified reproduction

GiteaMirror commented

@soyricardodev commented on GitHub (Apr 8, 2025):

i had this issue with next canary and better-auth, from 1.2.3 and now with 1.2.5, for me doesnt work the manual fetch to /api/auth/get-session, my solution was to create a "server redirect", basically just a server action that i call when register, login or signout with the authClient helper, if i do a route.push("/another-page"), this dont "refetch" the session on the layout, but if i redirect from a server action this is working

i need the authClient because i like the onError and onSucces for toast stuff and logging, so i dont want to login from a server action 100%, so i just create that util called redirect.ts

// lib/redirect.ts
"use server";

import { redirect } from "next/navigation";

async function serverRedirect(url: string) {
	redirect(url);
}

export { serverRedirect };

And this is how i use it:

export function SignIn({ redirectTo }: SignInProps) {
  const form = useForm<SignInSchemaInput>({
    defaultValues: {
	email: "",
	password: "",
    },
	resolver: zodResolver(signInSchema),
	});

	const [isLoading, setLoading] = useState(false);

	const router = useRouter();

	async function onSubmit(data: SignInSchemaInput) {
		setLoading(true);
		try {
			await signIn.email({
				...data,
				fetchOptions: {
					onSuccess: () => {
                                              // Here is the magic
						serverRedirect(redirectTo ?? "/cursos");
					},
					onError: (e) => {
						if (e.error.code === "INVALID_EMAIL_OR_PASSWORD") {
							form.setError("email", { type: "custom", message: "" });
							form.setError("password", {
								type: "custom",
								message: "Correo o contraseña incorrectos",
							});
						}
						toast.error("Ha ocurrido un error");
					},
				},
			});
		} catch (error) {
			console.error(error);
		} finally {
			setLoading(false);
		}
	}
// More code...

@soyricardodev commented on GitHub (Apr 8, 2025): i had this issue with next canary and better-auth, from 1.2.3 and now with 1.2.5, for me doesnt work the manual fetch to /api/auth/get-session, my solution was to create a "server redirect", basically just a server action that i call when register, login or signout with the authClient helper, if i do a route.push("/another-page"), this dont "refetch" the session on the layout, but if i redirect from a server action this is working i need the authClient because i like the onError and onSucces for toast stuff and logging, so i dont want to login from a server action 100%, so i just create that util called redirect.ts ``` // lib/redirect.ts "use server"; import { redirect } from "next/navigation"; async function serverRedirect(url: string) { redirect(url); } export { serverRedirect }; ``` And this is how i use it: ``` export function SignIn({ redirectTo }: SignInProps) { const form = useForm<SignInSchemaInput>({ defaultValues: { email: "", password: "", }, resolver: zodResolver(signInSchema), }); const [isLoading, setLoading] = useState(false); const router = useRouter(); async function onSubmit(data: SignInSchemaInput) { setLoading(true); try { await signIn.email({ ...data, fetchOptions: { onSuccess: () => { // Here is the magic serverRedirect(redirectTo ?? "/cursos"); }, onError: (e) => { if (e.error.code === "INVALID_EMAIL_OR_PASSWORD") { form.setError("email", { type: "custom", message: "" }); form.setError("password", { type: "custom", message: "Correo o contraseña incorrectos", }); } toast.error("Ha ocurrido un error"); }, }, }); } catch (error) { console.error(error); } finally { setLoading(false); } } // More code... ```

GiteaMirror commented

@Bekacru commented on GitHub (Apr 11, 2025):

can anyone share me a POC? I couldn't reproduce it either and this is a very important issue to address

@Bekacru commented on GitHub (Apr 11, 2025): can anyone share me a POC? I couldn't reproduce it either and this is a very important issue to address

GiteaMirror commented

@soyricardodev commented on GitHub (Apr 11, 2025):

can anyone share me a POC? I couldn't reproduce it either and this is a very important issue to address

I could do it, I'd love to. But one question, once I do it, how can I let you know? Would it work for you here?

@soyricardodev commented on GitHub (Apr 11, 2025): > can anyone share me a POC? I couldn't reproduce it either and this is a very important issue to address I could do it, I'd love to. But one question, once I do it, how can I let you know? Would it work for you here?

GiteaMirror commented

2026-03-13 08:11:16 -05:00

@Bekacru commented on GitHub (Apr 11, 2025):

@soyricardodev yes. make the repo public and share the link in this thread.

@Bekacru commented on GitHub (Apr 11, 2025): @soyricardodev yes. make the repo public and share the link in this thread.

GiteaMirror commented

@capaj commented on GitHub (Apr 15, 2025):

same problem here @ian your solution with calling the API with fetch works. Definitely a bug and pretty frustrating one.
I am on 1.2.7.

here's my code snippet including the proper types for the session:

  // TODO use auth.api.getSession when https://github.com/better-auth/better-auth/issues/2055 is fixed
  const session = await fetch(
    `${process.env.VERCEL_URL}/api/auth/get-session`,
    {
      headers: {
        'Content-Type': 'application/json',
        cookie: cookie ?? ''
      }
    }
  ).then((res) => res.json() as ReturnType<typeof auth.api.getSession>)

@capaj commented on GitHub (Apr 15, 2025): same problem here @ian your solution with calling the API with fetch works. Definitely a bug and pretty frustrating one. I am on 1.2.7. here's my code snippet including the proper types for the session: ```ts // TODO use auth.api.getSession when https://github.com/better-auth/better-auth/issues/2055 is fixed const session = await fetch( `${process.env.VERCEL_URL}/api/auth/get-session`, { headers: { 'Content-Type': 'application/json', cookie: cookie ?? '' } } ).then((res) => res.json() as ReturnType<typeof auth.api.getSession>) ```

GiteaMirror commented

2026-03-13 08:11:16 -05:00

@moreorover commented on GitHub (Apr 16, 2025):

I was not able to reproduce this exact problem, session always logs for me as it should inside root /src/app/layout.ts

However, I have found a very similar issue but with tRPC. After refreshing page first request that goes to private procedure comes out as unauthorized because session object received by tRPC is null.

Here is reproduction:
https://github.com/moreorover/prive-video/tree/reproduction

Instructions to start the project are found at https://github.com/moreorover/prive-video/blob/reproduction/README.md

@moreorover commented on GitHub (Apr 16, 2025): I was not able to reproduce this exact problem, session always logs for me as it should inside root `/src/app/layout.ts` However, I have found a very similar issue but with tRPC. After refreshing page first request that goes to private procedure comes out as unauthorized because session object received by tRPC is null. Here is reproduction: https://github.com/moreorover/prive-video/tree/reproduction Instructions to start the project are found at https://github.com/moreorover/prive-video/blob/reproduction/README.md

GiteaMirror commented

2026-03-13 08:11:16 -05:00

@soyricardodev commented on GitHub (Apr 17, 2025):

@soyricardodev yes. make the repo public and share the link in this thread.

Repo to reproduce here: https://github.com/soyricardodev/better-auth-nextjs-session-bug

Also a video

https://github.com/user-attachments/assets/93bf3cde-d237-451f-987c-1e94f04cda80

@soyricardodev commented on GitHub (Apr 17, 2025): > [@soyricardodev](https://github.com/soyricardodev) yes. make the repo public and share the link in this thread. [Repo to reproduce here: https://github.com/soyricardodev/better-auth-nextjs-session-bug](https://github.com/soyricardodev/better-auth-nextjs-session-bug) Also a video https://github.com/user-attachments/assets/93bf3cde-d237-451f-987c-1e94f04cda80

GiteaMirror commented

2026-03-13 08:11:17 -05:00

@soyricardodev commented on GitHub (Apr 17, 2025):

@soyricardodev yes. make the repo public and share the link in this thread.

Repo to reproduce here: https://github.com/soyricardodev/better-auth-nextjs-session-bug

Also a video

Better.Auth.nextjs.bug.webm

@Bekacru if you need more details, or help to reproduce feel free to lmk

i am very insterested to make this work by default as it should, better-auth is awesome

@soyricardodev commented on GitHub (Apr 17, 2025): > > [@soyricardodev](https://github.com/soyricardodev) yes. make the repo public and share the link in this thread. > > [Repo to reproduce here: https://github.com/soyricardodev/better-auth-nextjs-session-bug](https://github.com/soyricardodev/better-auth-nextjs-session-bug) > > Also a video > > Better.Auth.nextjs.bug.webm @Bekacru if you need more details, or help to reproduce feel free to lmk i am very insterested to make this work by default as it should, better-auth is awesome

GiteaMirror commented

2026-03-13 08:11:17 -05:00

@drago1520 commented on GitHub (Apr 19, 2025):

I have the same issue here. Again, such a basic feature is missing: the ability to simply get the session from an anonymous user.

@drago1520 commented on GitHub (Apr 19, 2025): I have the same issue here. Again, such a basic feature is missing: the ability to simply get the session from an anonymous user.

GiteaMirror commented

2026-03-13 08:11:17 -05:00

@Joe-Taka commented on GitHub (Apr 20, 2025):

For some reason /api/auth/get-session returns null for me, which also happens for auth.api.getSession(...).

@Joe-Taka commented on GitHub (Apr 20, 2025): For some reason `/api/auth/get-session` returns null for me, which also happens for `auth.api.getSession(...)`.

GiteaMirror commented

@soyricardodev commented on GitHub (Apr 21, 2025):

For some reason /api/auth/get-session returns null for me, which also happens for auth.api.getSession(...).

in which cases do you have that issue, can you share some code and your use?

@soyricardodev commented on GitHub (Apr 21, 2025): > For some reason `/api/auth/get-session` returns null for me, which also happens for `auth.api.getSession(...)`. in which cases do you have that issue, can you share some code and your use?

GiteaMirror commented

@soyricardodev commented on GitHub (Apr 21, 2025):

For some reason /api/auth/get-session returns null for me, which also happens for auth.api.getSession(...).

i didnt tested it with anon stuff, can you share a repro?

@soyricardodev commented on GitHub (Apr 21, 2025): > For some reason `/api/auth/get-session` returns null for me, which also happens for `auth.api.getSession(...)`. i didnt tested it with anon stuff, can you share a repro?

GiteaMirror commented

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

I am pretty sure

const user = await auth.api.signInAnonymous({headers: await headers()})

does not update the browser. Next.js 15.30

@drago1520 commented on GitHub (Apr 25, 2025): I am pretty sure ```js const user = await auth.api.signInAnonymous({headers: await headers()}) ``` does not update the browser. Next.js 15.30

GiteaMirror commented

@drago1520 commented on GitHub (Apr 26, 2025):

I understood why this happens. You cannot send cookies from server components (as pointed out in #2434 ), so the browser is out of sync with the database sessions. You must use client components or server actions. Let's close this issue.

@drago1520 commented on GitHub (Apr 26, 2025): I understood why this happens. You cannot send cookies from server components (as pointed out in #2434 ), so the browser is out of sync with the database sessions. You must use client components or server actions. Let's close this issue. ![Image](https://github.com/user-attachments/assets/f9ce838e-ef77-4c88-8653-e5b1a6560bd1)

GiteaMirror commented

@BjoernRave commented on GitHub (Apr 26, 2025):

@drago1520 can you please open a seperate issue for your problem with anonymous session and not pollute this thread?

@BjoernRave commented on GitHub (Apr 26, 2025): @drago1520 can you please open a seperate issue for your problem with anonymous session and not pollute this thread?

GiteaMirror commented

@drago1520 commented on GitHub (Apr 26, 2025):

@drago1520 can you please open a seperate issue for your problem with anonymous session and not pollute this thread?

I believe the issue is the same. We are trying to sign in from an RSC that does not support the writing of cookies. Thus, the browser does not return a session cookie, and we log null. Please let me know if I am wrong. More details at #2434

@drago1520 commented on GitHub (Apr 26, 2025): > [@drago1520](https://github.com/drago1520) can you please open a seperate issue for your problem with anonymous session and not pollute this thread? I believe the issue is the same. We are trying to sign in from an RSC that does not support the writing of cookies. Thus, the browser does not return a session cookie, and we log `null`. Please let me know if I am wrong. More details at #2434

GiteaMirror commented

@soyricardodev commented on GitHub (Apr 26, 2025):

I understood why this happens. You cannot send cookies from server components (as pointed out in #2434 ), so the browser is out of sync with the database sessions. You must use client components or server actions. Let's close this issue.

Can you elaborate more why this should be closed?

This happens even with client side stuff, if you see the examples from official docs and from this issue, we are using signIn from auth-client, this sets cookies and log the user with the auth handler, the cookies are being set, but the redirect with use router don't rfresh the browser UI data

@soyricardodev commented on GitHub (Apr 26, 2025): > I understood why this happens. You cannot send cookies from server components (as pointed out in [#2434](https://github.com/better-auth/better-auth/issues/2434) ), so the browser is out of sync with the database sessions. You must use client components or server actions. Let's close this issue. > > ![Image](https://github.com/user-attachments/assets/f9ce838e-ef77-4c88-8653-e5b1a6560bd1) Can you elaborate more why this should be closed? This happens even with client side stuff, if you see the examples from official docs and from this issue, we are using signIn from auth-client, this sets cookies and log the user with the auth handler, the cookies are being set, but the redirect with use router don't rfresh the browser UI data

GiteaMirror commented

2026-03-13 08:11:20 -05:00

@Kinfe123 commented on GitHub (Apr 26, 2025):

@drago1520 but on the above mentioned threads, they were logging the headers and it does have the cookie and cant able to get the session but i see you are trying to run the action handler directly with the RSC.

@Kinfe123 commented on GitHub (Apr 26, 2025): @drago1520 but on the above mentioned threads, they were logging the headers and it does have the cookie and cant able to get the session but i see you are trying to run the action handler directly with the RSC.

GiteaMirror commented

@edocollado commented on GitHub (May 7, 2025):

same problem here @ian your solution with calling the API with fetch works. Definitely a bug and pretty frustrating one. I am on 1.2.7.

here's my code snippet including the proper types for the session:

// TODO use auth.api.getSession when https://github.com/better-auth/better-auth/issues/2055 is fixed
const session = await fetch(
${process.env.VERCEL_URL}/api/auth/get-session,
{
headers: {
'Content-Type': 'application/json',
cookie: cookie ?? ''
}
}
).then((res) => res.json() as ReturnType)

i have the same problem

@edocollado commented on GitHub (May 7, 2025): > same problem here [@ian](https://github.com/ian) your solution with calling the API with fetch works. Definitely a bug and pretty frustrating one. I am on 1.2.7. > > here's my code snippet including the proper types for the session: > > // TODO use auth.api.getSession when https://github.com/better-auth/better-auth/issues/2055 is fixed > const session = await fetch( > `${process.env.VERCEL_URL}/api/auth/get-session`, > { > headers: { > 'Content-Type': 'application/json', > cookie: cookie ?? '' > } > } > ).then((res) => res.json() as ReturnType<typeof auth.api.getSession>) i have the same problem

GiteaMirror commented

2026-03-13 08:11:20 -05:00

@ian commented on GitHub (May 7, 2025):

We're using a pnpm workspace with shared auth code, I wonder if it's related.

For those having issues, can you reply with whether you are using a package in a workspace, or as a standalone repo?

@ian commented on GitHub (May 7, 2025): We're using a pnpm workspace with shared auth code, I wonder if it's related. For those having issues, can you reply with whether you are using a package in a workspace, or as a standalone repo?

GiteaMirror commented

2026-03-13 08:11:21 -05:00

@capaj commented on GitHub (May 7, 2025):

I am using pnpm in a monorepo

What do you mean by "shared Auth code"

@capaj commented on GitHub (May 7, 2025): I am using pnpm in a monorepo What do you mean by "shared Auth code"

GiteaMirror commented

2026-03-13 08:11:21 -05:00

@aleehedl commented on GitHub (May 8, 2025):

I have the same issue, but only when I'm running in dev mode with turbopack: npx next dev --turbopack, which is the default for Next.js.

With production mode or even npx next dev it works.

@aleehedl commented on GitHub (May 8, 2025): I have the same issue, but only when I'm running in dev mode with turbopack: `npx next dev --turbopack`, which is the default for Next.js. With production mode or even `npx next dev` it **works**.

GiteaMirror commented

@ricklabanca commented on GitHub (May 21, 2025):

I am glad I found this thread, it drives me crazy. In my server side code (a dto not related to a page directly) I get current user.
I can be running fine, and all of the sudden I have cookies but no session. Then a few minutes later it starts to work again. Restart makes no difference.

It is really strange because I don't see a pattern other than it stopping and suddenly start working again, same page just refreshing, nothing changes other than some time passing.

Are there some flags we could set for the session code? I am on the latest

@ricklabanca commented on GitHub (May 21, 2025): I am glad I found this thread, it drives me crazy. In my server side code (a dto not related to a page directly) I get current user. I can be running fine, and all of the sudden I have cookies but no session. Then a few minutes later it starts to work again. Restart makes no difference. It is really strange because I don't see a pattern other than it stopping and suddenly start working again, same page just refreshing, nothing changes other than some time passing. Are there some flags we could set for the session code? I am on the latest

GiteaMirror commented

@Rieranthony commented on GitHub (May 21, 2025):

I have a similar issue, I have a setup with a monorepo.

Api in a Hono server with bun and Better auth
Web app with next js

Everything works fine, I get to do the social sign in with google, cookies are set, but const session = await auth.api.getSession({ headers: await headers(), });

Always returns null

Everything is on latest.

EDIT:
Getting the session client side wiht "useSession" works fine, so the setup works.

@Rieranthony commented on GitHub (May 21, 2025): I have a similar issue, I have a setup with a monorepo. > Api in a Hono server with bun and Better auth > Web app with next js Everything works fine, I get to do the social sign in with google, cookies are set, but `const session = await auth.api.getSession({ headers: await headers(), });` Always returns `null` Everything is on latest. EDIT: Getting the session client side wiht "useSession" works fine, so the setup works.

GiteaMirror commented

@moreorover commented on GitHub (May 21, 2025):

I was not able to reproduce this exact problem, session always logs for me as it should inside root /src/app/layout.ts

However, I have found a very similar issue but with tRPC. After refreshing page first request that goes to private procedure comes out as unauthorized because session object received by tRPC is null.

Here is reproduction: https://github.com/moreorover/prive-video/tree/reproduction

Instructions to start the project are found at https://github.com/moreorover/prive-video/blob/reproduction/README.md

In my case this was due to the how Next.js handles cookies on server side. Here is the problem explained: https://github.com/t3-oss/create-t3-app/issues/1765

Nothing to do with Better Auth itself.

@moreorover commented on GitHub (May 21, 2025): > I was not able to reproduce this exact problem, session always logs for me as it should inside root `/src/app/layout.ts` > > However, I have found a very similar issue but with tRPC. After refreshing page first request that goes to private procedure comes out as unauthorized because session object received by tRPC is null. > > Here is reproduction: https://github.com/moreorover/prive-video/tree/reproduction > > Instructions to start the project are found at https://github.com/moreorover/prive-video/blob/reproduction/README.md In my case this was due to the how Next.js handles cookies on server side. Here is the problem explained: https://github.com/t3-oss/create-t3-app/issues/1765 Nothing to do with Better Auth itself.

GiteaMirror commented

@dolanoadriano commented on GitHub (May 27, 2025):

I have the problems in the dev.
After building it works.

@dolanoadriano commented on GitHub (May 27, 2025): I have the problems in the **dev**. After building it works.

GiteaMirror commented

@dolanoadriano commented on GitHub (May 27, 2025):

update: when I disable the --turbopack argument for the next dev script the problem disappears

@dolanoadriano commented on GitHub (May 27, 2025): update: when I disable the `--turbopack` argument for the `next dev` script the problem disappears

GiteaMirror commented

@elpidev commented on GitHub (May 30, 2025):

I didn't run into this issue before, but it started happening about a week ago.
I have a lot of customizations, so I tried reverting to a minimal setup, but the issue still persists.

The user/session is fetched in the root layout and other pages, and if it's null, it redirects to the login page, which is causing users to be logged out frequently.

I added a query param to /login like /login?r=201 to help track where the redirect is coming from. In my case, it's not just triggered in the root layout, it also happens on other pages.

I'm wondering if there's any workaround available at the moment.

@elpidev commented on GitHub (May 30, 2025): I didn't run into this issue before, but it started happening about a week ago. I have a lot of customizations, so I tried reverting to a minimal setup, but the issue still persists. The user/session is fetched in the root layout and other pages, and if it's null, it redirects to the login page, which is causing users to be logged out frequently. I added a query param to `/login` like `/login?r=201` to help track where the redirect is coming from. In my case, it's not just triggered in the root layout, it also happens on other pages. I'm wondering if there's any workaround available at the moment.

GiteaMirror commented

@binarytide commented on GitHub (Jun 4, 2025):

I'm trying to wrap better-auth in an Effect service, and calls like signInEmail successfully returns { redirect, token, user } no problem, but I can't get anything back from getSession

@binarytide commented on GitHub (Jun 4, 2025): I'm trying to wrap better-auth in an Effect service, and calls like signInEmail successfully returns { redirect, token, user } no problem, but I can't get anything back from getSession

GiteaMirror commented