Nextjs on Lessons learned

Next.js Server Action arguments are Flight data: use error digests carefully

Tue, 06 Oct 2026 00:00:00 +0000

A Next.js Server Action can receive a JSON-looking body whose strings are interpreted as React Flight tokens. If ordinary input works but $-prefixed input changes the response or produces HTTP 500, inspect the decoded arguments before trying more SQL or shell payloads. Differences between error digests can help separate failure paths, but they cannot establish a vulnerable version or remote code execution on their own.

This matters when testing the request behind an action call. The normal client serializer escapes literal strings for the protocol; manually editing the wire body can change what the server decodes.

The application sees the result of decodeReply

In the tagged Next.js 15.0.0 action handler , fetch-action bodies pass through decodeReply or its streaming counterpart before the selected action runs. The React 19.0.0 reply decoder interprets $-prefixed strings, including escaped literals, special numbers, and references.

For a local decoder, these argument values illustrate the distinction:

Wire string inside the arguments array	Decoded argument
`ordinary`	string `ordinary`
`$$literal`	string `$literal`
`$Infinity`	number `Infinity`
`$-Infinity`	number `-Infinity`
`$undefined`	`undefined`

A value changing type before the application function runs explains why an otherwise boring search action can behave strangely. Input validation inside that function does not protect an earlier, vulnerable deserializer.

Reproduce the protocol locally before probing further

Use an isolated scratch directory. The following intentionally installs an old, vulnerable package for an offline decoder experiment. Do not deploy it, expose a listener, or feed it untrusted traffic. Delete the directory afterward.

LAB=$(mktemp -d "${TMPDIR:?Set TMPDIR to your scratch directory}/flight-lab.XXXXXX")
cd "$LAB"
npm install --ignore-scripts --no-audit --no-fund --save-exact \
 react@19.0.0 react-dom@19.0.0 react-server-dom-webpack@19.0.0

Save this as check.cjs in that directory, then run node --conditions=react-server check.cjs:

const assert = require('node:assert/strict');
const { decodeReply } = require('react-server-dom-webpack/server.node');

async function check() {
 const cases = [
 ['ordinary', 'ordinary'],
 ['$$literal', '$literal'],
 ['$Infinity', Infinity],
 ['$-Infinity', -Infinity],
 ['$undefined', undefined],
 ];
 for (const [wire, expected] of cases) {
 const args = await decodeReply(JSON.stringify([wire]), {});
 assert.ok(Array.isArray(args));
 assert.equal(args[0], expected);
 }
 console.log('5 Flight decoding cases passed');
}
check().catch(error => {
 console.error(error);
 process.exitCode = 1;
});

This checks protocol behavior, not exploitability. For an authorized application assessment, reproduce the actual resolved packages and runtime conditions. Next.js may bundle its React implementation; a standalone npm package is not automatically an exact framework replica.

Preserve the decoded root’s expected shape, too. The tagged Next.js handler invokes actionHandler.apply(null, boundActionArguments). A root that resolves to a primitive string fails that call’s array-like argument requirement before the intended action behavior can be tested. Keep transport decoding and action invocation as separate checkpoints.

What an error digest can tell you

The Next.js 15.0.0 error handler generates digests using stringHash over error text and stack information in several paths, unless a digest already exists. One path uses:

err.digest = stringHash(err.message + (err.stack || '')).toString()

Different parser branches can throw from different stack locations and yield different digests even when the visible error message is generic. Record the complete response, status, and digest for each controlled input; repeat baseline requests to check stability. Correlate differences with logs in the local replica.

A digest is a lossy fingerprint. Build paths, package versions, runtime stacks, and existing application digests can alter it. Distinct digests suggest distinct error material; matching digests do not prove identical execution paths. HTTP 500 alone does not even locate the failure in Flight decoding.

Separate protocol reachability from React2Shell

React’s CVE-2025-55182 advisory confirms unauthenticated RCE through a flaw in decoding Server Function payloads. Ordinary Flight tokens also exist in correct protocol handling. Observing the transformations above therefore does not diagnose that CVE.

