Link to the code that reproduces this issue

https://github.com/bencmbrook/next-aggregateerror-repro

To Reproduce

To reproduce:

1. Build the app (next build /npm run build)
2. Start the app (next start /npm run start)
3. Openhttp://localhost:3000/api/log.

This will:

• Log to the server logs:console.error(myAggregateError)
• Display on the webpage, the result ofutil.inspect(myAggregateError)

The log and the text on the webpage will both show that the formattedAggregateError omits the[errors] section of the string.

To confirm that this is inconsistent with Node's behavior:

1. In a terminal, open the Node REPL (node)

2. Paste this code:

   consterror1=newError("Error 1");consterror2=newTypeError("Error 2");// `AggregateError` doesn't include the `errors` property in the log, even in production. It does in an unpatched Node runtime.constmyAggregateError=newAggregateError([error1,error2],"Multiple errors:");console.error(myAggregateError);// This is because the Node's util.inspect is likely patched:constformattedAggregateError=util.inspect(myAggregateError);conststringified=`This is the formatted AggregateError from util.inspect, missing the \`[errors]\` section:\n\n${formattedAggregateError}`;console.log(stringified);

3. Hit enter, and observe that bothconsole.error(myAggregateError) andconsole.log(stringified) produce a string containing the[errors] section.

Current vs. Expected behavior

Current Behavior:

console.error(myAggregateError) produces:

AggregateError: Multiple errors:    at x (.next/server/app/api/log/route.js:1:1569)

Expected Behavior:

console.error(myAggregateError) should include the[errors] section:

AggregateError: Multiple errors:    at x (.next/server/app/api/log/route.js:1:1569) {  [errors]: [    Error: Error 1        at x (.next/server/app/api/log/route.js:1:1569)    TypeError: Error 2        at x (.next/server/app/api/log/route.js:1:1588)  ]}

Provide environment information

Operating 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  Available memory (MB): 36864  Available CPU cores: 12Binaries:  Node: 22.18.0  npm: 10.9.3  Yarn: 1.22.22  pnpm: 9.15.4Relevant Packages:  next: 15.6.0-canary.39 // Latest available version is detected (15.6.0-canary.39).  eslint-config-next: N/A  react: 19.1.1  react-dom: 19.1.1  typescript: 5.9.3Next.js Config:  output: N/A

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

Route Handlers, Error Handling

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

Vercel (Deployed), next start (local)

Additional context

• It looks likeutil.inspectis indeed patched by Next.js. This is the function that Node uses to serialize Error objects insideconsole.log
• MDN reference on theerrors property.
• In development (next dev), this property is also not shown, but in development it is significantly different already (where it shows the code snippet), so it's already less comparable to expected Node behavior.
• I've tried this in Node 24, 22, 20 and the behavior is the same in each
• In case it's helpful, I'veadded a second test case to confirm that thecause property serializes correctly—it appears that it does work, and this bug is isolated to theerrors property.

  • Same steps as repro, but navigate tohttp://localhost:3000/api/with-cause. This will log:

    AggregateError: Multiple errors:    at x (.next/server/app/api/with-cause/route.js:1:671) {  [cause]: Error: Root error      at x (.next/server/app/api/with-cause/route.js:1:649)}

    So thecause property does serialize correctly, it's just.errors that is being omitted.