fix(update): stop Windows updates from locking their own launcher

[OutThisLife]

On Windows, hermes update started from venv\Scripts\hermes.exe can never succeed. The launcher runs the interpreter with the shim as its script and holds it open without FILE_SHARE_DELETE for the whole command, so the dependency sync has to replace a file it is itself holding: the quarantine rename is refused and uv fails with os error 32. No Desktop, gateway or antivirus involvement is required, and the concurrent-instance preflight cannot catch it because it excludes this process and its ancestors by design. The ZIP fallback repeats the same sequence, so the update reports progress while the editable install stays stale.

This consolidates the two open attempts at the bug into one fix and closes the gaps neither covered.

What changed

The update re-runs itself off the shim. When cmd_update detects that it was launched through one of this venv's console shims, it re-runs the same argv as venv\Scripts\python.exe -m hermes_cli.main ... and returns, releasing the shim before the child installs anything. Detection reads both the process ancestry and this process's own launch paths — sys.argv[0], __main__.__file__, the module spec origin — because the runpy/zipapp launch puts <shim>\__main__.py there and an argv[0] check alone misses it. Candidates are intersected with the venv's own shims, so a hermes.exe from another install never triggers a hand-off.

The hand-off runs ahead of the update lock. Placing it later means the child adopts the parent's marker by ancestry and the parent then releases it, leaving the update running unlocked.

The reboot-deferred rename is gone. MOVEFILE_DELAY_UNTIL_REBOOT was the quarantine's last resort and it is worse than doing nothing: it writes to HKLM, so every non-elevated update gets ERROR_ACCESS_DENIED silently, and when it does land it frees nothing for the install in flight while queueing an operation that moves aside whatever sits at the shim path at next boot — including a shim a later repair just wrote. Entries queued by older versions are now swept, matching only our own <shim> → <shim>.old.<stamp> pairs so other installers keep theirs.

Gateway /update no longer goes through the shim on Windows; it runs as a module under the interpreter the gateway already uses.

The venv is resolved as venv or .venv. uv venv writes .venv and our installers write venv, but every lookup hardcoded venv. On a .venv install _venv_scripts_dir() returned None, which silently disabled the shim preflight, the quarantine and the console-script verification — so any fix gated on it would have been a no-op there.

Verification

47 tests across the update/quarantine/recovery suites pass, including 21 new ones covering every launch variant, the venv scoping, the re-exec's argv and env marker, its loop guard and both fall-through paths, the pending-rename filter, and the venv/.venv split. ruff and the blocking Windows-footgun lint are clean on the diff.

Trade-off

The process the shell waited on exits as soon as the child is spawned, so hermes update's exit code reflects the hand-off rather than the update. A synchronous wait is not available here — this process exiting is the fix. The update prints its own result, and --gateway writes the true exit code to .update_exit_code before the gateway restart, which the watcher still reads. Anything that blocks the hand-off (no venv python, spawn refused) falls through to the previous in-process behaviour with the manual command printed, so a broken venv still gets whatever the update can do.

Credit

Supersedes #89970 and #88121, whose authors each had a piece of this. The automatic re-exec, the launch-variant detection and the gateway spawn fix come from @Akloenx123's #89970. Removing the reboot-deferred rename and sweeping the stale pending-rename entries come from @fangliquanflq's #88121. @jrleal10 reproduced the failure on native Windows 11 on both main and #88121, which is what made the shared root cause legible.

Supersedes #89970, #88121
Fixes #88838, #89599, #86093, #88078
Refs #79542, #89295, #79561

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 268615c — test(update): cover the Windows shim self-lock class}

⚠️ Warnings

OSV vulnerability scan · View job

7 known vulnerabilities found in pinned dependencies.

• CVE-2026-67213 in package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-71554 in uv.lock
• CVE-2026-70608 in package-lock.json
• CVE-2026-56876 in package-lock.json
• CVE-2026-70606 in package-lock.json
• CVE-2026-71554 in uv.lock

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

---

debug info

CI timings

CI timings · View report · View job

Wall time 5m2s vs 5m34s (-9.6%). 8 job(s) slower, 15 faster, 1 unchanged.

• Python tests / Run tests slice 2/12: -106.0s
• Python tests / Run tests slice 12/12: -63.0s
• Python tests / Run tests slice 3/12: -43.0s
• Python tests / Run tests slice 1/12: -43.0s
• Python tests / Run tests slice 7/12: -31.0s