For exploit validation, first reproduce the affected decoder in a private replica and demonstrate a harmless, deterministic effect there. Keep that result separate from any authorized remote confirmation. The experiment above deliberately stops at benign decoding.

For prevention, follow the current React and framework advisories, update the resolved server-side packages, rebuild, and verify what the running artifact actually contains. Do not use the historical demonstration versions as a patch recommendation. Authenticate and authorize actions independently, validate decoded arguments, and avoid exposing decoded-input debug echoes. Those controls do not replace fixing a vulnerable decoder.

When a $ probe changes behavior, capture the full response and reproduce that transformation locally before assigning a CVE or an impact rating.

Sandbox-blocked tests called "environmental", then committed

Mon, 13 Jul 2026 15:38:00 +0200

My coding agent finished a feature, ran the full test suite, and reported:

Full suite: 135 passed, 97 skipped; 22 DB suites failed due to no container runtime, plus sandboxed stub bind. Commit only handoff implementation files.

Then it committed. I ran pnpm test myself and got three real failures. The production build it had also skipped was broken too, and nobody found out for two months.

If your agent’s test run shows Error: Could not find a working container runtime strategy or Error: listen EPERM: operation not permitted 0.0.0.0:8080, those tests never ran, and a summary that counts them as “blocked” tells you nothing about the code.

The setup

Codex CLI on macOS, with its default sandbox
A pnpm monorepo: a Next.js 15.5.19 app plus a few packages
Vitest 2.1.9, with Testcontainers 10.28.0 starting Postgres for the database tests and a local stub of an external service listening on port 8080

The agent split the feature into five slices and gave each to a parallel subagent. Each subagent ran its own focused tests, and the orchestrator ran the full suite and the build at the end.

What went wrong

The sandbox blocks more than writes outside the project. Here it blocked three things the checks needed:

Testcontainers couldn’t reach Docker: Could not find a working container runtime strategy.
The service stub couldn’t bind its port: listen EPERM: operation not permitted 0.0.0.0:8080.
next build couldn’t write its compiler cache: EPERM writing ~/Library/Caches/next-swc.

Every database suite failed in beforeAll, and Vitest reported the tests inside them as skipped. The agent’s final report was accurate:

- Typecheck pass
- Focused tests pass
- Full: 135 passed; DB suites blocked by no Docker
- Build blocked by Next SWC cache permissions

Every line of that is true. But the suite has 232 tests, and 135 + 97 = 232: over 40 percent of it never ran, including every test that touched the database, where this feature did most of its work.

On the host, the same suite printed:

Test Files 2 failed | 63 passed (65)
 Tests 3 failed | 229 passed (232)

One new test forgot to start the service stub, so its client found no endpoint configured. Two older tests broke because the feature added an ownership check and their fixtures sent requests without a logged-in user (Error: authentication required). The agent fixed all three in two minutes once it saw them.

The build was worse. The commit re-exported a server action from another "use server" file:

"use server";

export { finalizeArtifact } from "../../reports/actions.ts";

tsc accepts this, and so do the tests. Only next build rejects it:

Failed to compile.

./app/reports/[id]/actions.ts
Error: x Only async functions are allowed to be exported in a "use server" file.

Two months later, a different session ran a production build, hit this error, and deleted the line.

The same sandbox, the same day

Half an hour before the bad commit, another session in the same repository hit the same two errors. At first it called them environmental too. Then it decided:

Full suite blocked by sandbox: Testcontainers cannot see Docker; stub bind gets `EPERM :8080`. Since Docker is reportedly running, retry full suite with host access.

Two minutes later it reported “Host rerun green: 60 files, 222 tests”, and only then did it commit. The agent that fixed my three failures did the same: it reran the focused tests with host approval before committing the fix. Both sessions knew how to leave the sandbox; nothing required them to before a commit.

Fix

Treat “blocked” as “not run”, and make “not run” stop the commit.

In Codex, a command runs outside the sandbox when the agent requests sandbox_permissions: "require_escalated" and you approve it. Put the rule in the instructions file the agent reads every session (AGENTS.md, or CLAUDE.md for Claude Code):

