Turbopack inferred parent root causes high memory pressure in next dev

[boopy253]

Link to the code that reproduces this issue

https://github.com/boopy253/next-turbopack-root-watch-repro

To Reproduce

1. Clone the reproduction repository.
2. Run:

cd app
npm install
npm run dev

3. Open the local dev URL printed by Next.js.

The repository root contains a parent package-lock.json, while the actual app lives in app/. The app intentionally does not set turbopack.root, so Next.js/Turbopack can infer the parent repository directory as the root.

The repository is intentionally small by default. It demonstrates the unsafe root inference without requiring a large local filesystem load.

Safe local validation on the reproduction repository:

• On next@16.3.0-canary.39, next dev still prints the workspace-root warning and selects the parent package-lock.json.
• With 1,000 generated unrelated files under the inferred parent root, a single guarded page request on next@16.2.7 reached about 904 MB process-tree RSS without Turbopack tracing, and about 923 MB process-tree RSS with NEXT_TURBOPACK_TRACING=1.
• The same guarded request on next@16.3.0-canary.39 reached about 813 MB process-tree RSS without Turbopack tracing, and about 828 MB process-tree RSS with NEXT_TURBOPACK_TRACING=1.
• The canary result is lower than 16.2.7, but it still performs the same parent-root inference and still shows substantial dev-server memory pressure in this small reproduction.
• These guarded validations did not increase system swap usage; they were intended to demonstrate the root-inference behavior and memory pressure without reproducing the full macOS VM-compressor failure path.

Current vs. Expected behavior

Current behavior:

When next dev runs with Turbopack and root is inferred from parent lockfiles, Turbopack can operate with a broader parent root than the actual application directory. In a large parent tree, this expands the filesystem scope used for module resolution, watching, and dev cache work.

In a larger local parent tree on macOS, this escalated beyond a normal Node.js process crash. The machine reached VM compressor exhaustion and then rebooted/panicked via watchdog:

panic: watchdog timeout: no checkins from watchdogd in 94 seconds
Compressor Info: 89% of compressed pages limit (OK) and 100% of segments limit (BAD) with 48 swapfiles and OK swap space

System logs shortly before the reboot/panic showed VM compressor pressure and jetsam activity:

memorystatus: killing due to "vm-compressor-space-shortage"
memorystatus: System is unhealthy
"compressor_exhausted": 1
JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGE

Expected behavior:

• Suspicious parent-root inference from multiple lockfiles should fail fast, or at least require explicit confirmation before Turbopack starts watching/resolving a broad parent tree.
• A broad inferred root should not lead to unbounded memory growth.
• Turbopack should have a resource guardrail for dev-server workers, file watching, and cache work.
• If turbopack.root is set explicitly, all downstream resolver and watcher behavior should strictly honor it.

Mitigation:

Setting turbopack.root explicitly to the app directory prevents the broader parent root from being used:

import path from "node:path";
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  turbopack: {
    root: path.resolve(__dirname),
  },
};

export default nextConfig;

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.5.0: Mon Apr 27 20:39:29 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T8142
  Available memory (MB): 16384
  Available CPU cores: 10

Binaries:
  Node: 24.15.0
  npm: 11.15.0
  Yarn: 1.22.22
  pnpm: 11.0.9

Relevant Packages:
  next: 16.3.0-canary.39 // Latest available version is detected (16.3.0-canary.39).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 6.0.3

Next.js Config:
  output: N/A

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

Turbopack, Module Resolution, Performance, Runtime

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

next dev (local)

Additional context

This looks related to #92978, but the observed failure mode on macOS was more severe. Instead of only a Node OOM or frozen dev server, the system reached VM compressor segment exhaustion and then a watchdog reboot/panic.

The key combination appears to be:

1. Next.js root inference selecting a parent directory based on lockfiles.
2. Turbopack using that broad root for module resolution / filesystem watching / dev cache.
3. A large parent directory tree causing excessive memory and VM compressor pressure.

The docs suggest collecting a Turbopack trace for performance or memory issues:

NEXT_TURBOPACK_TRACING=1 next dev