perf(build): stop unpacking node_modules wholesale from the Windows asar

[tsouth89]

Fixes the install-time and cold-start half of #5876.

What Changed

WINDOWS_ASAR_UNPACK was ["apps/server/dist/**", "**/node_modules/**"]. This inverts the CLI bundler's dependency rule — bundle everything except the packages that genuinely cannot be inlined — and narrows asarUnpack to exactly that set.

A package earns an exemption for one of two reasons:

• Native addons. A .node binary cannot be inlined into JS and must sit on disk for both the Windows primary and the Linux Node inside WSL. The JS wrappers that dlopen them count too (ffi-rs, @ff-labs/fff-node, msgpackr-extract, node-gyp-build), since they resolve their binary by real filesystem path at runtime.
• Bun-only entry points. @effect/platform-bun and @effect/sql-sqlite-bun are reached through a runtime-conditional dynamic import and resolve bun:sqlite, which does not exist when bundling for Node.

Both consumers now derive from one list in scripts/lib/cli-external-packages.ts, so they cannot drift.

Why

The Windows installer writes 14,687 files, 13,875 of them loose node_modules files, to support 20 native binaries. The entire Electron runtime is 22 files because it stays inside the archive.

That count costs twice: NSIS install time tracks file count, not bytes; and each file is a separate open/stat/scan the first time the server runs after an install, when the file cache is cold and the on-access scanner is not.

Measured on this repo, win/nsis x64:

	before	after
files written at install	14,687	1,192 (−92%)
loose node_modules files	13,875	370
native .node binaries	20	20
installer size	145.0 MiB	138.9 MiB

Cold start, extracting each build's payload to a fresh directory so the files had never been read, alternating run order between builds:

	before	after
server boot to Listening on	9,044ms / 10,160ms	3,667ms / 3,779ms
module load only (--version)	6,521 / 6,238 / 6,208ms	761 / 659 / 654ms

The main window is not created until the backend answers HTTP, so that ~6s comes off a cold launch.

Why one shared list

A package that is external but not unpacked still resolves on the Windows primary, which runs under ELECTRON_RUN_AS_NODE and reads app.asar transparently. It fails only under WSL. That asymmetry makes the drift invisible on the platform you are most likely to test on.

node-gyp-build-optional-packages hit exactly this while I was writing the patch — matched as external by the node-gyp-build prefix, missed by a glob without a trailing wildcard. There are tests for the invariant.

Verification

Extracted app.asar.unpacked into a directory with no node_modules ancestor — what plain node sees under WSL — and booted the server there. Migrations ran, it listened on 127.0.0.1, and no module failed to resolve. node-pty, ffi-rs, msgpackr-extract and @ff-labs/fff-node all load from that isolated tree.

scripts/build-desktop-artifact.test.ts (30) and the new scripts/lib/cli-external-packages.test.ts (7) pass. vp lint and @t3tools/server typecheck are clean.

One caveat on my verification: the build warned No WSL node-pty prebuild provided, so I exercised the WSL module resolution path with Linux-shaped constraints rather than a real WSL launch. Happy to rerun with a Linux pty.node prebuild if you want that closed before merging.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a — no UI change)
• I included a video for animation/interaction changes (n/a — no motion change)

---

Note

Medium Risk
Windows/WSL packaging behavior changes—missing external or unpack coverage surfaces as runtime MODULE_NOT_FOUND under WSL while Windows may still work; mitigated by shared lists, closure tests, and the packaged self-containment probe.

Overview
Narrows Windows asarUnpack from all of node_modules to the server dist plus globs derived from a shared external-package list, cutting install file count sharply while keeping what plain Node under WSL can load on disk.

Inverts server CLI bundling in apps/server/vite.config.ts: inline almost all JS deps via alwaysBundle + neverBundle, with rules centralized in scripts/lib/cli-external-packages.ts so the bundler and unpack globs stay aligned (native addons, loaders like node-gyp-build / detect-libc, bun-only entry points).

Adds desktop build guards: scan emitted chunks for wrongly inlined externals and missing inlined effect; detect inlined native loaders from the pnpm store; on Windows, copy app.asar.unpacked into an isolated tree (junction-safe symlinks, no ancestor node_modules) and run bin.mjs --version with hardened Node resolution.

Updates WSL preflight to require.resolve("node-pty/package.json") instead of effect, since JS deps are no longer on the unpacked filesystem.

