v4: auth0.middleware() crashes with "Cannot read properties of undefined (reading 'provider')" when invoked from proxy.ts under Next.js 16 (works from a Route Handler)

[VACTR]

Checklist

• The issue can be reproduced in the nextjs-auth0 sample app (or N/A — reproduced in a minimal Next.js 16 app instead, see below).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer (closest are Nextjs v16, auth0 v4.13.1: /auth/{login,logout,callback,profile,etc} not found #2436 and 4.13.0 - auth0.middleware no longer redirects when there's no session #2417, both different symptoms on earlier 4.x versions, both closed).
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

auth0.middleware() throws TypeError: Cannot read properties of undefined (reading 'provider') on every request when invoked from proxy.ts under Next.js 16. Reproduced identically in both next dev and next start (production build) — not a dev-only artifact.

The most diagnostic detail: the identical auth0.middleware() call succeeds when dispatched from a Route Handler and fails when dispatched from proxy.ts. Same Auth0Client instance, same request, two different call sites:

• GET /api/auth/login (dispatched from app/api/auth/[auth0]/route.ts, calling auth0.middleware(req) directly inside a GET handler) → works correctly. Clean 307 to the real Auth0 /authorize endpoint with correct client_id, PKCE code_challenge, state, nonce, and a properly-set transaction cookie.
• GET /login (an ordinary app page, covered by proxy.ts's matcher) → crashes with the trace below, on every request, no exceptions.

I initially suspected this might be an Edge-vs-Node runtime difference, since the working call site is a Node.js Route Handler. I tested this directly by adding export const runtime = "nodejs" to proxy.ts — Next.js rejected it outright at build time: Error: Route segment config is not allowed in Proxy file... Proxy always runs on Node.js runtime. So there is no Edge/Node distinction to invoke here; proxy.ts is already Node-only under Next 16, and the crash happens anyway. I was not able to narrow the root cause further than that structural contrast.

Also ruled out: fake/placeholder Auth0 credentials (re-tested against a real, valid Auth0 tenant and real client credentials — identical crash); an SDK version predating Next 16 support (this is reproduced on 4.25.0, whose own peerDependencies list next: "... || ^16.0.10"); the SDK's env-var-lazy domain resolver (passed domain explicitly instead of relying on the AUTH0_DOMAIN fallback — identical crash).

Workaround in use: removed proxy.ts entirely. Route mounting still works via the Route Handler (route.ts), and route protection is handled by each protected layout calling auth0.getSession() directly rather than relying on the proxy. The only capability lost is automatic rolling-session refresh.

Reproduction

1. Create a Next.js 16 app (App Router, Turbopack): npx create-next-app@latest --typescript
2. Add @auth0/nextjs-auth0 (4.25.0) and configure a minimal Auth0Client in e.g. auth.ts:

   import { Auth0Client } from "@auth0/nextjs-auth0/server";
   export const auth0 = new Auth0Client();

3. Create proxy.ts at the project root per the v4 migration guide's Next 16 section:

   import { auth0 } from "./auth";
   export default auth0.middleware;
   export const config = {
     matcher: ["/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)"],
   };

4. Set real (or placeholder — both reproduce it) AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_CLIENT_SECRET, AUTH0_SECRET, AUTH0_BASE_URL env vars.
5. next build && next start, then request any page not excluded by the matcher (e.g. /).
6. Expect: normal page response. Actual: 500, with the trace below in the server log.

Additional context

Full trace (paths are the local build output; the specific file/hash naturally varies by build):

TypeError: Cannot read properties of undefined (reading 'provider')
    at middleware (.next\server\chunks\[root-of-the-server]__<hash>._.js:31:138428)
    at handler (.next\server\chunks\[root-of-the-server]__<hash>._.js:34:1616)
    at <unknown> (.next\server\chunks\[root-of-the-server]__<hash>._.js:15:37004)
    at <unknown> (.next\server\chunks\[root-of-the-server]__<hash>._.js:15:36970)
    at async t2 (.next\server\chunks\[root-of-the-server]__<hash>._.js:15:33484)

Looking at dist/server/client.js (~line 195–243), the constructor's own comments describe an initialization-order dependency: this.provider is assigned via new AuthClientProvider(...), and a factory closure captures this by reference intending to read this.provider only after that assignment completes, with an explicit static-mode workaround for the case where "the factory ... is called during AuthClientProvider construction, before this.provider is fully assigned." That reads like the class of race the crash matches, but I wasn't able to confirm it's the same code path triggering under the proxy specifically.

nextjs-auth0 version

4.25.0 (also reproduced on 4.22.0 before upgrading)

Next.js version

16.2.12 (Turbopack)

Node.js version

24.14.1

[Piyush-85]

@VACTR Thanks for raising this, will debug and get back.

[VACTR]

Update on the diagnosis, in case it helps narrow this down before you dig in — the title/description as filed is narrower than what I've since confirmed.

Corrected characterisation: this is not Next.js-16-specific. It reproduces identically under Next.js 15 with the pre-16 middleware.ts filename (same SDK version, same Auth0Client config, same crash — Cannot read properties of undefined (reading 'provider')). The proxy/middleware dispatch path is what triggers it, independent of which Next.js major version or file-naming convention is in use. Renaming middleware.ts → proxy.ts for Next 16 is a filename change on Next's side, not a new invocation mechanism — and the bug predates that rename.

What ruled out an Edge-vs-Node explanation (from the original report, restated for clarity): adding export const runtime = "nodejs" to the middleware/proxy file doesn't change the outcome — Next.js rejects the directive outright at build time in proxy.ts ("Proxy always runs on Node.js runtime"), and under middleware.ts the crash reproduces the same way regardless of the runtime declared. So there's no Edge/Node distinction to invoke on either side — both are already Node-context, and the crash isn't a runtime-selection issue.

The Route-Handler-vs-proxy/middleware contrast, confirmed on both Next 15 and Next 16: the identical auth0.middleware() call, with the identical Auth0Client instance, succeeds every time when invoked from a Route Handler (GET/POST exported from an app/**/route.ts file calling auth0.middleware(req) directly) and fails every time when invoked from middleware.ts/proxy.ts. Same SDK version (4.22.0 and 4.25.0, both tested), same config, only the dispatch path differs.

Given that contrast holds across both Next.js major versions, I'd guess the root cause sits in how the SDK's AuthClientProvider/this.provider gets initialized relative to when and how the framework's middleware/proxy runtime first invokes it — possibly a timing/instance issue specific to the middleware execution context rather than anything Next-16-version-specific. I haven't been able to narrow further than that from the outside, but happy to test anything that would help isolate it further, if useful.

Workaround in place on our side is unchanged from the original report: dispatch only from a Route Handler, no proxy.ts/middleware.ts at all, route protection handled independently via each protected layout's own getSession() check. Works cleanly on both Next.js versions; the only capability lost is the SDK's automatic rolling-session refresh, which we replaced with an explicit fixed-duration session.