github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-24 08:01:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

GitHub OAuth fails with "State not found undefined" error in SvelteKit setup #1534

New Issue
Closed
opened 2026-03-13 08:45:49 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-03-13 08:45:49 -05:00
Owner
Copy Link

Originally created by @gyenabubakar on GitHub (Jul 19, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Bug Description

Following the official Better Auth documentation for setting up GitHub OAuth in SvelteKit results in a "State not found undefined" error during the OAuth callback. The documented setup steps do not work as expected.

Steps to Reproduce

  1. Clone the reproduction repository: https://github.com/gyenabubakar/kit-better-auth
  2. Set up the necessary environment variables following the .env.example
  3. Create a GitHub App using the URLs from .env.example when setting up the app
  4. Get the GitHub client ID and secret and configure your environment variables
  5. Run pnpm install to install dependencies
  6. Run docker compose up --detach to start up the Postgres database.
  7. Run pnpm run db:push to set up the database tables.
  8. Run pnpm run dev to start the development server
  9. Open the application URL
  10. Click "Continue with GitHub"
  11. Complete authorisation on GitHub
  12. Observe the "State not found undefined" error when redirected back## Expected Behavior

Current vs. Expected behavior

After completing GitHub authorisation, the user should be successfully authenticated and redirected to the application.

Actual Behaviour

GitHub redirects back to the application, but Better Auth fails with:

Image

What version of Better Auth are you using?

1.3.0

Provide environment information

— OS: macOS Ventura (15.5)
— Browser: Chrome
- Framework: SvelteKit  + adapter-node
- OAuth Provider: GitHub (App method)
- Database: PostgreSQL with Drizzle ORM

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

Documentation, Package, Backend

Auth config (if applicable)

Additional context

I was working on my main project trying to set up SvelteKit + adapter-cloudflare + Turso local server but encountered the ERROR [Better Auth]: State not found undefined error. Thinking I might be doing something wrong in my main project, I created a separate minimal SvelteKit project to isolate the issue, but the same error persists.

Originally created by @gyenabubakar on GitHub (Jul 19, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce ## Bug Description Following the official Better Auth documentation for setting up GitHub OAuth in SvelteKit results in a "State not found undefined" error during the OAuth callback. The documented setup steps do not work as expected. ## Steps to Reproduce 1. Clone the reproduction repository: **[https://github.com/gyenabubakar/kit-better-auth](https://github.com/gyenabubakar/kit-better-auth)** 2. Set up the necessary environment variables following the `.env.example` 3. Create a GitHub App using the URLs from `.env.example` when setting up the app 4. Get the GitHub client ID and secret and configure your environment variables 5. Run `pnpm install` to install dependencies 6. Run `docker compose up --detach` to start up the Postgres database. 7. Run `pnpm run db:push` to set up the database tables. 8. Run `pnpm run dev` to start the development server 9. Open the application URL 10. Click "Continue with GitHub" 11. Complete authorisation on GitHub 12. Observe the "State not found undefined" error when redirected back## Expected Behavior ### Current vs. Expected behavior After completing GitHub authorisation, the user should be successfully authenticated and redirected to the application. ## Actual Behaviour GitHub redirects back to the application, but Better Auth fails with: <img width="611" height="591" alt="Image" src="https://github.com/user-attachments/assets/e8195db8-61e1-45f2-9e6f-7a4099c17940" /> ### What version of Better Auth are you using? 1.3.0 ### Provide environment information ```bash — OS: macOS Ventura (15.5) — Browser: Chrome - Framework: SvelteKit + adapter-node - OAuth Provider: GitHub (App method) - Database: PostgreSQL with Drizzle ORM ``` ### Which area(s) are affected? (Select all that apply) Documentation, Package, Backend ### Auth config (if applicable) ```typescript ``` ### Additional context I was working on my main project trying to set up SvelteKit + adapter-cloudflare + Turso local server but encountered the `ERROR [Better Auth]: State not found undefined` error. Thinking I might be doing something wrong in my main project, I created a separate minimal SvelteKit project to isolate the issue, but the same error persists.
GiteaMirror added the sveltebug labels 2026-03-13 08:45:49 -05:00
GiteaMirror commented 2026-03-13 08:45:50 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 19, 2025):

Hi @gyenabubakar! I'm Dosu and I’m helping the better-auth team.

This error is most likely caused by a problem with how cookies are handled in your SvelteKit + adapter-node setup. Better Auth stores the OAuth "state" in a cookie at the start of the flow and expects to retrieve it on the callback. If the cookie is missing or inaccessible—often due to misconfigured attributes like SameSite, path, secure, or httpOnly, or due to platform-specific quirks—this error appears.

Recent changes in Better Auth's OAuth handling (since v1.3.0-beta9) have introduced stricter or altered state management, which can break flows that previously worked, especially if the adapter or deployment environment doesn't persist cookies as expected. There are also recent code changes that affect how state is parsed and retrieved during the OAuth callback, which could be relevant here citation.

To troubleshoot, double-check your SvelteKit cookie handling: ensure cookies are set with the correct attributes and are accessible on both the OAuth initiation and callback routes. If you're customizing cookie logic, normalize attribute cases (e.g., httpOnly vs. httponly) and make sure the path and domain are correct citation. Also, verify that your redirect URLs and trusted origins are set correctly in both your GitHub app and Better Auth config, as mismatches can also cause state errors citation.

If everything looks correct and the error persists, it's possible you're hitting a regression or limitation in Better Auth's recent OAuth state handling. Some issues require library-level fixes and may not be fully resolvable via user config citation.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 19, 2025): <!-- Greeting --> Hi @gyenabubakar! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This error is most likely caused by a problem with how cookies are handled in your SvelteKit + adapter-node setup. Better Auth stores the OAuth "state" in a cookie at the start of the flow and expects to retrieve it on the callback. If the cookie is missing or inaccessible—often due to misconfigured attributes like SameSite, path, secure, or httpOnly, or due to platform-specific quirks—this error appears. Recent changes in Better Auth's OAuth handling (since v1.3.0-beta9) have introduced stricter or altered state management, which can break flows that previously worked, especially if the adapter or deployment environment doesn't persist cookies as expected. There are also recent code changes that affect how state is parsed and retrieved during the OAuth callback, which could be relevant here [citation](https://github.com/better-auth/better-auth/pull/463). To troubleshoot, double-check your SvelteKit cookie handling: ensure cookies are set with the correct attributes and are accessible on both the OAuth initiation and callback routes. If you're customizing cookie logic, normalize attribute cases (e.g., httpOnly vs. httponly) and make sure the path and domain are correct [citation](https://github.com/better-auth/better-auth/issues/3217). Also, verify that your redirect URLs and trusted origins are set correctly in both your GitHub app and Better Auth config, as mismatches can also cause state errors [citation](https://github.com/better-auth/better-auth/issues/3062). If everything looks correct and the error persists, it's possible you're hitting a regression or limitation in Better Auth's recent OAuth state handling. Some issues require library-level fixes and may not be fully resolvable via user config [citation](https://github.com/better-auth/better-auth/issues/3481). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/5e478c7a-b677-44eb-bdc9-b71dcbfb20cd?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/5e478c7a-b677-44eb-bdc9-b71dcbfb20cd?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/5e478c7a-b677-44eb-bdc9-b71dcbfb20cd?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/5e478c7a-b677-44eb-bdc9-b71dcbfb20cd?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/5e478c7a-b677-44eb-bdc9-b71dcbfb20cd?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/5e478c7a-b677-44eb-bdc9-b71dcbfb20cd?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/5e478c7a-b677-44eb-bdc9-b71dcbfb20cd?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3488)
GiteaMirror commented 2026-03-13 08:45:50 -05:00
Author
Owner
Copy Link

@gyenabubakar commented on GitHub (Jul 20, 2025):

Better Auth stores the OAuth "state" in a cookie at the start of the flow and expects to retrieve it on the callback.

@dosubot After reading this, I tried the OAuth flow again. This time, when the GitHub authorisation page loaded, I opened the app in another tab and checked the cookies in devtools; no cookie was created. At the start of the flow, a record is created in the verifications table, which is what I thought Better Auth would depend on to verify the callback and complete the flow.

@gyenabubakar commented on GitHub (Jul 20, 2025): > Better Auth stores the OAuth "state" in a cookie at the start of the flow and expects to retrieve it on the callback. @dosubot After reading this, I tried the OAuth flow again. This time, when the GitHub authorisation page loaded, I opened the app in another tab and checked the cookies in devtools; no cookie was created. At the start of the flow, a record is created in the `verifications` table, which is what I thought Better Auth would depend on to verify the callback and complete the flow.
GiteaMirror commented 2026-03-13 08:45:50 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 20, 2025):

You're correct—Better Auth does not use cookies to store the OAuth "state" during the flow. Instead, it generates a random state string and stores it in the verifications table in your database. When the OAuth callback happens, Better Auth looks up this state in the database to validate the flow. No cookie is set or expected for this part of the process, so what you observed (no cookie, but a verifications record) is the intended behavior in SvelteKit + adapter-node setups see source.

If you're seeing "State not found undefined," it means the verification record for that state is missing or expired by the time the callback happens. This can be caused by issues like: the record not being created, being deleted too soon, database connectivity problems, or the state parameter not being passed correctly through the OAuth flow see source.

Focus your debugging on the database and the state parameter: make sure the verifications table is being written to and read from as expected, and that the state value is preserved from the initial redirect to the callback. Cookie settings are not relevant for this part of the OAuth flow.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 20, 2025): <!-- Answer --> You're correct—Better Auth does not use cookies to store the OAuth "state" during the flow. Instead, it generates a random state string and stores it in the verifications table in your database. When the OAuth callback happens, Better Auth looks up this state in the database to validate the flow. No cookie is set or expected for this part of the process, so what you observed (no cookie, but a verifications record) is the intended behavior in SvelteKit + adapter-node setups [see source](https://github.com/better-auth/better-auth/blob/99460c6325fef3661bc990826e8ae71933516330/packages/better-auth/src/oauth2/state.ts). If you're seeing "State not found undefined," it means the verification record for that state is missing or expired by the time the callback happens. This can be caused by issues like: the record not being created, being deleted too soon, database connectivity problems, or the state parameter not being passed correctly through the OAuth flow [see source](https://github.com/better-auth/better-auth/blob/99460c6325fef3661bc990826e8ae71933516330/packages/better-auth/src/oauth2/state.ts). Focus your debugging on the database and the state parameter: make sure the verifications table is being written to and read from as expected, and that the state value is preserved from the initial redirect to the callback. Cookie settings are not relevant for this part of the OAuth flow. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/dd610ad0-9cdf-4dce-b938-c7ab9e11c569?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/dd610ad0-9cdf-4dce-b938-c7ab9e11c569?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/dd610ad0-9cdf-4dce-b938-c7ab9e11c569?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/dd610ad0-9cdf-4dce-b938-c7ab9e11c569?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/dd610ad0-9cdf-4dce-b938-c7ab9e11c569?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/dd610ad0-9cdf-4dce-b938-c7ab9e11c569?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/dd610ad0-9cdf-4dce-b938-c7ab9e11c569?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3488)
GiteaMirror commented 2026-03-13 08:45:51 -05:00
Author
Owner
Copy Link

@Judeadeniji commented on GitHub (Jul 20, 2025):

Better Auth stores the OAuth "state" in a cookie at the start of the flow and expects to retrieve it on the callback.

@dosubot After reading this, I tried the OAuth flow again. This time, when the GitHub authorisation page loaded, I opened the app in another tab and checked the cookies in devtools; no cookie was created. At the start of the flow, a record is created in the verifications table, which is what I thought Better Auth would depend on to verify the callback and complete the flow.

I think the issue lies in how your environment variables are set up. I noticed you currently have:

PUBLIC_BETTER_AUTH_URL=http://localhost:8787
PRIVATE_BETTER_AUTH_SECRET=rETiyqEPD9Mduyu5hg9NWfQSQDk8K7sj

However, BetterAuth won’t automatically pick these up due to the prefixes.

Instead, try using:

BETTER_AUTH_URL=http://localhost:5173
BETTER_AUTH_SECRET=rETiyqEPD9Mduyu5hg9NWfQSQDk8K7sj

This way, the environment variables remain private by default in Svelte.

If you do need BETTER_AUTH_URL to be public, you can prefix it with PUBLIC_, but be sure to update your config like this:

import { betterAuth } from "better-auth"
import { env } from '$env/dynamic/public';

export const auth = betterAuth({
  baseURL: env.PUBLIC_BETTER_AUTH_URL,
  // ...
})

Let me know if that helps or if you’re still running into issues.

@Judeadeniji commented on GitHub (Jul 20, 2025): > > Better Auth stores the OAuth "state" in a cookie at the start of the flow and expects to retrieve it on the callback. > > @dosubot After reading this, I tried the OAuth flow again. This time, when the GitHub authorisation page loaded, I opened the app in another tab and checked the cookies in devtools; no cookie was created. At the start of the flow, a record is created in the `verifications` table, which is what I thought Better Auth would depend on to verify the callback and complete the flow. I think the issue lies in how your environment variables are set up. I noticed you currently have: ```properties PUBLIC_BETTER_AUTH_URL=http://localhost:8787 PRIVATE_BETTER_AUTH_SECRET=rETiyqEPD9Mduyu5hg9NWfQSQDk8K7sj ``` However, BetterAuth won’t automatically pick these up due to the prefixes. Instead, try using: ```properties BETTER_AUTH_URL=http://localhost:5173 BETTER_AUTH_SECRET=rETiyqEPD9Mduyu5hg9NWfQSQDk8K7sj ``` This way, the environment variables remain private by default in Svelte. If you do need `BETTER_AUTH_URL` to be public, you can prefix it with `PUBLIC_`, but be sure to update your config like this: ```ts import { betterAuth } from "better-auth" import { env } from '$env/dynamic/public'; export const auth = betterAuth({ baseURL: env.PUBLIC_BETTER_AUTH_URL, // ... }) ``` Let me know if that helps or if you’re still running into issues.
GiteaMirror commented 2026-03-13 08:45:51 -05:00
Author
Owner
Copy Link

@gyenabubakar commented on GitHub (Jul 20, 2025):

@Judeadeniji thanks for taking a look at this. Even after setting baseURL and secret, the problem still occurs.

I should've mentioned this earlier: the authorisation does work, actually. A new record is created in users and accounts tables. But the error page is what is shown on redirect from GitHub, which is what I'm trying to prevent. The account is successfully created, actually. [cc @dosubot]

Clicking on "Return to Application" in the screenshot above takes me to the / route, where I can now see the Sign out button because the auth worked.

If it helps, here's the URLs logged during the flow:

>>> POST http://localhost:8787/api/auth/sign-in/social

>>> GET http://localhost:8787/api/auth/get-session

>>> GET http://localhost:8787/api/auth/callback/github?code=0700ba3be978f880bf1a&state=xPzBDSqh0Njigj5f3f-XvFtQx_PfKBMK

>>> GET http://localhost:8787/api/auth/callback/github

2025-07-20T09:16:46.137Z ERROR [Better Auth]: State not found undefined

>>> GET http://localhost:8787/api/auth/error?error=state_not_found

Notice that after GitHub first redirects to /api/auth/callback/github, the code and state search params are set. Right after that, the callback route is hit again. Except this time, it has no search params. And I suspect that's what is causing the error. If I could just prevent the endpoint from being called the second time, this could resolve my issue. [@dosubot any idea why the endpoint is being called again?]

@Judeadeniji I'm wondering, did you happen to run the app in the reproduction repo with your suggested changes? Did it work for you?

@gyenabubakar commented on GitHub (Jul 20, 2025): @Judeadeniji thanks for taking a look at this. Even after setting `baseURL` and `secret`, the problem still occurs. I should've mentioned this earlier: the authorisation does work, actually. A new record is created in `users` and `accounts` tables. But the error page is what is shown on redirect from GitHub, which is what I'm trying to prevent. The account is successfully created, actually. [cc @dosubot] Clicking on "Return to Application" in the screenshot above takes me to the `/` route, where I can now see the `Sign out` button because the auth worked. If it helps, here's the URLs logged during the flow: ``` >>> POST http://localhost:8787/api/auth/sign-in/social >>> GET http://localhost:8787/api/auth/get-session >>> GET http://localhost:8787/api/auth/callback/github?code=0700ba3be978f880bf1a&state=xPzBDSqh0Njigj5f3f-XvFtQx_PfKBMK >>> GET http://localhost:8787/api/auth/callback/github 2025-07-20T09:16:46.137Z ERROR [Better Auth]: State not found undefined >>> GET http://localhost:8787/api/auth/error?error=state_not_found ``` Notice that after GitHub first redirects to `/api/auth/callback/github`, the `code` and `state` search params are set. Right after that, the callback route is hit again. Except this time, it has no search params. And I suspect that's what is causing the error. If I could just prevent the endpoint from being called the second time, this could resolve my issue. [@dosubot any idea why the endpoint is being called again?] @Judeadeniji I'm wondering, did you happen to run the app in the reproduction repo with your suggested changes? Did it work for you?
GiteaMirror commented 2026-03-13 08:45:52 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 20, 2025):