^{Reviewed by Cursor Bugbot for commit 2103eb6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Stop unpacking all node_modules from the Windows asar by inlining JS deps into the server bundle

• The server bundle in vite.config.ts now inlines all JS dependencies by default and keeps native/build-only packages external via a neverBundle rule, so only those external packages need to be unpacked from the asar.
• A shared cli-external-packages.ts module defines the authoritative list of external package prefixes, derives asar unpack globs, and provides findInlinedExternalPackages to scan bundle chunks for violations.
• build-desktop-artifact.ts now runs preflight checks that fail the build if external packages are inlined, native packages are accidentally bundled, or the sentinel package (effect) is not inlined (confirming self-containment).
• On Windows, the build verifies the packaged server bundle loads in isolation by running node bin.mjs --version against the unpacked asar in a temp directory, catching missing imports or escaping symlinks before artifact copy.
• The WSL preflight probe in DesktopWslEnvironment.ts now checks for node-pty availability instead of effect, since effect is no longer unpacked.
• Risk: build will hard-fail if any runtime dependency of an external package is accidentally bundled (e.g., detect-libc), requiring explicit additions to the external list.

^{Macroscope summarized 2103eb6.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f64d68f4-cfe1-4e3c-949a-2d2df8a347cf

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR substantially changes the Windows packaging strategy from unpacking all node_modules to selectively unpacking only native packages. The complexity of the new bundling logic, self-containment verification, and potential runtime impact on WSL if external packages are miscategorized warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[tsouth89]

Fair verdict, and the concern was the right one — so I went and tested it under real WSL. It found a bug. Pushed a fix in 0aacacd.

What broke. node-gyp-build-optional-packages is external, so it loads from the real filesystem, so its own require resolves from the real filesystem too. It requires detect-libc, which was not on my list and therefore got bundled — present only inside app.asar. The Windows primary reads that transparently under ELECTRON_RUN_AS_NODE and resolves it fine. Plain node under WSL cannot. msgpackr-extract failed through the same chain.

Measured on Ubuntu 24.04 with Linux node v24.18.0, against the packaged tree copied out of the NSIS payload:

before:
  MISSING (cjs) msgpackr-extract [MODULE_NOT_FOUND] Cannot find module 'detect-libc'
  MISSING (cjs) node-gyp-build-optional-packages [MODULE_NOT_FOUND] Cannot find module 'detect-libc'
  PROBE-RESULT: 2 unresolved

after:
  OK   (cjs) msgpackr-extract
  OK   (cjs) ffi-rs
  OK   (cjs) node-gyp-build-optional-packages
  OK   (esm) @ff-labs/fff-node
  PROBE-RESULT: no resolution failures

t3 --version runs from that tree under Linux node in both cases.

Why the list alone was never going to be enough. The real invariant is that an external package's entire runtime dependency closure must be external. detect-libc isn't native and doesn't look special; no amount of reading the list surfaces it. So it's now a test, not a convention: it walks each runtime-external package's declared dependencies transitively and fails if any would be bundled away. It reproduces this exact failure on the old list.

Writing that test surfaced a distinction the single list had flattened, which I've now made explicit:

• Runtime-external (native addons, their dlopen wrappers, and their closure) — Node loads these from disk, so the closure must be external.
• Build-only external (@effect/platform-bun, @effect/sql-sqlite-bun) — external purely so the bundler never resolves bun:*. Node never loads them, so their closure genuinely doesn't need to be external. The closure test skips them deliberately.

On node-pty. It still fails to load under WSL, but that is pre-existing and unrelated: this build was produced without --wsl-prebuild, which the build itself warns about, and node_modules/node-pty/prebuilds/ contains only darwin-arm64, darwin-x64, win32-arm64, win32-x64 in both the baseline and the patched build. Identical either way, so nothing here changes it. Resolution succeeds; it's the native binary for the platform that's absent.

Cost of the fix: 6 files (1,192 → 1,198). Native binaries and installer size unchanged.

Happy to squash the two commits if you'd prefer a single one.

[tsouth89]

Confirmed, both points. Good catch — the guard was worse than useless, because it reported success. Fixed in 45b4517.

Point 1 is worse than "can pass". I probed it rather than reasoning about it. From scripts/lib, every seed failed:

FAILS  node-pty MODULE_NOT_FOUND
FAILS  msgpackr-extract MODULE_NOT_FOUND
FAILS  ffi-rs MODULE_NOT_FOUND
FAILS  node-gyp-build MODULE_NOT_FOUND
FAILS  detect-libc MODULE_NOT_FOUND
FAILS  node-addon-api MODULE_NOT_FOUND
FAILS  @ff-labs/fff-node ERR_PACKAGE_PATH_NOT_EXPORTED

From apps/server only its direct dependencies resolve; the transitive packages that actually caused the WSL breakage still don't. And ERR_PACKAGE_PATH_NOT_EXPORTED is a second hole the same catch swallowed — an exports map can refuse the /package.json subpath even when the package is right there.

The tell I missed at the time: when the guard first ran it reported violations only from the @effect/platform-bun chain, and never node-gyp-build-optional-packages -> detect-libc — the bug it was written for. It never read that package.

Point 2 confirmed. !prefix.endsWith("/") dropped @yuuang/, @ff-labs/ and @msgpackr-extract/ entirely. Seeding a queue with prefix strings was wrong anyway — a prefix isn't a package name.

Fix. Manifests are now read off disk from the pnpm store, which is the same tree asarUnpack globs target: it reaches transitive packages and isn't subject to resolution or exports semantics. Seeds come from what's actually installed and matches a prefix, so scoped prefixes are covered.

Plus a guard test that fails unless node-pty, node-gyp-build-optional-packages and detect-libc are actually found, so a check that reads nothing can't report success again.

Verified by mutation, not assertion. Removing detect-libc from the list now fails with exactly the real bug:

these dependencies of external packages would be bundled away and fail to
resolve under WSL: node-gyp-build-optional-packages -> detect-libc

The previous version of the test passed with detect-libc removed. That's the difference.

39 tests pass across this file and build-desktop-artifact.test.ts; vp lint clean; @t3tools/server typecheck exits 0.

[ikifar2012]

Hey @tsouth89,

Was having trouble launching this in WSL only mode ran it though an agent and found this

line 243 in apps/desktop/src/wsl/DesktopWslEnvironment.ts

needs to be updated from:

try { require.resolve("effect"); } catch (_e) { process.exit(3); }

to this

try { require.resolve("node-pty/package.json"); } catch (_e) { process.exit(3); }

Seems like the rest of the file is fine and after modification of that one line everything seems to be working as expected

[tsouth89]

Nice find, thanks. You're right about the cause: this branch inlines the server's JS deps into the bundle, so effect isn't on disk anymore and that probe was checking for something that no longer exists. Verified against the packaged tree, require.resolve("effect") fails while require.resolve("node-pty/package.json") resolves.

Pushed your fix in 2134d96. Used node-pty since it's external precisely because it can't be inlined, so it stays a valid sentinel either way. Also updated the two comments that still described the old behaviour, and the exit-3 message downstream.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2134d96. Configure here.}

[tsouth89]

Good catch, fixed in the latest push. Reworded it to name node-pty and the native packages that actually have to be unpacked, rather than effect.

Checked the rest of the file and the tests for other references to the old sentinel while I was in there. The only remaining mentions of effect are in the comment explaining why the sentinel changed.

[t3-code]

🔴 blocker: alwaysBundle: shouldBundleCliDependency in apps/server/vite.config.ts does not force dependencies for which the predicate returns false to remain external.

As a result, transitive packages including msgpackr-extract, node-gyp-build-optional-packages, and detect-libc are still inlined in the generated bundle. Their native loader then resolves from the bundle directory and silently loses native acceleration.

I suggest using neverBundle for the external dependency list and adding a test against the emitted bundle, rather than only testing the dependency list.

Verified locally at bfd60896ebc4d9e8581153f72ee42b28bb815ea5:

• the exact head built successfully
• 39 targeted tests passed
• the packages above are present in dist/bin.mjs

I could not run the packaged Windows + WSL workflow on this Linux host, so this is not end-to-end WSL verification.

[tsouth89]

You're right on all counts. Confirmed it against the emitted bundle before changing anything: detect-libc, msgpackr-extract and node-gyp-build-optional-packages were present as full inlined //#region ../../node_modules/.pnpm/... blocks in bin.mjs.

The mechanism is that alwaysBundle is a NoExternalFn, so returning false from it means "no opinion" rather than "keep external". The default then applies, and it differs by dependency kind: node-pty and @ff-labs/fff-node are declared dependencies of apps/server so they stayed external and the packaging looked fine, while the three above are transitive and got bundled. Wired the same list to neverBundle as you suggested. Rebuilt and checked: msgpackr-extract is external again, and detect-libc and node-gyp-build-optional-packages are gone from the bundle entirely.

Also added the artifact check. findInlinedExternalPackages scans the emitted chunks for inlined externals and the desktop build now fails on one. It returns the module region count too, so "nothing inlined" is distinguishable from "the marker format changed and the scan is blind", which is the failure mode my earlier list-based test had.

Worth correcting something I said earlier in this PR: the detect-libc fix I pushed was chasing a symptom my own probe created. My probe required msgpackr-extract from disk, but the server was loading the inlined copy, so that MODULE_NOT_FOUND was never a real runtime failure. Unpacking it is correct now that msgpackr-extract is genuinely external, but the reasoning I gave for it was wrong.

On end to end: I built a Linux pty.node from source in Ubuntu 24.04, packaged an installer with --wsl-prebuild, and ran the real paths under Linux node against the extracted tree.

preflight probe:   node-pty loaded from .../prebuilds/linux-x64
msgpackr-extract:  native LOADED, resolved from
                   ~/e2e/app.asar.unpacked/node_modules/msgpackr-extract/index.js
pty spawn:         "pty-works"
server boot:       Migrations ran successfully
                   Listening on http://127.0.0.1:39225
                   0 module resolution errors

So the accelerator loads from disk rather than falling back, and the WSL backend comes up on the platform this actually matters for.

[tsouth89]

Right, the check was one-directional. Fixed in 1bac125.

The scan now reports every package it found in a region, and the build asserts effect is among them. Every server module imports it, so it is inlined in any correctly bundled build, and its absence means the dependencies went external again. That is the case you described, and the old check would have passed it.

I went looking for a general "every non-external dependency from package.json is inlined" assertion first, but a few declared deps legitimately never appear as regions once tree-shaken, so it would fail on correct builds. The sentinel avoids that without weakening the guarantee much.

Verified against the emitted bundle:

regions:              788
external violations:  none
effect inlined:       yes (209 regions)
inlined packages:     25

One thing worth mentioning from checking this: ajv's codegen emits require("ajv/dist/runtime/validation_error") and require("ajv-formats/dist/formats") as generated source strings. ajv itself is inlined, so those strings would only resolve if ajv were also on disk. I could not find a path that reaches them at runtime here, and the WSL server boots clean, but if you know that ajv standalone codegen is used anywhere I would rather add it to the external list than guess.

[t3-code]

the neverBundle fix works at current head, and the emitted bundle is correct now.

🔴 remaining blocker: scripts/build-desktop-artifact.ts:1895-1897

using only effect as the self-contained sentinel leaves a false negative for partial externalization. i reproduced this by changing alwaysBundle to inline only effect: the validator still passes because regions exist, no native external is inlined, and effect is present, while the emitted chunks retain bare imports including yaml and @effect/platform-node/*. those packages are not covered by the unpack globs, so that artifact is not self-contained for plain node under WSL.

check emitted bare imports instead: every non-builtin bare import should match the intentional external list. a bundler metafile would also work.

verified at 1bac1254:

• current server build passes
• 45 targeted tests pass
• server and scripts typechecks pass
• current emitted bundle has 664 module regions, 25 inlined packages, effect present, and no configured external package inlined
• all github checks are green

this is a guard/test blocker, not evidence that the current emitted bundle is broken. i still did not run the packaged windows + WSL flow.

[t3-code]

remaining validation problem

what is the problem?

The emitted-bundle guard at scripts/build-desktop-artifact.ts:1895-1897 treats effect as the only proof that ordinary dependencies were bundled. A partially externalized build can still inline effect while leaving other dependencies, such as yaml or @effect/platform-node/*, as bare imports. That artifact passes the current guard.

why is it a problem?

Those ordinary dependencies are not included by the narrowed asarUnpack globs. Electron on Windows may still resolve them through asar handling, but plain Node under WSL cannot read them from app.asar. The WSL backend can therefore fail with ERR_MODULE_NOT_FOUND, even though the build-time validation reported success.

I reproduced the false negative by changing alwaysBundle to inline only effect. The guard passed while the emitted chunks retained bare imports for yaml and @effect/platform-node/*.

suggested fix

Validate all bare imports in every emitted server chunk. Allow only:

• Node built-ins, including node:*;
• packages in the intentional external-package list.

Fail the build for every other bare import. Using the bundler metafile to inspect external modules would be even more robust if it is available. Add a regression test where effect is inlined but another ordinary dependency remains external.

Current head 1bac1254fd86e7f9bcb40a5dbf2cd90405b72a50 emits a correct bundle. This blocker is that the guard does not reliably prevent a future partial-externalization regression.

[tsouth89]

Replaced the static bundle checks with one that runs the artifact. After packaging, the unpacked tree is copied somewhere isolated and node apps/server/dist/bin.mjs --version runs there, so Node's resolver answers the question instead of a regex over minified source. Proved it both directions: inlining only effect fails on @effect/platform-node, dropping neverBundle fails listing the four externals, correct builds pass.

Also added a check that asks the pnpm store whether any inlined package carries a native loader, rather than trusting the list to be complete. That turned up bufferutil and utf-8-validate being inlined from the dev store. Neither is declared in this repo so neither reaches the staged install, and ws falls back to its JS paths either way, but they're listed now so it can't quietly become real.

Ran the packaged build end to end under WSL on Ubuntu 24.04 with a Linux pty.node: preflight passes, every external resolves, a pty spawns, and the server boots with no module errors.

I'm confident the packaging side is solid now.

[SunkenInTime]

Medium — the self-check still has a global-module false negative.

NODE_PATH: "" does not disable Node's built-in global CommonJS search paths. Node still searches %USERPROFILE%\.node_modules, %USERPROFILE%\.node_libraries, and the Node installation prefix, none of which are covered by ancestorNodeModulesPaths(probeApp, ...).

I reproduced this with an otherwise isolated fixture: with NODE_PATH empty, require.resolve("t3code-selfcheck-fixture") resolved from a fake %USERPROFILE%\.node_modules; the same command with node --no-global-search-paths returned MODULE_NOT_FOUND.

Because bundled code can still reach CommonJS resolution through require/createRequire, a missing packaged dependency that happens to be installed globally can make this probe report success. Please pass --no-global-search-paths before the entry point (and keep clearing NODE_PATH) so the stated “only its unpacked dependencies present” invariant is actually enforced.

[SunkenInTime]

Verified at 6a1b459: the probe now passes --no-global-search-paths before the packaged entry point and still clears NODE_PATH. Re-running the original fake-USERPROFILE fixture now returns MODULE_NOT_FOUND, and a fresh Windows x64/NSIS artifact build completes successfully with the hardened probe. This addresses the finding.

[SunkenInTime]

Reviewed current head 22731fda26c239259f29985bb4590408c17831cc, including the changes made after the previous T3 Code review.

The three existing inline threads are all genuinely addressed in the current source:

• the pnpm-store closure test now reads real transitive manifests and covers scoped prefixes;
• the WSL preflight/error text now uses the external node-pty sentinel;
• neverBundle is wired for externals, and the new packaged-tree execution probe replaces the weak one-package self-containment sentinel as the decisive runtime check.

Local verification on Windows 11 x64:

• 77/77 focused tests passed (cli-external-packages, desktop artifact, and WSL environment);
• scripts, server, and desktop targeted typechecks exited 0;
• release-equivalent x64/NSIS packaging with the Linux node-pty sidecar passed, including the new post-builder self-containment check;
• installer: 145,957,915 bytes (139.196 MiB), approximately 327.152 s from stage creation to installer output;
• unpacked packaged tree: 1,178 files / 117,575,719 bytes;
• under Ubuntu's plain Node v24.19.0, bin.mjs --version, msgpackr-extract, ffi-rs, node-gyp-build-optional-packages, detect-libc, node-pty, and @ff-labs/fff-node all loaded from the packaged tree;
• an isolated real server start completed migrations and listened on 127.0.0.1:43877; no MODULE_NOT_FOUND or ERR_DLOPEN_FAILED appeared.

The current emitted artifact therefore looks correct. I found one remaining guard hole and posted it inline: clearing NODE_PATH does not disable Node's %USERPROFILE%\.node_modules, .node_libraries, or install-prefix search paths, so a globally installed CommonJS dependency can still make the supposedly isolated self-check pass. Reproduced locally; --no-global-search-paths closes it: #5877 (comment)

My verdict is small fix requested, otherwise ready. This is a false-negative in the new regression check, not a failure of the current packaged runtime.

[tsouth89]

Confirmed and fixed in 6a1b459. Reproduced it by dropping a package into %USERPROFILE%\.node_modules:

NODE_PATH=                    -> resolved from the global folder
--no-global-search-paths      -> MODULE_NOT_FOUND

So clearing NODE_PATH was doing less than I assumed. The probe now runs with --no-global-search-paths, and the comment says why rather than just naming the flag.

Thanks for the independent packaging run as well, your unpacked file count and installer size line up with mine.

[SunkenInTime]

Re-reviewed head 6a1b459.

The new commit addresses the remaining guard issue exactly: the packaged-tree execution probe now uses --no-global-search-paths while continuing to clear NODE_PATH. The original fake-USERPROFILE fixture now returns MODULE_NOT_FOUND, closing the global CommonJS false-success path.

Fresh Windows 11 x64 verification:

• 77/77 focused tests passed;
• scripts, server, and desktop targeted typechecks exited 0;
• a fresh x64/NSIS artifact build exited 0 in 244 seconds, including the corrected post-builder self-containment probe;
• installer: 145,957,918 bytes; SHA-256 9A11BF25D4AC6AE533EC8662D02C232CE20D5895ACA8D22DE2D4C896408E6702.

No additional actionable findings. The prior issue is fixed; this is ready to merge.

[t3-code]

reviewed exact head 6a1b459eca06de813d2cf3b9a75c14c025a9b03b.

the previous blocker is fixed. the packaged-tree probe now runs the emitted cli through node with --no-global-search-paths and an empty NODE_PATH, so the earlier partial-externalization and global-module false positives are checked by node resolution itself rather than the weak effect sentinel.

no new actionable findings.

verified locally on linux:

• server build passes
• 49 focused packaging tests pass
• server and scripts typechecks pass
• isolated bin.mjs --version succeeds
• emitted bundle has 660 module regions, effect inlined, and no configured external packages inlined
• git diff --check passes
• github checks are green

code review: approved.
merge readiness: clean and mergeable.
release readiness: i did not independently run the packaged windows + wsl flow on this linux host; the pr includes successful windows/wsl artifact evidence from other reviewers.

[t3-code]

correction to my earlier approval at exact head 6a1b459eca06de813d2cf3b9a75c14c025a9b03b: i found a reproducible blocker in the new packaged-tree probe.

🔴 blocker: scripts/build-desktop-artifact.ts:1382

fs.copy(unpackedRoot, probeApp) uses node filesystem copy semantics that rewrite copied relative pnpm symlinks into absolute links pointing back into the original staged app.asar.unpacked tree. module resolution then starts from that original target and can walk into the staging app parent node_modules.

the ancestor guard only checks parents of probeApp, so it misses this escape. NODE_PATH="" and --no-global-search-paths do not stop normal parent lookup from the symlink target.

i reproduced this with a pnpm-shaped relative symlink: the copied probe had no ancestor node_modules, its copied symlink pointed into the source staging tree, and node exited 0 after loading a dependency present only in the staging app parent node_modules.

this can make the self-containment check pass while the installed WSL tree is missing a dependency.

suggested fix: preserve relative symlinks during the copy, dereference/materialize the copied tree, or reject any copied symlink whose resolved target remains outside probeApp. add the reproduced staging-parent leak as a regression test.

my previous approval was incorrect. code review is blocked until this is fixed.

[t3-code]

fixed and re-reviewed at exact head 4013ebd4b5732a23760711bc5a2d31ac69ab8b0f.

the isolated probe now rebases every in-tree pnpm link into the copied tree, rejects links that escape staging, and recreates directory links as windows-compatible junctions. the regression covers both relative and absolute source links.

verified: 50 focused tests, scripts typecheck, server build + cli smoke, formatting/lint, and github ci check/test/release smoke.

[UtkarshUsername]

I tested this branch against its merge-base commit 02f4ce5 on Windows.

WSL used to take a long time to connect. On this build the WSL backend connected in a few seconds in both dual and WSL-only mode. The app didn't get stuck on the "Connecting to WSL..." splash screen.

I also ran an A/B test vs the merge-base 02f4ce56:

metric	merge-base	this PR	change
installer size	144.64 MB	138.75 MB	-5.9 MB (-4.1%)
files installed	14,690	1,201	-13,489 (-91.8%)
install time (silent, 2 samples)	232.5s / 213.2s	116.9s / 99.9s	~2.1x faster
module load, cold (bin.mjs --version)	6.17s / 4.16s / 2.88s	4.28s / 2.74s / 2.01s	-31% cold, ~-30% warm

The biggest improvement I felt was the decrease in the time it took to connect to WSL.

Now that all issues have been resolved, I think this PR is ready to merge. @juliusmarminge