Thanks for this, and sorry for the delayed acknowledgement. Queued for review.

A +19/-2 single-file change is easy to review — nothing blocking from a size standpoint. CI shows 1-2 failing checks worth checking while it waits.

PowerShell 5.1 wrapping stderr and thereby aborting verification is a nasty class of bug: it makes a working install look broken for reasons that have nothing to do with the install. Good catch.

Great catch, and a textbook writeup. The hazard is real and still live on current main — I verified it rather than taking your word for it: install.ps1:8 sets $ErrorActionPreference = "Stop" globally, and both probes run bare underneath it (:259 and :327). PowerShell 5.1 wraps redirected native stderr in ErrorRecords, so under Stop the first stderr line becomes terminating — meaning a healthy binary that prints any warning to stderr while exiting 0 aborts the install with "downloaded binary failed to run".

That is exactly the kind of latent installer bomb that only detonates the day the binary prints its first warning, and with the daemon work adding warning paths it is a plausible one. Your scoped try/finally with detection kept on $LASTEXITCODE is the right conservative shape — the failure path is untouched, and the restore is exception-safe.

Thank you for the pure-ASCII discipline. I byte-scanned the patch and it is clean, comments deliberately avoiding em-dashes. We have been burned by a single non-ASCII character in this exact file before — PowerShell 5.1 decodes a BOM-less .ps1 as ANSI and one em-dash injected a stray quote that made install.ps1 unparseable on main. Not everyone knows that; you clearly did.

Three things needed, all small:

1. A mechanical rebase. Main removed the launcher stub (a54ea95), so $DownloadedLauncher is now $DownloadedBinary and the probes sit at install.ps1:259 and :327. Your fix survives the rename intact. Worth knowing: the literal invariant pinned at tests/test_windows_bundle_contract.sh:206 requires the substring & $DownloadedBinary --version, and the rebased line still contains it since 2>&1 comes after — so that contract stays green.

2. One hardening ask — a narrow false-pass window. With EAP=Continue, a binary that fails to launch (corrupt or wrong-architecture image, as opposed to exiting nonzero) may surface as a non-terminating error, in which case $LASTEXITCODE is not updated. For probe 1 that fails safe: no native command has run yet, so $LASTEXITCODE is $null and the -ne 0 check throws. But probe 2 has prior native calls before it (probe 1 exiting 0, and & $Dest daemon stop), so a stale 0 could false-pass a corrupt install and print "Installed: …" alongside an error record. Pre-fix, EAP=Stop promoted that to terminating and aborted correctly.

Pre-seeding $global:LASTEXITCODE = 1 inside each relaxed block before the call closes it, and costs nothing. If you get the chance on your 5.1 box, it would also be genuinely useful to confirm how a start-failure actually surfaces there — I could not settle that from source alone.

3. Yes please to the test you offered. You mentioned you would add a harness test if pointed at the right place: a stderr-writing stub under the Windows VM win.sh smoke-install/guards family is the right home. Worth saying why it matters — our real-Windows smoke leg runs install.ps1 but with a stderr-quiet binary, so it would not have caught the original hazard either. At minimum, a contract pin on the EAP save/restore block would stop the fix being silently removed later.

With the rebase and the pre-seed this merges. Thanks for a precise, well-scoped fix.