github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-22 14:21:55 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #4490] [BUG] multiSession: listDeviceSessions() only returns 2 sessions when maximumSessions: 3 #9954

New Issue
Closed
opened 2026-04-13 05:48:30 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-13 05:48:30 -05:00
Owner
Copy Link

Originally created by @Maxime-RiseVerse on GitHub (Sep 6, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4490

Originally assigned to: @Paola3stefania on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Configure multiSession with maximumSessions: 3
  2. Login with Account A
  3. Login with Account B
  4. Login with Account C (currently active)
  5. Call listDeviceSessions() → Returns only 2 sessions (A and B, not the active C)
  6. Switch to Account A using multiSession.setActive()
  7. Call listDeviceSessions() → Still only 2 sessions (Account C disappeared)

Current vs. Expected behavior

Current behavior:

  • I have 3 accounts logged in
  • listDeviceSessions() only returns 2 accounts
  • The currently active account is missing from the list

Expected behavior:

  • I have 3 accounts logged in
  • listDeviceSessions() should return all 3 accounts
  • All logged-in sessions should be visible in the list

Note: All 3 sessions exist in the database, but the API only returns 2.

Workaround: Setting maximumSessions: 4 allows 3 accounts to work correctly.

What version of Better Auth are you using?

1.3.8

System info

{
  "system": {
    "platform": "win32",
    "arch": "x64",
    "version": "Windows 11 Pro",
    "release": "10.0.26100",
    "cpuCount": 16,
    "cpuModel": "Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz",
    "totalMemory": "31.88 GB",
    "freeMemory": "6.50 GB"
  },
  "node": {
    "version": "v22.14.0",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "10.9.2"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "15.5.2"
    },
    {
      "name": "react",
      "version": "19.1.1"
    }
  ],
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    },
    {
      "name": "drizzle",
      "version": "^0.44.5"
    }
  ],
  "betterAuth": {
    "version": "0.1.0",
    "config": null
  }
}

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

Backend

Auth config (if applicable)

import { betterAuth } from 'better-auth';
  import { drizzleAdapter } from
  'better-auth/adapters/drizzle';
  import { emailOTP, multiSession, organization
   } from 'better-auth/plugins';
  import { db } from '@/lib/db';
  import {
    account,
    invitation,
    member,
    organization as organizationTable,
    session,
    user,
    verification,
  } from '@/lib/db/schema';

  export const auth = betterAuth({
    database: drizzleAdapter(db, {
      provider: 'pg',
      schema: {
        user,
        session,
        account,
        verification,
        organization: organizationTable,
        member,
        invitation,
      },
      usePlural: false,
    }),
    emailAndPassword: {
      enabled: true,
      requireEmailVerification: true,
    },
    plugins: [
      multiSession({
        maximumSessions: 3,
      }),
      organization({
        organizationLimit: 5,
      }),
      emailOTP({
        sendVerificationOnSignUp: false,
      }),
    ],
    secret: process.env.BETTER_AUTH_SECRET,
    trustedOrigins:
  [process.env.BETTER_AUTH_URL ||
  'http://localhost:3000'],
  });

Additional context

The issue happens locally. All 3 sessions remain valid in the database, but listDeviceSessions() API call only returns 2.

