Summary
The new bwrap execution suite fails on Windows and will keep the Windows leg of the nightly red. It landed in 3486cd8f86 (feat(core): Add the bwrap execution foundation, #12067) at 2026-09-19T13:54:30Z — the file does not exist at the 2026-09-18 nightly revision, and the same revision's Ubuntu leg is green — so this is a new, host-specific failure rather than a flake or a pre-existing one.
Evidence
Windows job of a manual lane dispatch, run 35451653395 / job 105919765167, which checked out b914fbc1e5807f80e9056b51d365fbb541d80d5a (main at ef16196c plus a test-only change in an unrelated file):
FAIL src/sandbox/bwrap-execution.test.ts > bwrap execution adapter > allows a temporary root that contains disjoint sandbox roots
FAIL src/sandbox/bwrap-execution.test.ts > bwrap execution adapter > builds a literal launch, filters internal secrets, and cleans confirmed resources
FAIL src/sandbox/bwrap-execution.test.ts > bwrap execution adapter > rejects an overlapping temporary root before launching or leaking control state
FAIL src/sandbox/bwrap-execution.test.ts > bwrap execution adapter > reports a throwing post-promote settle callback
FAIL src/sandbox/bwrap-execution.test.ts > bwrap execution adapter > retains evidence only when an existing receipt leaves execution uncertain
FAIL src/sandbox/bwrap-execution.test.ts > bwrap execution adapter > uses an absolute scratch root for a relative TMPDIR without leaking it
Test Files 1 failed | 760 passed | 9 skipped (770)
Error: Sandbox assets are missing. Run the build and bundle first.
❯ sandboxAsset src/sandbox/bwrap-execution.ts:61:11
❯ Module.executeBwrap src/sandbox/bwrap-execution.ts:109:17
❯ src/sandbox/bwrap-execution.test.ts:181:26
In the same run, job 105919765082 (Ubuntu, same checkout) succeeded, and the macOS job's log contains zero occurrences of Sandbox assets are missing. The failed file is the only failed file in the Windows core run.
What I can establish about the cause
The suite forces the platform it believes it is on (vi.spyOn(process, 'platform', 'get').mockReturnValue('linux')), so on a Windows host it still takes the bwrap execution path; that path resolves a sandbox asset from disk (a sibling, otherwise a bundled name) and throws when neither exists. On the Windows test host neither candidate is present, so the resolver raises the build-flavoured error instead of the suite being skipped. Since bubblewrap itself is Linux-only, the suite cannot be meaningful on Windows unless its assets are provided or stubbed there.
I have not pinned why the asset is absent on that host specifically — the Windows job's step list and the asset's origin need a look from someone who knows this module's packaging, so I am reporting the failure with the evidence rather than guessing at a mechanism.
Impact
Tonight's nightly (2026-09-19) will be red on Windows again, for this file rather than the one fixed in #12262 — which is exactly the situation that makes the Windows lane useless as a regression signal (see #12262 for the chain of nightly failures since 2026-09-11).
Suggested directions
Either gate the suite to the platforms that can actually run the adapter, or stub the asset resolution so the suite keeps its cross-platform coverage. I have no preference and have not opened a PR, since this is the author's call on a module that merged hours ago.
Reproduction
Dispatch the CI workflow with a branch_ref pointing at any revision containing #12067 (a manual dispatch is the only way to reach the Windows leg, because it is gated off for pull requests), then read the Test (windows-latest, Node 22.x) job's core test summary.
Summary
The new bwrap execution suite fails on Windows and will keep the Windows leg of the nightly red. It landed in
3486cd8f86(feat(core): Add the bwrap execution foundation, #12067) at 2026-09-19T13:54:30Z — the file does not exist at the 2026-09-18 nightly revision, and the same revision's Ubuntu leg is green — so this is a new, host-specific failure rather than a flake or a pre-existing one.Evidence
Windows job of a manual lane dispatch, run 35451653395 / job 105919765167, which checked out
b914fbc1e5807f80e9056b51d365fbb541d80d5a(main atef16196cplus a test-only change in an unrelated file):In the same run, job 105919765082 (Ubuntu, same checkout) succeeded, and the macOS job's log contains zero occurrences of
Sandbox assets are missing. The failed file is the only failed file in the Windows core run.What I can establish about the cause
The suite forces the platform it believes it is on (
vi.spyOn(process, 'platform', 'get').mockReturnValue('linux')), so on a Windows host it still takes the bwrap execution path; that path resolves a sandbox asset from disk (a sibling, otherwise a bundled name) and throws when neither exists. On the Windows test host neither candidate is present, so the resolver raises the build-flavoured error instead of the suite being skipped. Since bubblewrap itself is Linux-only, the suite cannot be meaningful on Windows unless its assets are provided or stubbed there.I have not pinned why the asset is absent on that host specifically — the Windows job's step list and the asset's origin need a look from someone who knows this module's packaging, so I am reporting the failure with the evidence rather than guessing at a mechanism.
Impact
Tonight's nightly (2026-09-19) will be red on Windows again, for this file rather than the one fixed in #12262 — which is exactly the situation that makes the Windows lane useless as a regression signal (see #12262 for the chain of nightly failures since 2026-09-11).
Suggested directions
Either gate the suite to the platforms that can actually run the adapter, or stub the asset resolution so the suite keeps its cross-platform coverage. I have no preference and have not opened a PR, since this is the author's call on a module that merged hours ago.
Reproduction
Dispatch the CI workflow with a
branch_refpointing at any revision containing #12067 (a manual dispatch is the only way to reach the Windows leg, because it is gated off for pull requests), then read theTest (windows-latest, Node 22.x)job's core test summary.