[Bug]: Windows local verification: 30 test failures + 1 gate failure in 4 root causes — fixes on 4 prepared branches (+3 findings)

[Ralle1976]

Environment: Windows 11 x64 (build 26200), Node 24.18.0, pnpm 9.12.0, no Developer Mode (no unprivileged symlink), Windows PowerShell 5.1 default. Baseline origin/main @ 44b13d3 (v0.5.2), verified 2026-09-22.

Summary

Running the Windows-relevant gates locally on current main reproduces 30 test failures + 1 gate failure — arithmetic: 11 capability (symlink EPERM) + 18 policy + 1 sandbox = 30, plus test:windows itself failing on non-elevated shells. Following up on #298's baseline, each failure was root-caused: there are four distinct causes, and each has its own single-purpose prepared branch on my fork (per the import model used in #304):

Branch	Fix	Failures retired
test/srt-macos-host-path-join	srt-macos env assertion mirrors the impl's join()	1 → fixed outright
test/policy-facade-windows-fixtures	policy facade fixtures deterministic across hosts	18 → 8 run again + 10 named skips
test/symlink-privilege-gated-skip	symlink-privilege-gated skips + Developer Mode in the windows CI job	11 → run under the privilege, named skips without it
fix/windows-source-check-fallback	NTFS preflight (#303) false-negative on non-elevated hosts	1 gate → fixed outright

After all four: 0 failures, with 21 named, reason-labeled skips on a non-privileged Windows host (census below) — 15 of which execute once the Developer Mode CI step (branch C) or a local Developer Mode is in place.

The symlink-privilege branches overlap by zero cases (the 4 policy symlink cases live in local-permission-facade.test.ts; the 11 capability cases in 4 other files). Count check: branch B retires 8+6+4 = 18 ✓.

Branch A — srt-macos path-separator assertion (1 failure)

packages/local-runtime-v2/src/service/sandbox/backend/srt-macos.test.ts:197 asserted the hardcoded literal "/tmp/session-1/git-templates-empty" while the implementation computes the value with node:path.join() (srt-macos.ts:129), which renders \tmp\... on Windows. Fix: build the expected value with join() too — byte-identical to the literal on POSIX. Tradeoff stated plainly: the assertion becomes "the env value is the join of the sandbox temp dir and git-templates-empty" rather than a fixed POSIX string. A skip was rejected because it would hide one separator mismatch, and gating the whole file would drop 19 currently-passing Windows cases.

Branch B — policy facade fixtures are host-dependent (18 failures)

packages/local-runtime/test/unit/local-permission-facade.test.ts failed 18 of 142 on Windows with three fixture/host causes:

1. Silent host-dependent platform. freshFacade only threaded platform to the facade when a test set it explicitly, so un-pinned tests exercised the Windows decision path on Windows hosts and the POSIX path everywhere else. The suite's intent is POSIX semantics (test:policy is gated platforms: ["darwin","linux"] in scripts/verify.mjs — CI never saw these failures). The simulation now defaults to 'darwin' on Windows hosts (explicitly, with a comment) and is always passed through. Restores 8 decision-logic cases (they run again instead of failing on host artifacts).
2. NTFS cannot express Unix execute bits. inspectTrashRuntime's POSIX branch requires mode & 0o111, which can never be true on NTFS (chmod is a no-op for Unix bits there), so a Windows host simulating POSIX always saw "mavis-trash is not executable". The check is now host-aware. No production path changes: the POSIX branch only runs with a simulated POSIX platform.
3. 10 remaining cases gated with named skips and precise reasons (see census): 6 hit a path-rendering boundary — the simulated platform does not reach the path resolution, so POSIX-style inputs resolve to C:\-style paths and containment asks where the test expects allow (evidence: a decision dump showed resolved: \tmp\private-output.log and Path: C:\tmp\private-output.log against rule C:\tmp/**, i.e. the glob never matched). Threading the simulated platform through the permission engine's path rendering would fix these, but that engine is security-adjacent and its suite is deliberately POSIX-only in the verify matrix — leaving that refactor to the team (happy to do it on request). 4 need the symlink privilege (branch C's probe).

Branch C — symlink-privilege-gated skips (11 failures) + CI step

fs.symlink on Windows requires Developer Mode or admin. The 11 cases across canonical-agent-config.test.ts (6), agent.repository.test.ts (3), mcp/project-config.test.ts (1), headless-invocation.test.ts (1) all die with EPERM: operation not permitted, symlink. These exercise link-following safety logic and are worth running wherever the host can create links, so instead of gating them to POSIX each file now probes the privilege lazily (memoized fs.symlinkSync probe) and gates with skipIf(process.platform === "win32" && !canSymlink()) — with the privilege (Developer Mode or elevated) they run exactly as before.

Companion CI step (same branch, separate commit): enable Developer Mode in the windows-latest job so these 11 run in CI instead of skipping:

- if: ${{ runner.os == 'Windows' }}
  run: reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 1 /f

GitHub-hosted Windows runners run elevated, so this is one line before pnpm verify. Framing note: "green by reclassification" was deliberately rejected as the only fix — #238 paused Windows CI "while checks are made reliable", and the skips are labeled deferred coverage pending this CI change, not a cleanup.

Skip census

File	Cases gated	Condition	Runs with Developer Mode?
local-permission-facade.test.ts	6	Windows path-rendering boundary (branch B.3)	no — needs the engine follow-up
local-permission-facade.test.ts	4	symlink privilege	yes
canonical-agent-config.test.ts	6	symlink privilege	yes
agent.repository.test.ts	3	symlink privilege	yes
mcp/project-config.test.ts	1	symlink privilege	yes
headless-invocation.test.ts	1	symlink privilege	yes

Totals: 21 named skips on an unprivileged Windows host; 15 of them execute under the privilege (CI step above or local Developer Mode).

Branch D — the #303 NTFS preflight false-negatives on non-elevated hosts

Found while verifying this branch series: pnpm verify --profile windows fails at test:windows on my machine — and would fail for any contributor without an elevated shell. scripts/check-windows-source-location.mjs shells out to fsutil fsinfo volumeinfo, which on stock Windows 11 answers non-elevated processes with Fehler 5: Zugriff verweigert (exit 1); the preflight then reports "Windows could not verify the checkout volume" and rejects a checkout that is in fact on local NTFS (vol C: and Get-CimInstance Win32_LogicalDisk both report NTFS from the same shell). CI never caught it because GitHub-hosted Windows runners run elevated.

Fix: keep fsutil as the fast path and fall back to one elevation-free Get-CimInstance Win32_LogicalDisk query (locale-invariant FileSystem/DriveType properties) when fsutil is denied; the existing verdict checks stay the single source of truth. Regression tests cover all outcomes: fallback-NTFS passes (this bug), fallback-FAT32 and fallback-non-fixed reject, both-unavailable fails closed with both error messages, allowNonFixed, and the untouched fsutil fast path.

Finding 1 — the 14 PowerShell 5.1 regression tests from #304 run in no CI leg

packages/local-runtime/test/unit/child-bash-lifecycle.test.ts (the Windows PowerShell 5.1 exit codes suite added in #304) is declared in the capability group (test/vitest-suites.json), but test:capabilities carries no windows: true flag in scripts/verify.mjs, so the windows profile skips it — while the full profile runs on ubuntu (where the suite's skipIf(process.platform !== 'win32') skips the 14 cases). Net: the regression coverage that justified #304 executes only on developer Windows machines, never in CI. Suggested (small): add windows: true to test:capabilities, or move/copy the PS-5.1 suite into the windows group. With branch C's CI step, the capability group is viable on windows-latest.

Finding 2 — Windows tmpdir-under-home widens a containment auto-allow (product behavior, not test artifact)

One policy case (turn-scoped trusted exact writes > allows only the supplied exact Plan target…) expects an ask but observes allow on Windows. Root cause: os.tmpdir() resolves under %USERPROFILE% on Windows, so the working-directory-containment path (facade.ts resolveWorkingDirectory home fallback + the fs-permission containment step) treats temp writes as contained and auto-allows what the test expects to ask. If the same rule applies to real sessions, %TEMP% writes are auto-approved on Windows where a POSIX host would ask. Branch B gates the case with that reason — the behavior difference itself is left to you deliberately: containment semantics are a product call. Happy to root-cause the intended semantics in a follow-up.

Finding 3 (context) — the windows profile's test surface

Related to Finding 1: pnpm verify --profile windows currently runs no vitest groups except the 2-case windows contract (scripts/verify.mjs:40-81; policy is darwin/linux, sandbox is darwin, and capability/smoke/byok/status-contract have no windows: true). With branches B+C and the CI step, the policy and capability groups become viable on windows-latest; extending the profile is then a one-flag change each. Not proposing it here — that is a CI-design decision.

Validation & boundaries

Per branch, on the environment above (2026-09-22):

Branch	Check	Result
A	pnpm test:sandbox	26 passed, 22 skipped, 0 failed (was 1 failed)
B	pnpm test:policy	132 passed, 10 skipped, 0 failed (was 124 passed, 18 failed); pnpm typecheck clean
C	vitest run of the 4 affected files	188 passed, 11 skipped, 0 failed (was 11 EPERM failures); pnpm typecheck clean
D	pnpm test:windows + real CLI preflight	8/8 (was 7/8 with the real-host case failing); CLI exit 0 (was exit 1)

Context number: full pnpm test:capabilities on the rebased #298 branch (baseline + those fixes) = 11 failed / 4369 passed / 60 skipped — exactly the 11 symlink-EPERM cases this issue's branches address.

Not run: macOS/Linux hosts (each fix is a no-op on POSIX by construction — gates short-circuit before the probe and the render fix mirrors the impl's join — but no POSIX run was executed here), a privileged Windows host for branch C's cases (they run unchanged with the privilege; the probe only affects the skip predicate), full pnpm verify per branch, live-model runs, Desktop app.

[hetaoBackend]

This was generated by AI during triage.

Thanks for the exceptionally thorough report — root-causing 30 failures + 1 gate failure into four independent causes, each with a single-purpose prepared branch and a zero-overlap count check, is exactly the shape of contribution that is easy to review.

Initial assessment per branch:

• A (srt-macos join() assertion) — agreed this is a straightforward test bug: asserting a hardcoded POSIX literal against a node:path.join()-computed value can only pass on POSIX. Building the expectation with join() is the right fix and stays byte-identical on macOS/Linux.
• B (policy facade host-dependent fixtures) — deterministic fixtures + named, reason-labeled skips is the right direction; reviewers will want to check that the 10 named skips don't mask genuinely portable assertions.
• C (symlink privilege gating + Developer Mode CI step) — privilege-gated skips are reasonable; the CI job change needs maintainer review since it touches the workflow.
• D (NTFS preflight false-negative on non-elevated hosts) — plausible follow-up to fix(windows): clarify source checkout requirements #303; will be reviewed together with [Bug]: Source build on non-NTFS/cloud-synced Windows volumes fails cryptically (pnpm workspace links need junctions) #299.

Next step: please open the four branches as separate PRs (smallest first — A and D are likely quick to land). Per repo policy each PR should pass the applicable pnpm verify profile and note which gates were actually run on Windows.

Triaging as bug + cli + needs-triage until maintainer review of the branches.

[hetaoBackend]

This was generated by AI during review.

Reviewed the four branches as actual diffs against origin/main @ 44b13d3, not just the write-up. All four root causes reproduce against current main — the evidence holds up. Below is per-branch feedback plus one priority correction.

Priority correction: which failures actually block anyone

The write-up presents the 30 failures as one flat set, but scripts/verify.mjs platform-gates them very unevenly:

• test:policy is platforms: ["darwin","linux"] (verify.mjs:64-66) and test:sandbox is platforms: ["darwin"] (verify.mjs:69) — neither runs on a Windows host under any profile. So branch A's 1 failure and branch B's 18 are reachable only by invoking pnpm test:policy / pnpm test:sandbox directly.
• test:capabilities (verify.mjs:57) has no platforms restriction, so it does run when a Windows contributor runs the default full profile — branch C's 11 EPERM failures genuinely break pnpm verify there.
• test:windows (verify.mjs:58) runs in both the windows and full profiles on a Windows host — branch D is a hard blocker.

So the landing order we'd like is D → C → A → B, and the weight is very different from the issue's presentation. D is the most valuable of the four: it is a real contributor-facing regression from #303, not a test artifact — any contributor without an elevated shell is rejected by a preflight even though their checkout is on local NTFS, and elevated GitHub runners can never catch it.

Branch A — ready, please open the PR

join is already imported at srt-macos.test.ts:14, and the expectation is byte-identical on POSIX. No objection.

Nit (non-blocking): the change retypes the literal "/tmp/session-1" rather than referencing the fixture's sandboxTempDir, so the assertion can drift if the fixture changes. Deriving it from the same input would be slightly more robust.

Branch D — right direction, one implementation change requested

The fallback is well-behaved where it matters: volume is already constrained by the /^[a-z]:\\$/iu check before interpolation, and a missing/unknown volume yields an empty FileSystem, so the NTFS check fails closed. The regression tests land in test/windows-contract.test.mjs, which test:windows really does execute on the Windows leg — good.

One change before we take it. This part re-encodes the CIM result back into fsutil's text format so the existing regexes keep matching:

driveType = `DriveType : ${driveNumber === "3" ? "DRIVE_FIXED" : "DRIVE_OTHER"}`;
volumeInfo = `File System : ${fsName}`;

That couples two independent data sources to one tool's output formatting; a later tightening of the fsutil regexes would silently break the fallback path with no test signal. Please normalize both sources into a structured intermediate (e.g. { fileSystem, isFixed }) and have the verdict checks read that. The verdict logic stays the single source of truth, which is what you were going for anyway.

Branch C — take the test commit, hold the CI commit

The privilege probe and skipIf gating are fine: memoized, and short-circuited on non-Windows so the probe never runs there.

The reg add AllowDevelopmentWithoutDevLicense commit should be split out and held, for two reasons:

1. It currently changes nothing. The 11 symlink cases live in the capability group, and the Windows leg runs --profile windows, which skips test:capabilities (no windows: true). Until that flag is added, the step cannot make those cases execute. You identify this yourself in Finding 1/3 — but it means the CI commit is inert in the branch that ships it.
2. GitHub-hosted Windows runners already run elevated, so they already hold SeCreateSymbolicLinkPrivilege. The same premise you use to justify the step also makes Developer Mode redundant there.

Please open branch C as the test-gating commit only. Whether to extend the Windows profile to test:capabilities is a CI-design decision we'll take separately (see the last section).

Branch B — please narrow the scope before we review it

Two problems.

1. It changes production code, contrary to the stated boundary. The issue says "No production path changes", but the branch modifies packages/local-runtime/src/infra/ensure-trash-script.ts:

-      if ((statSync(scriptPath).mode & 0o111) === 0) {
+      if (process.platform !== 'win32' && (statSync(scriptPath).mode & 0o111) === 0) {

The reasoning is given right after, so this is not a disclosure problem — but a security-adjacent production diff inside a branch titled test(policy): make fixtures deterministic is easy for a reviewer to miss. Please call it out in the PR title/description.

2. The change is at the wrong layer. inspectTrashRuntime is already platform-injectable — ensure-trash-script.ts:116-120 takes platform and probe parameters, and facade.ts:1129 passes the facade's simulated platform. Introducing a real-host process.platform test into that function removes its pure input-to-output contract: the same arguments now produce different verdicts on different hosts, which is precisely the host-dependence the branch sets out to eliminate on the test side. The resulting branch is also dead in production — on POSIX the new condition is always true (behavior unchanged, zero coverage), and Windows production takes the platform === 'win32' path and never reaches it. Net effect: a branch in a production security path that only ever executes under test.

If this accommodation is needed, please widen the existing injection seam instead of sniffing the host — the function already accepts platform and probe, so an injectable executable-bit check fits the existing design.

3. Cost/benefit on the skips. Because test:policy never runs on Windows in any profile, these 18 failures block no gate today, while the branch adds 10 permanent skip predicates to a security-critical suite. We would rather not carry that.

Suggested split: keep the freshFacade change that pins the simulated platform explicitly and always threads it through — removing silent host dependence from a fixture is a clean win on its own, and we'd take that. Drop the ensure-trash-script.ts change and the 10 skips; we'll record the remaining Windows-host behavior as a known limitation on this issue instead.

Finding 2 — tracked separately

This is the one with product implications rather than test implications, and we'll pick it up on our side. For the record, the code path is consistent with your description: facade.ts:1045-1061 resolveWorkingDirectory falls back to homedir() when there is no session or agent workspace, and that value is threaded into createToolPermissionContext as the containment boundary. On Windows os.tmpdir() sits under %USERPROFILE%, so the fallback covers temp writes that a POSIX host would leave outside $HOME. Notably the sibling resolveExplicitWorkspaceDirectory (same file, immediately below) carries a comment stating that the home/dataDir fallback "must not become a write/delete safety boundary" — so the hazard is already recognized for write/delete, just not on this path. We'll open a separate issue; no need for you to carry it.

Findings 1 and 3 — our follow-up, not yours

You're right on both, and together they describe the actual structural problem: the Windows profile currently executes essentially no vitest coverage — only the windows group — because policy and sandbox are platform-locked and capability carries no windows flag. That also means #304's 14 PowerShell 5.1 regression cases run in no CI leg at all. Restoring a meaningful Windows test surface after #238 is ours to schedule, and branch C's CI step belongs to that work rather than to a test-portability PR.

Next steps

1. Open D (with the normalization change above) and A as PRs — these are the two we can land quickly.
2. Open C as the test-gating commit only; leave the workflow change out.
3. For B, open only the freshFacade platform-pinning part if you'd like it landed; otherwise we'll close that thread with the limitation recorded here.

Each PR should note which gates were actually run and on what host, per CONTRIBUTING.md. Thanks again — the branch-per-cause structure with the zero-overlap accounting made this genuinely fast to verify.