Originally created by @Maxime-RiseVerse on GitHub (Sep 6, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4490 Originally assigned to: @Paola3stefania on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1. Configure multiSession with maximumSessions: 3 2. Login with Account A 3. Login with Account B 4. Login with Account C (currently active) 5. Call listDeviceSessions() → Returns only 2 sessions (A and B, not the active C) 6. Switch to Account A using multiSession.setActive() 7. Call listDeviceSessions() → Still only 2 sessions (Account C disappeared) ### Current vs. Expected behavior Current behavior: - I have 3 accounts logged in - listDeviceSessions() only returns 2 accounts - The currently active account is missing from the list Expected behavior: - I have 3 accounts logged in - listDeviceSessions() should return all 3 accounts - All logged-in sessions should be visible in the list Note: All 3 sessions exist in the database, but the API only returns 2. Workaround: Setting maximumSessions: 4 allows 3 accounts to work correctly. ### What version of Better Auth are you using? 1.3.8 ### System info ```bash { "system": { "platform": "win32", "arch": "x64", "version": "Windows 11 Pro", "release": "10.0.26100", "cpuCount": 16, "cpuModel": "Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz", "totalMemory": "31.88 GB", "freeMemory": "6.50 GB" }, "node": { "version": "v22.14.0", "env": "development" }, "packageManager": { "name": "npm", "version": "10.9.2" }, "frameworks": [ { "name": "next", "version": "15.5.2" }, { "name": "react", "version": "19.1.1" } ], "databases": [ { "name": "pg", "version": "^8.16.3" }, { "name": "drizzle", "version": "^0.44.5" } ], "betterAuth": { "version": "0.1.0", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from 'better-auth'; import { drizzleAdapter } from 'better-auth/adapters/drizzle'; import { emailOTP, multiSession, organization } from 'better-auth/plugins'; import { db } from '@/lib/db'; import { account, invitation, member, organization as organizationTable, session, user, verification, } from '@/lib/db/schema'; export const auth = betterAuth({ database: drizzleAdapter(db, { provider: 'pg', schema: { user, session, account, verification, organization: organizationTable, member, invitation, }, usePlural: false, }), emailAndPassword: { enabled: true, requireEmailVerification: true, }, plugins: [ multiSession({ maximumSessions: 3, }), organization({ organizationLimit: 5, }), emailOTP({ sendVerificationOnSignUp: false, }), ], secret: process.env.BETTER_AUTH_SECRET, trustedOrigins: [process.env.BETTER_AUTH_URL || 'http://localhost:3000'], }); ``` ### Additional context The issue happens locally. All 3 sessions remain valid in the database, but listDeviceSessions() API call only returns 2.
GiteaMirror added the lockedbug labels 2026-04-13 05:48:30 -05:00
GiteaMirror commented 2026-04-13 05:48:32 -05:00
Author
Owner
Copy Link

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

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

This looks like a bug in the multiSession plugin's session listing logic. The implementation of listDeviceSessions() only returns one session per user by filtering for unique user IDs, so if you have multiple sessions for the same user, only one will show up—even if all sessions exist in the database. This can cause the active session to be missing from the list if it gets filtered out by this logic. The maximumSessions setting only limits the number of multi-session cookies, not the number of sessions returned by the API. Setting maximumSessions: 4 works as a workaround because it allows an extra cookie, but the underlying filtering logic is still the cause of the issue. See source.

There’s no official documentation or known workaround for this behavior, but you could try mutating the response using the customSession plugin with shouldMutateListDeviceSessionsEndpoint: true if you need more control over the returned sessions. See PR #3868.

If you need all sessions to be listed, you’ll likely need to adjust the filtering logic in your local copy or wait for an upstream fix.

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:3263217029 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Greeting --> Hi @Maxime-RiseVerse! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This looks like a bug in the multiSession plugin's session listing logic. The implementation of `listDeviceSessions()` only returns one session per user by filtering for unique user IDs, so if you have multiple sessions for the same user, only one will show up—even if all sessions exist in the database. This can cause the active session to be missing from the list if it gets filtered out by this logic. The `maximumSessions` setting only limits the number of multi-session cookies, not the number of sessions returned by the API. Setting `maximumSessions: 4` works as a workaround because it allows an extra cookie, but the underlying filtering logic is still the cause of the issue. [See source](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/packages/better-auth/src/plugins/multi-session/index.ts). There’s no official documentation or known workaround for this behavior, but you could try mutating the response using the `customSession` plugin with `shouldMutateListDeviceSessionsEndpoint: true` if you need more control over the returned sessions. [See PR #3868](https://github.com/better-auth/better-auth/pull/3868). If you need all sessions to be listed, you’ll likely need to adjust the filtering logic in your local copy or wait for an upstream fix. <!-- 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/2a677551-12bb-4b5d-be8e-dc487ea86c27?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/2a677551-12bb-4b5d-be8e-dc487ea86c27?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/2a677551-12bb-4b5d-be8e-dc487ea86c27?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/2a677551-12bb-4b5d-be8e-dc487ea86c27?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/2a677551-12bb-4b5d-be8e-dc487ea86c27?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/2a677551-12bb-4b5d-be8e-dc487ea86c27?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/2a677551-12bb-4b5d-be8e-dc487ea86c27?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/4490)
GiteaMirror commented 2026-04-13 05:48:32 -05:00
Author
Owner
Copy Link

@Maxime-RiseVerse commented on GitHub (Sep 6, 2025):

@dosu Thanks for the response, but I think
you misunderstood the issue. I'm not using
multiple sessions for the same user - I have
3 completely different user accounts
(different emails and user IDs).

After debugging and reviewing the source
code, I found the actual bug is in the after
hook (line ~290) that creates multi-session
cookies:

const currentMultiSessions =
    Object.keys(Object.fromEntries(cookies)).
filter(isMultiSessionCookie).length
    + (cookieString.includes("session_token")
 ? 1 : 0);

if (currentMultiSessions >=
opts.maximumSessions) {
    return; // Bug: prevents creating the 3rd
 multi-session cookie
}

With maximumSessions: 3:
- Login Account A → Creates _multi- cookie (0
 + 1 = 1 < 3) ✅
- Login Account B → Creates _multi- cookie (1
 + 1 = 2 < 3) ✅
- Login Account C → NO _multi- cookie (2 + 1
= 3 >= 3) ❌

Account C only gets the active session
cookie, no _multi- cookie. When I switch away
 from Account C, it disappears because it has
 no _multi- cookie to preserve it.

My debug logs confirm this - I only have 2
_multi- cookies for 3 logged-in accounts.

The workaround maximumSessions: 4 works
because it allows the 3rd _multi- cookie to
be created. The fix would be to adjust the
counting logic to properly allow
maximumSessions number of accounts.

This clearly explains the bug is in cookie
creation during login, not in the session
listing logic.
<!-- gh-comment-id:3263231706 --> @Maxime-RiseVerse commented on GitHub (Sep 6, 2025): @dosu Thanks for the response, but I think you misunderstood the issue. I'm not using multiple sessions for the same user - I have 3 completely different user accounts (different emails and user IDs). After debugging and reviewing the source code, I found the actual bug is in the after hook (line ~290) that creates multi-session cookies: ```typescript const currentMultiSessions = Object.keys(Object.fromEntries(cookies)). filter(isMultiSessionCookie).length + (cookieString.includes("session_token") ? 1 : 0); if (currentMultiSessions >= opts.maximumSessions) { return; // Bug: prevents creating the 3rd multi-session cookie } With maximumSessions: 3: - Login Account A → Creates _multi- cookie (0 + 1 = 1 < 3) ✅ - Login Account B → Creates _multi- cookie (1 + 1 = 2 < 3) ✅ - Login Account C → NO _multi- cookie (2 + 1 = 3 >= 3) ❌ Account C only gets the active session cookie, no _multi- cookie. When I switch away from Account C, it disappears because it has no _multi- cookie to preserve it. My debug logs confirm this - I only have 2 _multi- cookies for 3 logged-in accounts. The workaround maximumSessions: 4 works because it allows the 3rd _multi- cookie to be created. The fix would be to adjust the counting logic to properly allow maximumSessions number of accounts. This clearly explains the bug is in cookie creation during login, not in the session listing logic.
GiteaMirror commented 2026-04-13 05:48:33 -05:00
Author
Owner
Copy Link

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

You're absolutely right—the bug is in the multi-session cookie creation logic, not the session listing. The after hook in the multiSession plugin counts the current sessions like this:

const currentMultiSessions =
  Object.keys(Object.fromEntries(cookies)).filter(isMultiSessionCookie).length
  + (cookieString.includes("session_token") ? 1 : 0);

if (currentMultiSessions >= opts.maximumSessions) {
  return;
}

This causes an off-by-one error: when maximumSessions is 3, only 2 _multi- cookies are created, so the third account never gets a persistent multi-session cookie. That's why your workaround (setting maximumSessions: 4) works, but it's not the intended behavior. The bug is confirmed in the current codebase and hasn't been addressed in any recent PRs or docs [source].

To fix this, the counting logic should be adjusted so that the number of persistent multi-session cookies matches maximumSessions. For example, you could remove the + (cookieString.includes("session_token") ? 1 : 0) part, or refactor the logic to only count unique sessions.

Until this is fixed upstream, your workaround is the only way to ensure all sessions are preserved. This bug could affect any scenario where users expect to have the full number of concurrent sessions allowed by maximumSessions, regardless of browser or device.

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:3263232395 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> You're absolutely right—the bug is in the multi-session cookie creation logic, not the session listing. The after hook in the multiSession plugin counts the current sessions like this: ```typescript const currentMultiSessions = Object.keys(Object.fromEntries(cookies)).filter(isMultiSessionCookie).length + (cookieString.includes("session_token") ? 1 : 0); if (currentMultiSessions >= opts.maximumSessions) { return; } ``` This causes an off-by-one error: when maximumSessions is 3, only 2 `_multi-` cookies are created, so the third account never gets a persistent multi-session cookie. That's why your workaround (setting maximumSessions: 4) works, but it's not the intended behavior. The bug is confirmed in the current codebase and hasn't been addressed in any recent PRs or docs [[source]](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/packages/better-auth/src/plugins/multi-session/index.ts). To fix this, the counting logic should be adjusted so that the number of persistent multi-session cookies matches maximumSessions. For example, you could remove the `+ (cookieString.includes("session_token") ? 1 : 0)` part, or refactor the logic to only count unique sessions. Until this is fixed upstream, your workaround is the only way to ensure all sessions are preserved. This bug could affect any scenario where users expect to have the full number of concurrent sessions allowed by maximumSessions, regardless of browser or device. <!-- 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/cedd3330-6b1f-4dd1-84f3-fe00a534cb2f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/cedd3330-6b1f-4dd1-84f3-fe00a534cb2f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/cedd3330-6b1f-4dd1-84f3-fe00a534cb2f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/cedd3330-6b1f-4dd1-84f3-fe00a534cb2f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/cedd3330-6b1f-4dd1-84f3-fe00a534cb2f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/cedd3330-6b1f-4dd1-84f3-fe00a534cb2f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/cedd3330-6b1f-4dd1-84f3-fe00a534cb2f?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/4490)
GiteaMirror commented 2026-04-13 05:48:33 -05:00
Author
Owner
Copy Link

