Desktop updater respawn causes infinite update loop
NousResearch/hermes-agent · cluster 77277 · apps/desktop
Data as of
Nothing open on GitHub. Fix merged in #73928. Check it covers your case.
The short answer
- Known?
- Yes. 7 related items grouped here, 1 issue already closed.
- Fix event
- A fix was merged to main in PR #73928. Check it covers your case. No release data is tracked.
- Tracker
- The maintainers' tracker marks this
unresolved. That is separate from the fix event. - Still open
- Nothing open on GitHub.
These items address a bug where the desktop updater incorrectly identifies its own respawned backend process as a virtual environment blocker, causing the in-app update process to loop indefinitely on Windows. Fixes involve excluding respawned backends from the venv-blocker scan and gating respawn logic on update state.
Open issues0
Open PRs0
Fixes on record
-
#73928 fix(desktop): gate backend respawns on updateInFlight, not just the update marker (#73822)
files:
apps/desktop/electron/main.ts,apps/desktop/electron/update-gate.test.ts,apps/desktop/electron/update-gate.ts -
#91869 fix(update): Windows venv-holder guard names holders correctly and can see the gateway it must pause (#90778, #87594 — proven live on windows-latest)
files:
.github/workflows/windows-venv-e2e.yml,hermes_cli/update_cmd.py,tests/gateway/test_goal_resume_restart.py,tests/hermes_cli/test_venv_holder_classifier.py,tests/hermes_cli/test_venv_holder_windows_live.py -
#92013 fix(update): ZIP fallback no longer destroys user work or the desktop build (#87331, #91962, #87304, #70337 — salvage #87878 + #70477)
files:
hermes_cli/update_cmd.py,tests/hermes_cli/test_cmd_update.py,tests/hermes_cli/test_update_zip_fallback_guards.py,tests/hermes_cli/test_update_zip_release_preserve.py,tests/hermes_cli/test_update_zip_symlink_reject.py -
#92447 feat(gateway): fleet consumers now ask the gateway itself — control socket with identify/status (#92091 step 1)
files:
gateway/control_socket.py,gateway/run.py,hermes_cli/update_inventory.py,hermes_cli/update_receipt.py,tests/gateway/test_control_socket.py,tests/gateway/test_control_socket_windows_live.py,website/docs/getting-started/updating.md -
#92617 fix(update): a contended Windows venv is never mutated — failed shim quarantine refuses instead of warning (#87331)
files:
hermes_cli/_install_repair.py,hermes_cli/main.py,hermes_cli/update_cmd.py,tests/agent/test_bedrock_adapter.py,tests/agent/test_bedrock_integration.py,tests/hermes_cli/test_bedrock_model_picker.py,tests/hermes_cli/test_shim_fail_closed_windows_live.py,tests/hermes_cli/test_update_shim_fail_closed.py,tests/run_agent/test_streaming.py
1 PR closed without merging
From the close comments: done elsewhere 1
-
#77772 fix(desktop): exclude respawned backends from venv-blocker scan (#77277) · done elsewhere →
#91277,#73822,#92617,#92013,#91869,#77277,#92091,#92447
Closed issues · 1
- Closed#77277Desktop in-app update loops forever on Windows: updater reports its own respawning backend as the venv blocker
How this cluster was grouped
-
Link evidence (
structural links throughout): every member is connected by structural evidence: shared changed files, or a closing/superseded reference. -
Pairwise link density
0.29: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36.1.00means every pair is linked.
Pick up a Lab task
Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.
Open the Lab