The second call to /api/auth/callback/github without query parameters (and the resulting "State not found undefined" error) is almost always caused by the callbackURL in your OAuth flow being set to the callback endpoint itself, rather than a user-facing route. After successful authentication, Better Auth redirects to the callbackURL stored in the OAuth state—if this is /api/auth/callback/github, it triggers the endpoint again, but now without the required code and state params, resulting in the error you see.

To fix this, make sure that when you initiate the OAuth flow (e.g., via signInSocial or similar), the callbackURL you provide is a regular application route (like / or /dashboard), not the callback endpoint. The GitHub OAuth app's redirect URI should still point to /api/auth/callback/github, but the callbackURL used in your app's state generation/config must be a user-facing page.

Double-check your Better Auth config, environment variables, and any code that starts the OAuth flow to ensure this. If you want to trace where the callbackURL is being set, add logging at each step of the flow. This should prevent the duplicate invocation and the error page after successful login. For more details, see the callback handler logic and state management.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 20, 2025): <!-- Answer --> The second call to `/api/auth/callback/github` without query parameters (and the resulting "State not found undefined" error) is almost always caused by the callbackURL in your OAuth flow being set to the callback endpoint itself, rather than a user-facing route. After successful authentication, Better Auth redirects to the callbackURL stored in the OAuth state—if this is `/api/auth/callback/github`, it triggers the endpoint again, but now without the required `code` and `state` params, resulting in the error you see. To fix this, make sure that when you initiate the OAuth flow (e.g., via `signInSocial` or similar), the `callbackURL` you provide is a regular application route (like `/` or `/dashboard`), not the callback endpoint. The GitHub OAuth app's redirect URI should still point to `/api/auth/callback/github`, but the callbackURL used in your app's state generation/config must be a user-facing page. Double-check your Better Auth config, environment variables, and any code that starts the OAuth flow to ensure this. If you want to trace where the callbackURL is being set, add logging at each step of the flow. This should prevent the duplicate invocation and the error page after successful login. For more details, see the [callback handler logic](https://github.com/better-auth/better-auth/blob/99460c6325fef3661bc990826e8ae71933516330/packages/better-auth/src/api/routes/callback.ts) and [state management](https://github.com/better-auth/better-auth/blob/99460c6325fef3661bc990826e8ae71933516330/packages/better-auth/src/oauth2/state.ts). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c3d0235a-d516-4f2d-92dd-607ecf7b10da?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c3d0235a-d516-4f2d-92dd-607ecf7b10da?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c3d0235a-d516-4f2d-92dd-607ecf7b10da?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c3d0235a-d516-4f2d-92dd-607ecf7b10da?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c3d0235a-d516-4f2d-92dd-607ecf7b10da?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c3d0235a-d516-4f2d-92dd-607ecf7b10da?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c3d0235a-d516-4f2d-92dd-607ecf7b10da?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3488)
GiteaMirror commented 2026-03-13 08:45:53 -05:00
Author
Owner
Copy Link

@gyenabubakar commented on GitHub (Jul 20, 2025):

Yeah that fixes it. In my env I had:

PUBLIC_GITHUB_CALLBACK_URL=http://localhost:8787/api/auth/callback/github

...and was doing this:

AUTH_CLIENT.signIn.social({
   provider: 'github',
   callbackURL: PUBLIC_GITHUB_CALLBACK_URL
});

Removing callbackURL or updating the env:

PUBLIC_GITHUB_CALLBACK_URL=http://localhost:8787/

...fixed it.

@gyenabubakar commented on GitHub (Jul 20, 2025): Yeah that fixes it. In my env I had: ``` PUBLIC_GITHUB_CALLBACK_URL=http://localhost:8787/api/auth/callback/github ``` ...and was doing this: ```ts AUTH_CLIENT.signIn.social({ provider: 'github', callbackURL: PUBLIC_GITHUB_CALLBACK_URL }); ``` Removing `callbackURL` or updating the env: ``` PUBLIC_GITHUB_CALLBACK_URL=http://localhost:8787/ ``` ...fixed it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label bug svelte
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1534
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?