Repository navigation
Windows sandbox: npm test fails and node --test hangs inside the AppContainer #101
Description
Problem
Inside the Windows AppContainer sandbox (sandbox-helper.exe), the standard Node.js test commands do not work:
npm testandnpm.cmd testexit with code 1.node --test(with no arguments, with a folder, or with a single file) hangs until the command times out.
This happened in every run that tried these commands during the plan-mode benchmark on 2026-10-05: 24 runs on two builds, Claude Sonnet 5.5, small projects whose package.json has "test": "node --test" and that need no dependencies. The model then tried variations (cmd /c npm test, --test-isolation=none), so each run took 150–200 s instead of about 15 s. The benchmark's own check ran the same tests unsandboxed and they passed, so the projects themselves were fine.
Failed calls recorded by the benchmark (toolsByName / failedTools in out/bench-agent-tasks-plan.json):
run_command: Ran `npm test` (exit 1)
run_command: Ran `npm.cmd test` (exit 1)
run_command: Ran `node --test` (timed out)
run_command: Ran `node --test test/strings.test.js` (timed out)
run_command: Ran `node --test --test-isolation=none test/strings.test.js` (exit 1)
The helper source is the same on main (37f8bb6) and in PR #92, and both builds behaved the same way.
Possible causes to check
- npm needs folders under the user profile that the AppContainer cannot reach (
%APPDATA%\npm-cache,%LOCALAPPDATA%\npm-cache,.npmrc), and the home folder is hidden. TEMP/TMPpoint to%LOCALAPPDATA%\Temp, which is not granted. The Windows policy grants no temporary folder, unlike the other backends (see also security: narrow macOS sandbox file access and isolate command temp directories #96 for macOS).node --teststarts a child process for each test file and talks to it over pipes. Check whether creating those pipes fails or blocks under the AppContainer token or the job object's limits.
Use the existing Vitest integration tests (sandbox_windows.integration.test.ts) or focused instrumentation in the helper to find out. Do not launch the helper through nested PowerShell with redirected stdin (see AGENTS.md).
Acceptance checks
- A real Windows integration test runs
npm testandnode --teston a dependency-free fixture project inside the sandbox, and both pass. - Any temporary folder or cache granted for this is per command (or limited to the project) and does not expose the rest of the profile.
Activity
stepupgaming commentedon Oct 5, 2026
On this machine the failure is earlier than a hang.
C:\Program Files\nodejshas noALL APPLICATION PACKAGESACE, andwindowsPolicydoes not grant Program Files, sonodeandnpmare not visible at all. Details are in #106. The hang described here can still show up once the binary is readable.fix: isolate Windows sandbox npm runtime paths
fix: explain the Windows sandbox Node test hang when a command times out
PierrunoYT commentedon Oct 7, 2026
Status: blocked upstream. The Patch side is done. What's left needs a Node.js release that bundles libuv ≥ 1.53, and none does yet.
Cause
In libuv ≤ 1.52.1,
uv__unique_pipe_namenames every child-process stdio pipe\\?\pipe\uv\<n>-<pid>. An AppContainer may only create named pipes under\\.\pipe\LOCAL\…(see theCreateNamedPiperemarks), soCreateNamedPipeAfails withERROR_ACCESS_DENIED.uv__pipe_servertreats that error as a name collision, increments the name and retries forever. That's whynode --test(one child process per test file) hangs until the command timeout instead of failing. The same applies to any sandboxed Node program that spawns children with piped stdio.Upstream status (checked 2026-10-07)
TokenIsAppContainerand addsLOCAL\to the pipe name.main,v26.xandv24.x(since 24.16) bundle libuv 1.52.1.v22.xbundles 1.51.0. I found no Node release and no open update PR with 1.53.Why Patch can't work around it
LOCAL\. Compiler Explorer hit the same limit (ninja#2354).ERROR_ACCESS_DENIEDand keep looping.node.exeto rename the pipes, shipping a patched Node, or adding--test-isolation=noneto commands automatically.What is done
3ac2d97: private per-command temp folder, npm cache and empty npm user config; project PATH entries use the mapped drive; process-only PowerShell execution policy.npm test,npm.cmd testandnode --testpass with--test-isolation=nonein the real Windows integration tests.1311572: when a command in the Windows AppContainer times out, therun_commandresult tells the agent why. It names--test-isolation=none(--experimental-test-isolation=noneon Node 22) and theunsandboxedrequest. The command is never rewritten. This targets the 150–200 s benchmark runs where the model retried variations blindly.To close this issue
Once a Node release bundles libuv ≥ 1.53, run
sandbox_windows.integration.test.tson that runtime. Its default-isolationnode --test/npm testchecks stop skipping on libuv ≥ 1.53, and they cover the first acceptance check. The timeout hint can be removed once the minimum supported Node includes the fix.PierrunoYT commentedon Oct 9, 2026
Upstream status (2026-10-09): libuv 1.53.0 was released on 2026-09-24, and Node.js has an open automated PR to adopt it, nodejs/node#66282 (opened 2026-09-25, not merged yet;
deps/uvonmainis still 1.52.1). Once a Node.js release ships it, re-run the Windows sandbox integration tests for defaultnode --testand drop thetest-isolation=nonehint if they pass. Notes:docs/WINDOWS_SANDBOX_RESEARCH.md.