3.9 KiB
Windows empty-profile startup verification
Follow-up to #2345, including @gefrezim's diagnosis of the import-time Windows home lookup.
Source and boundary
Baseline: main 172407787f1842dedbcd27b5385177595f786ce4. Verification used
the real Windows 11 10.0.22631.0 host, official Windows x64 Node 24.18.0,
locked production dependencies and REA's compiled public CLI / SDK 2.3.1 MCP
server. No IDA or Ghidra engine was used. Runtime copies and compact receipts
live outside the checkout; no account profile path or ambient environment is
recorded here.
The tested dispatcher SHA-256 is
526105418604cc6e5a202a6275b700814e27450bfaffd45e7510530ba669de8d.
Only the dispatcher changed in the deployed runtime. It treats an empty Windows
USERPROFILE as unset before dependency imports. Nonempty selections continue
to reach the existing home resolver; no additional lookup or fallback owner is
introduced.
Real Windows observations
With HOME empty in each case, the baseline produced:
| USERPROFILE selection | --version |
--help |
MCP discovery |
|---|---|---|---|
| Unset | Exit 0 | Exit 0 | Healthy |
| Empty | Exit 1, uv_os_homedir |
Exit 1, uv_os_homedir |
Healthy |
| Nonempty test-owned profile | Exit 0 | Exit 0 | Healthy |
The corrected CLI passed all six invocations with no stderr. Version output remained 6 bytes and help output 15,497 bytes. Real setup dry runs with empty and nonempty profile selections both exited 0, planned their configuration under the expected home, preserved existing configuration bytes and created no configuration under the working directory. No installation was performed.
MCP was already healthy in the baseline; this change does not claim to repair
an MCP startup failure. Complete baseline discovery was 187 tools and 2,545,790
serialized bytes, SHA-256
1e6bbca7f62852134eb703ea098f5a302d1fe333b8433475429f6fc1b1aba18f.
All three corrected MCP controls also passed with no stderr and the same
catalogue bytes and digest.
The existing homeDirectoryFallback acceptance test exercises the import-time
failure through the public setup dry run. Adding it to the Windows curated lane
makes that regression execute on the affected platform. No duplicate startup
test was retained. Nine related tests passed, including the existing MCP doctor
and curated-lane path checks; Linux passing alone does not prove Windows behavior.
Review caught a missing package-scope registration for the newly listed test;
the original CI shard failed that ownership invariant. The path is now also
registered in scripts/ci/scopes.mjs, and all 84 scope checks plus the two
curated-path checks pass. Runtime source and its tested digest are unchanged.
Efficiency and resource limits
Heavy host probes ran serially at BelowNormal priority, with one CPU and a
512 MiB CLI/server heap setting (256 MiB for the probe parent). Heap settings do
not bound total process memory. An exit-time process.resourceUsage() observer
recorded individual corrected CLI invocations: CPU time ranged from 7.968 to
9.874 seconds and peak working set from 299,956 to 301,852 KiB. These figures
exclude the probe parent and any observer overhead outside the CLI process.
The six observed wall times ranged from 8.656 to 10.961 seconds.
The baseline did not use that resource observer, and cold/warm caches were not normalized. These observations establish functional behavior and bounded probe scope; no CPU, memory or latency improvement is claimed. The fix adds one constant-time environment check, no filesystem lookup, engine call, retry or cache. Output bytes are not model tokens; actual model usage was not measured.