A check that the sandbox blocked has not passed. Before committing, rerun every blocked test suite and build with host access (`sandbox_permissions: "require_escalated"`).
If that isn't possible, don't commit: report what didn't run.

Then read the agent’s numbers yourself. If passed plus skipped equals the total, and you never skip tests on purpose, every skipped test is one that didn’t run. If you have CI, have it run the full suite and the build before a merge.

Why it happens

The agent’s memory for this project already had a rule: “separate passed static or focused checks from runtime suites blocked by the environment, and reserve the final green claim for integrated verification.” The agent followed that rule to the letter: it never claimed green and listed exactly what had been blocked. Then it committed, because nothing in its instructions tied the commit to the green claim.

“Blocked by the environment” reads like an infrastructure problem that someone else will handle, so it ends up as a footnote in the report while the commit goes ahead. The rule made the report honest. It didn’t make anyone run the tests.

Takeaway

When a sandbox blocks a test or a build, nothing was verified. An agent that reports this honestly will still commit, unless its instructions say that a blocked check stops the commit.

Look at your agent’s last commit: if its summary says a suite or a build was “blocked”, rerun them on the host today.

ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY: your coding agent's pnpm 11 is not your pnpm 10

Mon, 06 Jul 2026 15:04:00 +0200

A coding agent ran pnpm test in my repo and got this:

Scope: all 6 workspace projects
[ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY] Aborted removal of modules directory due to no TTY

If you are running pnpm in CI, set the CI environment variable to "true", or set "confirmModulesPurge" to "false".

The stack trace ended in runDepsStatusCheck (.../node_modules/.pnpm/pnpm@11.7.0/...). My package.json says "packageManager": "pnpm@10.33.0", and pnpm -v in my terminal prints 10.33.0.

If you see this error only inside an agent, the agent is running its own pnpm, and following the hint makes things worse.

The setup

macOS, pnpm 10.33.0 through Corepack, a pnpm monorepo with a Next.js 15 app
The Codex desktop app, which ships its own Node 24 and pnpm under ~/.cache/codex-runtimes/codex-primary-runtime/dependencies/: pnpm 11.7.0 in July, 11.25.0 in October
The agent runs pnpm test without a TTY

What went wrong

The agent followed the hint and reran with CI=true pnpm test. pnpm stopped asking and did what it had wanted to do from the start:

Recreating /Users/me/project/node_modules
Progress: resolved 378, reused 0, downloaded 137, added 12
...
[WARN] GET https://registry.npmjs.org/@next/swc-darwin-arm64/-/swc-darwin-arm64-15.5.19.tgz error (ERR_PNPM_ENOSPC). Will retry in 10 seconds. 2 retries left.
[WARN] GET https://registry.npmjs.org/next/-/next-15.5.19.tgz error (ERR_PNPM_ENOSPC). Will retry in 10 seconds. 2 retries left.
...
Progress: resolved 378, reused 0, downloaded 377, added 377, done

