fix(install): stop managed runtime child trees on Windows by helix4u · Pull Request #81327 · NousResearch/hermes-agent

helix4u · 2026-08-07T21:12:57Z

What does this PR do?

The Windows venv sweep already limits its process selection to executables inside this Hermes install's venv. It then used Stop-Process on only the selected parent, which can leave a managed Python child under .hermes-runtime alive and holding the install open.

This keeps the existing path check and changes only the stop action: each verified venv process is now stopped with its full child tree. Unrelated Python processes remain outside the selection.

Related Issue

Related to #70026, specifically the current-main managed-runtime child repro in #70026 (comment).

Type of Change

🐛 Bug fix (non-breaking change that fixes an issue)
✨ New feature (non-breaking change that adds functionality)
🔒 Security fix
📝 Documentation update
✅ Tests (adding or improving test coverage)
♻️ Refactor (no behavior change)
🎯 New skill (bundled or hub)

Changes Made

Updated scripts/install.ps1 to run taskkill /T /F for each process selected by the existing venv-prefix check.
Added a Windows behavioral regression that starts a venv parent, a managed-runtime child outside the venv, and an unrelated process, then verifies the installer stops only the Hermes tree.
Stubbed the regression's image-wide launcher kill and scheduled-task calls so it cannot stop real Hermes launchers or touch real gateway tasks on a developer machine.

How to Test

On Windows, run scripts/run_tests.sh tests/test_install_ps1_venv_process_tree.py -q -j 4.
The regression runs the real install.ps1 -Stage venv path against a temporary Hermes home.
Confirm the venv parent and .hermes-runtime child exit while the unrelated process stays alive.

Local checks completed:

PowerShell parser: passed.
scripts/install.ps1 ASCII check: passed.
python -m py_compile tests/test_install_ps1_venv_process_tree.py: passed.
python scripts/check-windows-footguns.py scripts/install.ps1 tests/test_install_ps1_venv_process_tree.py: passed.
Focused Python test: not run locally under the workstation safety rule; CI pending.

Checklist

Code

I've read the Contributing Guide
My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
I searched for existing PRs to make sure this isn't a duplicate
My PR contains only changes related to this fix/feature (no unrelated commits)
I've run pytest tests/ -q and all tests pass
I've added tests for my changes (required for bug fixes, strongly encouraged for features)
I've tested on my platform: Windows 11 static checks completed; behavioral test pending CI

Documentation & Housekeeping

I've updated relevant documentation (README, docs/, docstrings) — or N/A
I've updated cli-config.yaml.example if I added/changed config keys — or N/A
I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

N/A. The linked issue comment contains the current-main process tree and updater failure evidence.

teknium1 · 2026-08-09T02:38:56Z

Salvaged into #82179 — your commit is rebased onto current main intact (authorship preserved), with the sibling fix stacked on top: the same orphaned-straggler problem your install.ps1 sweep fixes also dead-ends hermes update's venv-holder guard ("Hermes is still running" with zero windows open), so #82179 adds an orphan-backend classifier + tree reap there too. Thanks for the fix — closing this once #82179 merges.

