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

[GH-ISSUE #4584] The return value of auth.api.getSession has a type issue. #9988

New Issue
Closed
opened 2026-04-13 05:51:00 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-13 05:51:00 -05:00
Owner
Copy Link

Originally created by @mlhiter on GitHub (Sep 11, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4584

Originally assigned to: @Bekacru on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Image When I use auth.api.getSession, its return type is { session:unknown user: unknown }

Current vs. Expected behavior

I don't know why, because I use this in my previous project(next 14.0.3) and it work.
But for my new project it is not work.
Some system info:
"better-auth": "^1.3.9",
"next": "15.5.2",

What version of Better Auth are you using?

1.3.9

System info

npx @better-auth/cli info --json
{
  "system": {
    "platform": "darwin",
    "arch": "arm64",
    "version": "Darwin Kernel Version 24.6.0: Mon Jul 14 11:28:30 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6030",
    "release": "24.6.0",
    "cpuCount": 12,
    "cpuModel": "Apple M3 Pro",
    "totalMemory": "18.00 GB",
    "freeMemory": "0.14 GB"
  },
  "node": {
    "version": "v24.5.0",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "11.5.1"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "15.5.2"
    },
    {
      "name": "react",
      "version": "19.1.0"
    }
  ],
  "databases": [
    {
      "name": "@prisma/client",
      "version": "^6.16.0"
    }
  ],
  "betterAuth": {
    "version": "0.1.0",
    "config": {
      "appName": "jotlin",
      "plugins": [],
      "socialProviders": {
        "github": {
          "clientId": "[REDACTED]",
          "clientSecret": "[REDACTED]"
        }
      }
    }
  }
}

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

Types

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

No response

Originally created by @mlhiter on GitHub (Sep 11, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4584 Originally assigned to: @Bekacru on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce <img width="1802" height="1334" alt="Image" src="https://github.com/user-attachments/assets/e0d2128f-fe34-47f2-9189-9f446a19fe56" /> When I use auth.api.getSession, its return type is { session:unknown user: unknown } ### Current vs. Expected behavior I don't know why, because I use this in my previous project(next 14.0.3) and it work. But for my new project it is not work. Some system info: "better-auth": "^1.3.9", "next": "15.5.2", ### What version of Better Auth are you using? 1.3.9 ### System info ```bash npx @better-auth/cli info --json { "system": { "platform": "darwin", "arch": "arm64", "version": "Darwin Kernel Version 24.6.0: Mon Jul 14 11:28:30 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6030", "release": "24.6.0", "cpuCount": 12, "cpuModel": "Apple M3 Pro", "totalMemory": "18.00 GB", "freeMemory": "0.14 GB" }, "node": { "version": "v24.5.0", "env": "development" }, "packageManager": { "name": "npm", "version": "11.5.1" }, "frameworks": [ { "name": "next", "version": "15.5.2" }, { "name": "react", "version": "19.1.0" } ], "databases": [ { "name": "@prisma/client", "version": "^6.16.0" } ], "betterAuth": { "version": "0.1.0", "config": { "appName": "jotlin", "plugins": [], "socialProviders": { "github": { "clientId": "[REDACTED]", "clientSecret": "[REDACTED]" } } } } } ``` ### Which area(s) are affected? (Select all that apply) Types ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context _No response_
GiteaMirror added the locked label 2026-04-13 05:51:00 -05:00
GiteaMirror commented 2026-04-13 05:51:02 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 11, 2025):

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

This is a known type inference issue in Better Auth v1.3.x: when using auth.api.getSession, TypeScript sometimes infers { session: unknown, user: unknown } due to incomplete type propagation, especially if you use options like returnHeaders or if your config/plugins affect type inference. This is not specific to your setup—others have reported the same problem in recent versions as well.

A common workaround is to use the asResponse option and then cast the result to the correct type using your inferred session type, like this:

const response = await auth.api.getSession({ headers, asResponse: true });
const { session, user } = (await response.json()) as typeof auth.$Infer.Session;

This approach ensures you get proper types for session and user even if the direct call returns unknown types. More details and discussion are available here.

If you’re not using asResponse, double-check that your Better Auth config and usage match the latest docs, and that you’re not missing any generics or explicit type parameters. If you’re using server components or cross-origin setups, also review your cookie and header handling, as that can affect both runtime and type inference (reference).

To reply, just mention @dosu.

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

<!-- gh-comment-id:3281074859 --> @dosubot[bot] commented on GitHub (Sep 11, 2025): <!-- Greeting --> Hi @mlhiter! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This is a known type inference issue in Better Auth v1.3.x: when using `auth.api.getSession`, TypeScript sometimes infers `{ session: unknown, user: unknown }` due to incomplete type propagation, especially if you use options like `returnHeaders` or if your config/plugins affect type inference. This is not specific to your setup—others have reported the same problem in recent versions as well. A common workaround is to use the `asResponse` option and then cast the result to the correct type using your inferred session type, like this: ```ts const response = await auth.api.getSession({ headers, asResponse: true }); const { session, user } = (await response.json()) as typeof auth.$Infer.Session; ``` This approach ensures you get proper types for `session` and `user` even if the direct call returns `unknown` types. More details and discussion are available [here](https://github.com/better-auth/better-auth/issues/3780). If you’re not using `asResponse`, double-check that your Better Auth config and usage match the latest docs, and that you’re not missing any generics or explicit type parameters. If you’re using server components or cross-origin setups, also review your cookie and header handling, as that can affect both runtime and type inference ([reference](https://github.com/better-auth/better-auth/issues/4188)). <!-- 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/3cc63e0b-1bbf-4347-9b41-589b69af7957?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3cc63e0b-1bbf-4347-9b41-589b69af7957?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3cc63e0b-1bbf-4347-9b41-589b69af7957?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3cc63e0b-1bbf-4347-9b41-589b69af7957?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3cc63e0b-1bbf-4347-9b41-589b69af7957?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3cc63e0b-1bbf-4347-9b41-589b69af7957?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3cc63e0b-1bbf-4347-9b41-589b69af7957?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&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/4584)
GiteaMirror commented 2026-04-13 05:51:03 -05:00
Author
Owner
Copy Link

@mlhiter commented on GitHub (Sep 11, 2025):

Robot solution is not work. And I just follow the doc to encounter this issue.

.

<!-- gh-comment-id:3281129241 --> @mlhiter commented on GitHub (Sep 11, 2025): Robot solution is not work. And I just follow the doc to encounter this issue. .
GiteaMirror commented 2026-04-13 05:51:05 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 11, 2025):

This type inference issue is a known problem in Better Auth, especially in recent versions and with certain setups. The root cause is that TypeScript can't always infer the correct types for session and user from your config, so it falls back to unknown—even if you follow the docs. This happens because the generics from your betterAuth() config aren't always propagated through to the API endpoints, especially if you use plugins or custom fields, or if your config isn't explicitly typed. There are also two conflicting type definitions for getSession in the codebase, which can override the correct typing and cause this exact issue (details).

Workarounds that have helped others include:

  • Using type assertions or manually casting the return type when calling getSession.
  • If you use custom user fields, make sure to add them to your server config under user.additionalFields and use inferAdditionalFields<typeof auth>() in your client config (example).
  • If you use the asResponse option, cast the result to typeof auth.$Infer.Session after calling .json(), but this doesn't always work for everyone.

Also, make sure you have zod installed as a dependency—missing it can cause types to resolve as any or unknown in some setups (see this note).

If none of these work, the issue is likely due to how generics are wired through your config and the Better Auth API. There isn't a universal fix yet, but you can safely cast the result to the expected type as a workaround. If you have custom plugins or fields, double-check that they're typed correctly and registered in both server and client configs.

If you want to share a minimal reproducible example (your config and usage), I can help spot if anything is missing that would help TypeScript infer the types correctly.

To reply, just mention @dosu.

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

<!-- gh-comment-id:3281162388 --> @dosubot[bot] commented on GitHub (Sep 11, 2025): <!-- Answer --> This type inference issue is a known problem in Better Auth, especially in recent versions and with certain setups. The root cause is that TypeScript can't always infer the correct types for `session` and `user` from your config, so it falls back to `unknown`—even if you follow the docs. This happens because the generics from your `betterAuth()` config aren't always propagated through to the API endpoints, especially if you use plugins or custom fields, or if your config isn't explicitly typed. There are also two conflicting type definitions for `getSession` in the codebase, which can override the correct typing and cause this exact issue [(details)](https://github.com/better-auth/better-auth/issues/3780). Workarounds that have helped others include: - Using type assertions or manually casting the return type when calling `getSession`. - If you use custom user fields, make sure to add them to your server config under `user.additionalFields` and use `inferAdditionalFields<typeof auth>()` in your client config [(example)](https://github.com/better-auth/better-auth/issues/1245). - If you use the `asResponse` option, cast the result to `typeof auth.$Infer.Session` after calling `.json()`, but this doesn't always work for everyone. Also, make sure you have `zod` installed as a dependency—missing it can cause types to resolve as `any` or `unknown` in some setups [(see this note)](https://github.com/better-auth/better-auth/issues/3780). If none of these work, the issue is likely due to how generics are wired through your config and the Better Auth API. There isn't a universal fix yet, but you can safely cast the result to the expected type as a workaround. If you have custom plugins or fields, double-check that they're typed correctly and registered in both server and client configs. If you want to share a minimal reproducible example (your config and usage), I can help spot if anything is missing that would help TypeScript infer the types correctly. <!-- 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/073a8787-5d6e-4393-b816-fafa829cc3a3?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/073a8787-5d6e-4393-b816-fafa829cc3a3?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/073a8787-5d6e-4393-b816-fafa829cc3a3?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/073a8787-5d6e-4393-b816-fafa829cc3a3?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/073a8787-5d6e-4393-b816-fafa829cc3a3?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/073a8787-5d6e-4393-b816-fafa829cc3a3?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/073a8787-5d6e-4393-b816-fafa829cc3a3?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&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/4584)
GiteaMirror commented 2026-04-13 05:51:06 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 11, 2025):

I might take a look, thanks for feedback

<!-- gh-comment-id:3282438978 --> @himself65 commented on GitHub (Sep 11, 2025): I might take a look, thanks for feedback
GiteaMirror commented 2026-04-13 05:51:06 -05:00
Author
Owner
Copy Link

@mlhiter commented on GitHub (Sep 15, 2025):

@himself65 any process and do you need me to provide more context?

<!-- gh-comment-id:3290305896 --> @mlhiter commented on GitHub (Sep 15, 2025): @himself65 any process and do you need me to provide more context?
GiteaMirror commented 2026-04-13 05:51:07 -05:00
Author
Owner
Copy Link

@timheerwagen commented on GitHub (Sep 24, 2025):

I encountered a similar bug in version 1.3.16, for which I had to use the workaround of inferring types from auth.api.getSession: https://github.com/better-auth/better-auth/issues/4875.

export type ServerSession = Awaited<ReturnType<typeof auth.api.getSession>>;

This worked in version 1.3.5, but it throws an error in the latest version.

<!-- gh-comment-id:3328508822 --> @timheerwagen commented on GitHub (Sep 24, 2025): I encountered a similar bug in version `1.3.16`, for which I had to use the workaround of inferring types from auth.api.getSession: https://github.com/better-auth/better-auth/issues/4875. ```ts export type ServerSession = Awaited<ReturnType<typeof auth.api.getSession>>; ``` This worked in version `1.3.5`, but it throws an error in the latest version.
GiteaMirror commented 2026-04-13 05:51:07 -05:00
Author
Owner
Copy Link

@flocarle commented on GitHub (Sep 26, 2025):

To contribute to this issue, I think the bug was introduced in version 1.3.13. I was using 1.3.9 but had to upgrade because of an expo issue. I upgraded to the latest but suddenly user inside Session was not being inferred correctly. Started downgrading versions until I got it right again and that was in version 1.3.12.

Looking at the changelog, I think the bug might have been introduced by the feature Add returnHeaders to getSession

<!-- gh-comment-id:3338205025 --> @flocarle commented on GitHub (Sep 26, 2025): To contribute to this issue, I think the bug was introduced in version `1.3.13`. I was using `1.3.9` but had to upgrade because of an expo issue. I upgraded to the latest but suddenly `user` inside `Session` was not being inferred correctly. Started downgrading versions until I got it right again and that was in version `1.3.12`. Looking at the changelog, I think the bug might have been introduced by the feature `Add returnHeaders to getSession`
GiteaMirror commented 2026-04-13 05:51:08 -05:00
Author
Owner
Copy Link

@enisze commented on GitHub (Sep 26, 2025):

hey guys I'm also concerned about the types. How can I properly share client and server types properly? Especially, when I customize?

<!-- gh-comment-id:3338816212 --> @enisze commented on GitHub (Sep 26, 2025): hey guys I'm also concerned about the types. How can I properly share client and server types properly? Especially, when I customize?
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 locked
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#9988
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?