Windows: build tracing (compiled @vercel/nft) globs the whole user profile when a dependency resolves a home-rooted dynamic path — junction loops surface as fatal EACCES webpack errors

Link to the code that reproduces this issue

https://github.com/hurttlocker/o8

To Reproduce

1. On Windows (stock GitHub windows-latest), run next build (webpack) on an app where some traced dependency computes a home-rooted dynamic path — an expression nft's static evaluator resolves to C:\Users\<user> or another directory above the project.
2. Build tracing (next/dist/compiled/@vercel/nft) emits a glob whose base is that out-of-project directory and starts walking C:\Users\<user>\**\*.
3. The Windows user profile contains junction cycles (Application Data -> AppData\Local and friends), so the walk recurses until access-denied errors surface as webpack build errors and fail the build.

Failing public CI run with the EACCES spray: https://github.com/hurttlocker/o8/actions/runs/31070784414
Investigation notes: https://github.com/hurttlocker/o8/issues/1745

Current vs. Expected behavior

Current: hundreds of errors of the shape

EACCES: permission denied, scandir 'C:\Users\runneradmin\AppData\Local\Application Data\...'

bubble out of the tracing glob walk as webpack errors, killing an otherwise-green build. We identified the source by instrumenting the compiled bundle's Glob constructor with a synchronous caller-stack print: the glob pattern's base was the runner's user-profile directory — outside the tracing base — produced from a statically-evaluated dynamic path in a dependency.

On macOS/Linux the same wildcard walk can happen but stays harmless (no junction cycles, different permission layout), which hides the bug from non-Windows CI.

Expected: emitted globs whose base directory is outside the tracing base (job.base) should be skipped — or at minimum, walk errors under such a base should be non-fatal. Tracing the entire user profile can never be the intended result of resolving one dynamic import; it's unbounded work and, on Windows, fatal.

We patched our compiled nft copy with exactly that guard — skip any emitted glob whose base is not equal to or under job.base — and the Windows build went from 100% failing to green, with zero change in traced output on darwin/linux.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows Server 2022 (GitHub windows-latest)
Binaries:
  Node: 22.x
  npm: 10.x
Relevant Packages:
  next: 16.2.11
  react: 19.x
  typescript: 5.x
Next.js Config:
  output: standalone (webpack build; Turbopack not used)

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

Webpack

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

next build (local)

Additional context

This may belong partly in the standalone vercel/nft repo — filing here first because the compiled-in copy under next/dist/compiled/@vercel/nft is what ships with Next and the failure presents as a next build failure. Happy to test candidate fixes on our public Windows CI matrix, where the failure was 100% reproducible.

Not yet verified against canary — the repro needs a Windows runner.

Start with the compiled tracing code under next/dist/compiled/@vercel/nft, especially the Glob walk and its job.base handling. Reproduce the reported next build on a Windows runner, then verify that globs rooted outside job.base do not walk the user profile and that the build no longer emits fatal EACCES errors.