@Maxime-RiseVerse commented on GitHub (Dec 3, 2025):

@dosu This bug is still present on current version. Has there been any PR to fix this? The suggested fix is straightforward - changing >= to > in the comparison.

<!-- gh-comment-id:3607368100 --> @Maxime-RiseVerse commented on GitHub (Dec 3, 2025): @dosu This bug is still present on current version. Has there been any PR to fix this? The suggested fix is straightforward - changing >= to > in the comparison.
GiteaMirror commented 2026-04-13 05:48:34 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Dec 3, 2025):

There hasn't been any PR that implements the fix of changing >= to > in the multi-session cookie counting logic. The closest related PR is #6248, which addresses duplicate cookies for the same account and includes improvements to session counting to avoid off-by-one errors, but it does not explicitly fix or mention the bug you're describing or the suggested comparison change. The problematic logic is still present in the current version, and your suggested fix has not been merged or discussed in any PRs so far. The issue remains unresolved—continuing to use your workaround or monitoring for updates is the best option for now.
See PR #6248 for details

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

<!-- gh-comment-id:3607376262 --> @dosubot[bot] commented on GitHub (Dec 3, 2025): <!-- Answer --> There hasn't been any PR that implements the fix of changing >= to > in the multi-session cookie counting logic. The closest related PR is #6248, which addresses duplicate cookies for the same account and includes improvements to session counting to avoid off-by-one errors, but it does not explicitly fix or mention the bug you're describing or the suggested comparison change. The problematic logic is still present in the current version, and your suggested fix has not been merged or discussed in any PRs so far. The issue remains unresolved—continuing to use your workaround or monitoring for updates is the best option for now. [See PR #6248 for details](https://github.com/better-auth/better-auth/pull/6248) <!-- 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/f45924b0-3ad0-478d-9156-74e976f6bffb?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/f45924b0-3ad0-478d-9156-74e976f6bffb?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/f45924b0-3ad0-478d-9156-74e976f6bffb?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/f45924b0-3ad0-478d-9156-74e976f6bffb?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f45924b0-3ad0-478d-9156-74e976f6bffb?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/f45924b0-3ad0-478d-9156-74e976f6bffb?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/f45924b0-3ad0-478d-9156-74e976f6bffb?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=There%20hasn%27t%20been%20any%20PR%20that%20implements%20the%20fix%20of%20changing%20%3E%3D%20to%20%3E%20in%20the%20multi-session%20cookie%20counting%20logic.%20The%20closest%20related%20PR%20is%20%236248%2C%20which%20addresses%20duplicate%20cookies%20for%20the%20same%20account%20and%20includes%20improvements%20to%20session%20counting%20to%20avoid%20off-by-one%20errors%2C%20but%20it%20does%20not%20explicitly%20fix%20or%20mention%20the%20bug%20you%27re%20describing%20or%20the%20suggested%20comparison%20change.%20The%20problematic%20logic%20is%20still%20present%20in%20the%20current%20version%2C%20and%20your%20suggested%20fix%20has%20not%20been%20merged%20or%20discussed%20in%20any%20PRs%20so%20far.%20The%20issue%20remains%20unresolved%E2%80%94continuing%20to%20use%20your%20workaround%20or%20monitoring%20for%20updates%20is%20the%20best%20option%20for%20now.%20%20%0A%5BSee%20PR%20%236248%20for%20details%5D%28https%3A//github.com/better-auth/better-auth/pull/6248%29)&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/4490)
GiteaMirror commented 2026-04-13 05:48:34 -05:00
Author
Owner
Copy Link

@Maxime-RiseVerse commented on GitHub (Dec 3, 2025):

This bug is still present in the latest version. I've done a deep dive into the source code and confirmed the root cause: File: packages/better-auth/src/plugins/multi-session/index.ts (lines ~306-310)

const currentMultiSessions = Object.keys(Object.fromEntries(cookies))
  .filter(isMultiSessionCookie).length
  + (cookieString.includes("session_token") ? 1 : 0);

if (currentMultiSessions >= opts.maximumSessions) {  // Bug: should be >
  return;
}

The fix is a one-character change: >= → > I'd be happy to submit a PR if a maintainer can confirm this is the right approach. Note: PR #6248 touches the same file but addresses a different issue (duplicate cookies for same account). This fix could potentially be included there, or submitted separately.

<!-- gh-comment-id:3607402811 --> @Maxime-RiseVerse commented on GitHub (Dec 3, 2025): This bug is still present in the latest version. I've done a deep dive into the source code and confirmed the root cause: File: packages/better-auth/src/plugins/multi-session/index.ts (lines ~306-310) ``` const currentMultiSessions = Object.keys(Object.fromEntries(cookies)) .filter(isMultiSessionCookie).length + (cookieString.includes("session_token") ? 1 : 0); if (currentMultiSessions >= opts.maximumSessions) { // Bug: should be > return; } ``` The fix is a one-character change: >= → > I'd be happy to submit a PR if a maintainer can confirm this is the right approach. Note: PR #6248 touches the same file but addresses a different issue (duplicate cookies for same account). This fix could potentially be included there, or submitted separately.
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 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#9954
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?