…e venv-holder guard The GUI-updater handoff race: the Desktop fires SIGTERM + app.quit() and spawns hermes-setup, but its Python backend (`python.exe -m hermes_cli.main serve`) can survive the teardown. The Desktop is gone -- nothing will respawn that backend -- yet the venv-holder guard refused on it and the update dead-ended with "Hermes is still running" while the user had zero windows open (observed twice on 2026-08-09, 01:59 and 02:17, bootstrap-installer.log). New `_orphaned_desktop_backend_pids()` classifies remaining holders: a serve/dashboard backend whose supervising parent is provably dead (PID gone, or recycled -- parent created after the child) is a straggler safe to reap. Any live-parent backend, non-backend holder, or unprovable case keeps the refusal exactly as before. Reaping uses the new `_stop_process_trees()` (taskkill /T /F), mirroring the Desktop's forceKillProcessTree and install.ps1's venv sweep so the managed .hermes-runtime interpreter child dies with its launcher (#70026). Builds on #81327 (salvaged intact underneath): that fixed the same parent-only-kill gap in install.ps1's venv sweep; this closes the remaining dead-end in the `hermes update` guard itself. E2E on a real Windows box: spawned a detached orphan with a backend-shaped argv -> classifier returned its PID and the tree reap killed it; a non-backend orphan and the live Desktop backend (parent alive) both returned None (refusal preserved).

teknium1 · 2026-08-09T02:46:42Z

Merged via #82179 (your commit landed intact on main — thanks!)

… update Pre-#67193 hermes-setup binaries (June 2026 and earlier, including the newest published build) resolve bootstrap-cache/install-<branch>.ps1 by "exists -> reuse forever": a branch-ref cache entry written at install time is never re-downloaded, so every GUI update/repair executes a months-stale install script. The binary has no self-update path, so no amount of `hermes update` fixes it. Live incident (2026-08-09, ryanc): install-main.ps1 cached June 4 lacked the #81327 venv process-tree sweep; the bootstrap venv stage died with "Cannot remove item venv\Scripts\python.exe: Access denied" on a straggler backend pair, twice, despite every relevant fix already being merged on main - the installer simply never ran that code. Fix: `_refresh_bootstrap_cache_scripts()` runs at the end of every update path (git, zip, already-up-to-date repair), overwriting mutable branch-ref cache entries with the freshly pulled scripts/install.ps1 / install.sh. The stale binary's unconditional reuse becomes a feature: it "reuses" a file the update keeps permanently current. Post-#67193 installers re-download on every run anyway, so this is a harmless pre-seed of identical bytes for them. Scope guards: 40-hex commit-SHA entries are immutable pins and are never touched; .ps1 gets the UTF-8 BOM to match the installer's cache format (#67193); best-effort - a failed refresh never fails the update. E2E on the incident machine: poisoned the real bootstrap-cache/install-main.ps1 with a stub, ran the real function - healed byte-exact to the checkout's script (BOM intact, #81327 tree-kill sweep present).

…e venv-holder guard The GUI-updater handoff race: the Desktop fires SIGTERM + app.quit() and spawns hermes-setup, but its Python backend (`python.exe -m hermes_cli.main serve`) can survive the teardown. The Desktop is gone -- nothing will respawn that backend -- yet the venv-holder guard refused on it and the update dead-ended with "Hermes is still running" while the user had zero windows open (observed twice on 2026-08-09, 01:59 and 02:17, bootstrap-installer.log). New `_orphaned_desktop_backend_pids()` classifies remaining holders: a serve/dashboard backend whose supervising parent is provably dead (PID gone, or recycled -- parent created after the child) is a straggler safe to reap. Any live-parent backend, non-backend holder, or unprovable case keeps the refusal exactly as before. Reaping uses the new `_stop_process_trees()` (taskkill /T /F), mirroring the Desktop's forceKillProcessTree and install.ps1's venv sweep so the managed .hermes-runtime interpreter child dies with its launcher (NousResearch#70026). Builds on NousResearch#81327 (salvaged intact underneath): that fixed the same parent-only-kill gap in install.ps1's venv sweep; this closes the remaining dead-end in the `hermes update` guard itself. E2E on a real Windows box: spawned a detached orphan with a backend-shaped argv -> classifier returned its PID and the tree reap killed it; a non-backend orphan and the live Desktop backend (parent alive) both returned None (refusal preserved).

… update Pre-NousResearch#67193 hermes-setup binaries (June 2026 and earlier, including the newest published build) resolve bootstrap-cache/install-<branch>.ps1 by "exists -> reuse forever": a branch-ref cache entry written at install time is never re-downloaded, so every GUI update/repair executes a months-stale install script. The binary has no self-update path, so no amount of `hermes update` fixes it. Live incident (2026-08-09, ryanc): install-main.ps1 cached June 4 lacked the NousResearch#81327 venv process-tree sweep; the bootstrap venv stage died with "Cannot remove item venv\Scripts\python.exe: Access denied" on a straggler backend pair, twice, despite every relevant fix already being merged on main - the installer simply never ran that code. Fix: `_refresh_bootstrap_cache_scripts()` runs at the end of every update path (git, zip, already-up-to-date repair), overwriting mutable branch-ref cache entries with the freshly pulled scripts/install.ps1 / install.sh. The stale binary's unconditional reuse becomes a feature: it "reuses" a file the update keeps permanently current. Post-NousResearch#67193 installers re-download on every run anyway, so this is a harmless pre-seed of identical bytes for them. Scope guards: 40-hex commit-SHA entries are immutable pins and are never touched; .ps1 gets the UTF-8 BOM to match the installer's cache format (NousResearch#67193); best-effort - a failed refresh never fails the update. E2E on the incident machine: poisoned the real bootstrap-cache/install-main.ps1 with a stub, ran the real function - healed byte-exact to the checkout's script (BOM intact, NousResearch#81327 tree-kill sweep present).