toNextJsHandler causes file scan outside project directory leading to EPERM on Windows during next build #1581

Closed
opened 2026-03-13 08:49:52 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @r2desen on GitHub (Jul 26, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

toNextJsHandler causes file scan outside project directory leading to EPERM on Windows during next build
When using Next.js 15.4.4 on Windows, calling the function toNextJsHandler(auth) from the better-auth/next-js package in a route handler (e.g. src/app/api/auth/[...all]/route.ts) causes the Next.js production build (next build) to fail with a permission error (EPERM).

The error occurs because internally toNextJsHandler triggers a file scan (using glob or similar) that recursively scans directories starting from the current working directory (process.cwd()) without restricting the scope to the project folder. This results in the build process attempting to read protected system folders like C:\Users\ronny\Ambiente de Rede, causing the error:

css
Copiar
Editar
glob error [Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede'] {
errno: -4048,
code: 'EPERM',
syscall: 'scandir',
path: 'C:\Users\ronny\Ambiente de Rede'
}
Failed to compile.

Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede'
Steps to reproduce
Create a Next.js project on Windows with Next.js v15.4.4

Install better-auth package (v1.3.1)

Create the file src/app/api/auth/[...all]/route.ts containing:

ts
Copiar
Editar
import { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";

export const { POST, GET } = toNextJsHandler(auth);
Run pnpm build (or npm run build)

Expected behavior
The build process should only scan files within the project directory (e.g., under src/ or the Next.js project root) and should not attempt to read directories outside of the project root, especially system or user profile folders.

Actual behavior
The file scan triggered by toNextJsHandler is too broad and attempts to read protected directories under the user profile (C:\Users\ronny...), causing a permissions error and failing the build.

Workarounds attempted
Commenting out the toNextJsHandler line allows the build to succeed.

Adding custom watchOptions.ignored rules in next.config.ts does not prevent the glob from scanning outside the project.

The error persists even with no Tailwind CSS or global CSS imports.

Suggested fix
Restrict the glob / file scanning patterns inside toNextJsHandler (or the underlying file scan logic) to be limited to the project directory, for example by:

Using a base directory such as path.join(process.cwd(), 'src') as root for scans

Adding options to exclude system or user folders

Handling permission errors gracefully without failing the entire build

Environment
Windows 10

Node.js version: (e.g., v20.x)

Next.js: 15.4.4

better-auth: 1.3.1

Package manager: pnpm

Logs
css
Copiar
Editar

users-betterauth@0.1.0 build D:\dev\nextjs\users-betterauth
next build

▲ Next.js 15.4.4

  • Environments: .env

Creating an optimized production build ...
glob error [Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede'] {
errno: -4048,
code: 'EPERM',
syscall: 'scandir',
path: 'C:\Users\ronny\Ambiente de Rede'
}
Failed to compile.

Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede'

Build failed because of webpack errors

Current vs. Expected behavior

Expected behavior
The build process should only scan files within the project directory (e.g., under src/ or the Next.js project root) and should not attempt to read directories outside of the project root, especially system or user profile folders.

Actual behavior
The file scan triggered by toNextJsHandler is too broad and attempts to read protected directories under the user profile (C:\Users\ronny...), causing a permissions error and failing the build.

What version of Better Auth are you using?

1.3.1

Provide environment information

Windows 10/11

Node.js version: (e.g., v20.x)

Next.js: 15.4.4

better-auth: 1.3.1

Package manager: pnpm

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

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth";
import { prismaAdapter } from "better-auth/adapters/prisma";
import prisma from "@/lib/prisma";

export const auth = betterAuth({
  database: prismaAdapter(prisma, {
    provider: "postgresql",
  }),
  emailAndPassword: {
    enabled: true,
  },
});

Additional context

No response

Originally created by @r2desen on GitHub (Jul 26, 2025). ### Is this suited for github? - [ ] Yes, this is suited for github ### To Reproduce toNextJsHandler causes file scan outside project directory leading to EPERM on Windows during next build When using Next.js 15.4.4 on Windows, calling the function toNextJsHandler(auth) from the better-auth/next-js package in a route handler (e.g. src/app/api/auth/[...all]/route.ts) causes the Next.js production build (next build) to fail with a permission error (EPERM). The error occurs because internally toNextJsHandler triggers a file scan (using glob or similar) that recursively scans directories starting from the current working directory (process.cwd()) without restricting the scope to the project folder. This results in the build process attempting to read protected system folders like C:\Users\ronny\Ambiente de Rede, causing the error: css Copiar Editar glob error [Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede'] { errno: -4048, code: 'EPERM', syscall: 'scandir', path: 'C:\\Users\\ronny\\Ambiente de Rede' } Failed to compile. Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede' Steps to reproduce Create a Next.js project on Windows with Next.js v15.4.4 Install better-auth package (v1.3.1) Create the file src/app/api/auth/[...all]/route.ts containing: ts Copiar Editar import { auth } from "@/lib/auth"; import { toNextJsHandler } from "better-auth/next-js"; export const { POST, GET } = toNextJsHandler(auth); Run pnpm build (or npm run build) Expected behavior The build process should only scan files within the project directory (e.g., under src/ or the Next.js project root) and should not attempt to read directories outside of the project root, especially system or user profile folders. Actual behavior The file scan triggered by toNextJsHandler is too broad and attempts to read protected directories under the user profile (C:\Users\ronny\...), causing a permissions error and failing the build. Workarounds attempted Commenting out the toNextJsHandler line allows the build to succeed. Adding custom watchOptions.ignored rules in next.config.ts does not prevent the glob from scanning outside the project. The error persists even with no Tailwind CSS or global CSS imports. Suggested fix Restrict the glob / file scanning patterns inside toNextJsHandler (or the underlying file scan logic) to be limited to the project directory, for example by: Using a base directory such as path.join(process.cwd(), 'src') as root for scans Adding options to exclude system or user folders Handling permission errors gracefully without failing the entire build Environment Windows 10 Node.js version: (e.g., v20.x) Next.js: 15.4.4 better-auth: 1.3.1 Package manager: pnpm Logs css Copiar Editar > users-betterauth@0.1.0 build D:\dev\nextjs\users-betterauth > next build ▲ Next.js 15.4.4 - Environments: .env Creating an optimized production build ... glob error [Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede'] { errno: -4048, code: 'EPERM', syscall: 'scandir', path: 'C:\\Users\\ronny\\Ambiente de Rede' } Failed to compile. Error: EPERM: operation not permitted, scandir 'C:\Users\ronny\Ambiente de Rede' > Build failed because of webpack errors ### Current vs. Expected behavior Expected behavior The build process should only scan files within the project directory (e.g., under src/ or the Next.js project root) and should not attempt to read directories outside of the project root, especially system or user profile folders. Actual behavior The file scan triggered by toNextJsHandler is too broad and attempts to read protected directories under the user profile (C:\Users\ronny\...), causing a permissions error and failing the build. ### What version of Better Auth are you using? 1.3.1 ### Provide environment information ```bash Windows 10/11 Node.js version: (e.g., v20.x) Next.js: 15.4.4 better-auth: 1.3.1 Package manager: pnpm ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth"; import { prismaAdapter } from "better-auth/adapters/prisma"; import prisma from "@/lib/prisma"; export const auth = betterAuth({ database: prismaAdapter(prisma, { provider: "postgresql", }), emailAndPassword: { enabled: true, }, }); ``` ### Additional context _No response_
GiteaMirror added the nextjs label 2026-03-13 08:49:52 -05:00
Author
Owner

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

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

This issue is not currently tracked or documented in the better-auth project. The implementation of toNextJsHandler does not use glob or perform any file scanning itself—it only returns handlers for GET and POST requests based on your auth config, and there is no evidence of file scanning or glob usage in its code or related documentation [source].

The file scanning that leads to EPERM errors is likely triggered elsewhere in the stack, possibly by a lower-level utility, plugin, or a Next.js build process that is scanning too broadly (e.g., starting from process.cwd() instead of the project root). No configuration options or workarounds specific to better-auth are documented for restricting this scan, and no similar issues have been reported in the repo or docs.

A possible next step is to review any custom plugins, adapters, or dynamic imports in your auth config (such as the Prisma adapter) and check if any of them could be triggering a broad file scan during build. Also, review your Next.js build setup for any plugins or custom scripts that might be involved in file discovery. If you can isolate a specific dependency or pattern that triggers the scan, restricting its root directory or handling permission errors gracefully would be the best mitigation.

To reply, just mention @dosu.


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

@dosubot[bot] commented on GitHub (Jul 26, 2025): <!-- Greeting --> Hi @r2desen! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This issue is not currently tracked or documented in the better-auth project. The implementation of `toNextJsHandler` does not use glob or perform any file scanning itself—it only returns handlers for GET and POST requests based on your auth config, and there is no evidence of file scanning or glob usage in its code or related documentation [[source]](https://github.com/better-auth/better-auth/blob/02f19810d60a26a8907f6a988383edf91b0b9599/packages/better-auth/src/integrations/next-js.ts). The file scanning that leads to EPERM errors is likely triggered elsewhere in the stack, possibly by a lower-level utility, plugin, or a Next.js build process that is scanning too broadly (e.g., starting from `process.cwd()` instead of the project root). No configuration options or workarounds specific to better-auth are documented for restricting this scan, and no similar issues have been reported in the repo or docs. A possible next step is to review any custom plugins, adapters, or dynamic imports in your auth config (such as the Prisma adapter) and check if any of them could be triggering a broad file scan during build. Also, review your Next.js build setup for any plugins or custom scripts that might be involved in file discovery. If you can isolate a specific dependency or pattern that triggers the scan, restricting its root directory or handling permission errors gracefully would be the best mitigation. <!-- 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/e6274056-0162-41f9-b3d4-4e654e175b0e?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/e6274056-0162-41f9-b3d4-4e654e175b0e?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/e6274056-0162-41f9-b3d4-4e654e175b0e?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/e6274056-0162-41f9-b3d4-4e654e175b0e?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e6274056-0162-41f9-b3d4-4e654e175b0e?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/e6274056-0162-41f9-b3d4-4e654e175b0e?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e6274056-0162-41f9-b3d4-4e654e175b0e?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/3626)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1581