[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: cpu-features@0.0.10, esbuild@0.21.5, esbuild@0.28.1, protobufjs@7.6.4, sharp@0.34.5, ssh2@1.17.0

It deleted node_modules and downloaded every package again (reused 0) into a second store, and the disk ran out on the way. It left an untracked .pnpm-store/ in the repo and wrote placeholders into the tracked pnpm-workspace.yaml:

allowBuilds:
 cpu-features: set this to true or false
 esbuild: set this to true or false
 protobufjs: set this to true or false
 sharp: set this to true or false
 ssh2: set this to true or false

No tests ran. After that, even pnpm exec tsc --noEmit failed with the same NO_TTY error, so the agent switched to ./node_modules/.bin/tsc and ./node_modules/.bin/vitest, reverted the YAML, deleted .pnpm-store/ and committed with only the focused tests green.

Ten weeks later, next build failed:

 ⚠ Attempted to load @next/swc-darwin-arm64, but it was not installed
 ⨯ Failed to load SWC binary for darwin/arm64, see more info here: https://nextjs.org/docs/messages/failed-loading-swc

The July install had ended one package short (378 resolved, 377 added), and the SWC binary was one of the two downloads that hit ENOSPC. A later agent session “fixed” the build by installing the binary into /tmp and symlinking it into node_modules, a fix that lasts until macOS cleans /tmp.

Fix

First, ask the agent’s shell which pnpm it gets:

command -v pnpm
pnpm -v

Then make the agent use your version. Corepack reads packageManager, whatever is first on PATH:

corepack pnpm test # runs pnpm 10.33.0

Write that into AGENTS.md (or your agent’s equivalent), along with one rule: if pnpm wants to remove node_modules, stop and report.

To make the bundled pnpm harmless as well, turn off the automatic install in pnpm-workspace.yaml:

verifyDepsBeforeRun: false

That is the pnpm 10 default, so nothing changes for you. I checked it with the bundled pnpm 11.25.0: with the setting, it runs the script; without it, it installs first.

If you already followed the hint, clean up with your own pnpm:

git checkout -- pnpm-workspace.yaml
rm -rf .pnpm-store
corepack pnpm install --frozen-lockfile

Run that in a terminal. If pnpm asks to remove node_modules, say yes; this time it rebuilds against your own store.

Why

Three pnpm 11 changes line up:

verify-deps-before-run defaults to install (pnpm 10: false). pnpm test and pnpm exec check node_modules first and install if anything is off.
pnpm 11 uses store v11; pnpm 10 uses v10. node_modules/.modules.yaml records the store it was linked from, so to pnpm 11 a working pnpm 10 install looks incompatible and has to be purged. confirmModulesPurge defaults to true; a purge without a TTY aborts, and CI=true drops the confirmation but not the purge.
Ignored build scripts are an error, and pnpm writes the allowBuilds placeholders for you to fill in.

On my Mac, the two stores now sit side by side in ~/Library/pnpm/store/: 851 MB in v10, 588 MB in v11.

Why didn’t packageManager catch it? pnpm 11 does honor it: run the bundled binary directly and pnpm -v prints 10.33.0, because it switches to the pinned version. The wrapper in the October runtime turns that off:

#!/usr/bin/env bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
export pnpm_config_pm_on_fail=ignore
exec "${SCRIPT_DIR}/../../node/bin/node" "${SCRIPT_DIR}/../../node/node_modules/pnpm/bin/pnpm.mjs" "$@"

The environment variable beats anything in the repo. With pmOnFail: error in pnpm-workspace.yaml, or devEngines.packageManager with "onFail": "error", the wrapper still runs 11.25.0.

Takeaway

An agent runtime can bring its own toolchain and switch off the check that would have caught it. When an agent reports “tests blocked by the environment”, find out which binary it ran before you believe the report.

Run pnpm -v in your agent’s shell today and compare it with packageManager.

Next.js "Cannot read properties of undefined (reading 'length')" in installChunk: two processes share .next

Mon, 22 Jun 2026 13:01:00 +0200

I opened the dashboard of my Next.js app and got a 500 error:

 GET /app/dashboard 500 in 285ms
 ⨯ TypeError: Cannot read properties of undefined (reading 'length')
 at <unknown> (.next/server/app/app/accounts/page.js:685:47)
 at Object.<anonymous> (.next/server/app/app/accounts/page.js:688:3) {
 page: '/app/accounts'
}
 GET /app/accounts 500 in 278ms

If the stack points into generated .next/server/.../page.js and the full trace ends in installChunk in webpack-runtime.js, your code is fine. Another Next process has written into the .next directory your dev server is reading from.

The setup

Next.js 15.5 with webpack in dev, in a pnpm monorepo (the app lives in apps/web)
pnpm dev running in my terminal on port 3000
A coding agent working in the same checkout, which checks its work with pnpm build

What went wrong

I asked the agent to fix the 500. It did what anyone would do with reading 'length': it grepped the app for .length. The accounts page didn’t touch a collection at all, so the agent followed the authenticated layout into the auth code and suspected an import there. Then it opened the generated page.js at line 685 and found webpack glue, not application code.

To reproduce, the agent ran pnpm build, which succeeded, and then started its own next dev -p 3001 next to mine. The first request to /app/accounts returned 200. After a request to the dashboard, both routes returned 500, and this time the error page carried the whole stack:

TypeError: Cannot read properties of undefined (reading 'length')
 at installChunk (apps/web/.next/server/webpack-runtime.js:249:41)
 at __webpack_require__.f.require (apps/web/.next/server/webpack-runtime.js:259:15)
 ...
 at apps/web/.next/server/app/app/dashboard/page.js:718:47

Line 249 is in webpack’s chunk loader:

var installChunk = (chunk) => {
 var moreModules = chunk.modules, chunkIds = chunk.ids, runtime = chunk.runtime;
 // ...
 for(var i = 0; i < chunkIds.length; i++)
 installedChunks[chunkIds[i]] = 1;
};

chunk is whatever require("./" + chunkFile) returned. chunk.ids was undefined, so the file on disk was not the chunk this runtime expected. A ps showed why: two next-server processes, mine on 3000 and the agent’s on 3001, both compiling into apps/web/.next. On top of that, the agent’s next build had written its production output into the same directory a few minutes earlier.

Both of the usual ways to reproduce a bug, a fresh build and a second server, are ways to cause this one. Before you reproduce, look for other Next processes on the checkout:

ps -axo pid,ppid,command | grep '[n]ext-server'

Fix

Give next dev its own output directory in next.config.mjs:

export default {
 // `next dev` and `next build` generate incompatible webpack chunk graphs.
 // Keep their output separate so a build cannot break a running dev server.
 distDir: process.env.NODE_ENV === "development" ? ".next-dev" : ".next",
};

Ignore it in .gitignore:

.next/
.next-dev/

Add its generated types to tsconfig.json, next to the .next ones:

"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts", ".next-dev/types/**/*.ts"]

The running dev server picked up the config change and rebuilt into .next-dev. From then on, next build writes to .next and the dev server never reads it.

To recover without the config change, stop every Next process except one, delete .next and restart pnpm dev.

If you’re on Next.js 16, you already have this: next dev writes to .next/dev, so dev and build can run concurrently .

The follow-on trap: `next-env.d.ts`

Next rewrites next-env.d.ts on every dev start and every build, and the file names the types of whichever directory ran last:

/// <reference path="./.next-dev/types/routes.d.ts" />

After every next build, it says ./.next/types/routes.d.ts instead. The file was tracked, so it showed up as modified in later sessions, and the agents kept “fixing” it with git show HEAD:apps/web/next-env.d.ts > apps/web/next-env.d.ts. Do what the .gitignore from create-next-app does and ignore the file:

echo 'next-env.d.ts' >> apps/web/.gitignore
git rm --cached apps/web/next-env.d.ts

Why

next dev and next build both default to .next in Next.js 15, and they write different chunk graphs into it. A second next dev is no better: two webpack compilers write into one directory, and neither knows about the other. The runtime that is already loaded require()s a chunk by the name from its own graph, gets a file the other compilation wrote, and fails at chunk.ids.length. The error says length, so you go looking for an array in your code.

Coding agents check their work with next build, usually while your dev server is still running, so you’ll hit this more often than you’d think.

Takeaway

An error from inside installChunk points at the build directory, so look for a second Next process before you read your own code. Never let two Next processes share a distDir.

If an agent or a script runs next build in the checkout where your dev server runs, give dev its own distDir today.

Nextjs on Lessons learned

Next.js Server Action arguments are Flight data: use error digests carefully

The application sees the result of decodeReply

Reproduce the protocol locally before probing further

What an error digest can tell you

Separate protocol reachability from React2Shell

Sandbox-blocked tests called "environmental", then committed

The setup

What went wrong

The same sandbox, the same day

Fix

Why it happens

Takeaway

ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY: your coding agent's pnpm 11 is not your pnpm 10

The setup

What went wrong

Fix

Why

Takeaway

Next.js "Cannot read properties of undefined (reading 'length')" in installChunk: two processes share .next

The setup

What went wrong

Fix

The follow-on trap: next-env.d.ts

Why

Takeaway

The follow-on trap: `next-env.d.ts`