[Bug]: Windows update fails after interrupted install — hermes.exe missing + node_modules ENOTEMPTY + desktop UPDATE DIDN'T FINISH

[mboveiri]

Environment

• OS: Windows 10/11
• Hermes version: v0.19.0 (2026.7.20) — install method: git
• Python: 3.11.15
• Node.js: v24.13.0
• Install directory: C:\Users\<user>\AppData\Local\hermes\hermes-agent

Description

After a previous incomplete update (likely interrupted or crashed), running hermes update fails at the Building desktop app stage with multiple cascading errors. The desktop app also refuses to launch, showing "UPDATE DIDN'T FINISH — Could not find the hermes CLI".

Issues #39185, #45860, and #48854 are reportedly fixed, but this scenario still reproduces on v0.19.0.

Steps to Reproduce

1. Install Hermes Agent v0.19.0 via git
2. A previous hermes update or hermes desktop is interrupted (power loss, Ctrl+C, crash, etc.)
3. Run hermes update again
4. Observe failures at "Building desktop app" stage

Actual Behavior

Error 1: npm ci fails with ENOTEMPTY

npm error code ENOTEMPTY
npm error syscall rmdir
npm error path C:\Users\<user>\AppData\Local\hermes\hermes-agent\node_modules\@babel\core\node_modules\.bin
npm error errno -4051
npm error ENOTEMPTY: directory not empty, rmdir

npm ci fails because a previous incomplete install left corrupted node_modules. The retry with npm install also fails or hangs.

Error 2: Playwright Chromium not installed

'playwright' is not recognized as an internal or external command
[!] Playwright Chromium install failed -- exit code 1

Because npm install for desktop workspace failed, npx playwright install chromium cannot run.

Error 3: hermes.exe missing from venv/Scripts/

The desktop app shows:

UPDATE DIDN'T FINISH
Could not find the hermes CLI under C:\Users\<user>\AppData\Local\hermes\hermes-agent.
Is Hermes installed? Re-run the installer to repair the install.

After checking venv/Scripts/, only hermes-agent.exe and hermes-acp.exe exist — hermes.exe is gone.

Error 4: Desktop updater hangs

Clicking "Retry update" in the desktop UI either hangs indefinitely or fails with "another Hermes process is using this installation" even after closing the app and restarting Windows.

Manual Fix Required

The following manual steps were needed to recover:

# 1. Kill all node/electron processes
Get-Process | Where-Object { $_.ProcessName -match 'electron|node|npm' } | Stop-Process -Force

# 2. Delete corrupted node_modules
cmd /c "rmdir /s /q ""C:\Users\<user>\AppData\Local\hermes\hermes-agent\node_modules"""

# 3. Restore hermes.exe via pip reinstall
cd "C:\Users\<user>\AppData\Local\hermes\hermes-agent"
.\venv\Scripts\python.exe -m pip install -e .

# 4. Run update again
hermes update

After these steps, hermes update succeeded and upgraded to v0.19.1.

Expected Behavior

1. hermes update should detect corrupted node_modules and clean-reinstall automatically
2. If hermes.exe is missing, the updater/CLI should attempt to restore it (e.g. via pip install -e .) instead of failing with "Could not find the hermes CLI"
3. The desktop updater should not hang indefinitely — it should detect the corrupted state and offer a repair option

Related Issues

• hermes command not available on Windows — missing .exe entry point in venv/Scripts/ #39185 — hermes.exe missing (fix merged v2026.7.1, but still reproduces after interrupted update)
• 3 Bugs Found — Windows Installation #45860 — hermes.exe disappears after interrupted update (fix merged, but scenario still triggers)
• Desktop "Update" button hangs forever on Windows due to Electron file lock (EBUSY) #48854 — EBUSY file lock hangs updater (fix merged, but gateway/child processes still cause lock contention)
• [Bug] Windows Desktop updater falsely detects running Hermes processes and aborts update ("Another Hermes process is using this installation") #74267 — "another Hermes process" false positive (open)
• [Bug]: [Desktop][macOS] In-app update stuck in "another update is already running" loop because the updater itself doesn't exit #74531 — Self-lock loop on Windows/macOS (open)
• [Bug] Windows: footbar-triggered update races process table on first attempt, no auto-relaunch after retry #74805 — Race condition on first update attempt (open)

Suggestion

The update mechanism should include a self-healing / defensive recovery step:

1. Before starting the update, validate that hermes.exe exists in venv/Scripts/
2. If missing, run pip install -e . to restore it before proceeding
3. If node_modules is corrupted (detect by failed npm ci), automatically delete and retry with npm install
4. On Windows, kill any orphaned Hermes-related processes before starting the update (similar to what hermes desktop --force-build already does)

[GottZ]

This was generated by AI during triage.

Summary

One PR addresses issue #75584. #75752 targets both reported root causes: the missing target-venv Hermes shim and the corrupted node_modules tree that survives a failed npm ci attempt.

Related pull requests

• fix(desktop): recover from interrupted Windows update (missing hermes.exe + ENOTEMPTY) #75752 best fix — (+519/-27) — fixes: Adds a validated target-venv Python module fallback ahead of PATH, with a bounded import probe, so an interrupted update can proceed when hermes.exe is missing without selecting a foreign installation. It also removes node_modules before the npm install fallback after npm ci fails, directly addressing the Windows ENOTEMPTY recovery loop, with focused Rust and Python regression coverage.

Suggested consolidation

#75752 is the best available fix and is consistent with the automated keep_open review. Keep open with a salvage path: preserve the validated target-venv python -m hermes_cli.main recovery path, its bounded probe, and the shared npm cleanup behavior with their regression tests; there are no competing PRs or duplicates to close.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I75584(["issue #75584 (open)"])
    P75752["PR #75752 (open)"]
    P75752 -->|best fix| I75584
    class I75584 open
    class I75584 target
    class P75752 open
    class P75752 best
    click I75584 "https://github.com/NousResearch/hermes-agent/issues/75584"
    click P75752 "https://github.com/NousResearch/hermes-agent/pull/75752"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 31 kB of PR diffs, 7 kB of issue/PR text, 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[nrsteel]

Additional independent Windows reproduction from a git-installed Hermes Desktop:

• Hermes v0.19.0 on Windows

• System Node: v22.20.0

• Desktop updater requirement: Node >=22.22.0

• A normal update left the installation with:

  Desktop dependency install failed
  Update partially complete
  The desktop app could not be rebuilt
  

• The next Desktop launch failed with Remote gateway URL is required, even though the existing remote connection configuration was valid.

The installation was recovered without resetting the checkout or deleting user state by using the bundled Node v22.23.2, reinstalling dependencies, rebuilding the Desktop package, and relaunching it. The rebuilt Desktop then connected successfully to the configured remote backend and remained stable.

This suggests the updater should prefer the bundled/managed runtime when the system Node is below the Desktop requirement, and should leave a clearly runnable rollback or return a hard failure when the Desktop rebuild cannot complete. Related Ubuntu details are tracked in #76533.

[GottZ]

This was generated by AI during triage.

Delta since our previous triage comment

@nrsteel’s independent Windows reproduction extends the issue beyond the two recovery failures covered previously: an outdated system Node can also leave the Desktop partially rebuilt, and the updater lacks a clearly runnable rollback or hard-failure path. The updated #75752 diff still directly repairs the missing target-venv shim and corrupted node_modules paths, but it does not select the bundled Node runtime or provide rollback behavior.

Changed pull requests

• fix(desktop): recover from interrupted Windows update (missing hermes.exe + ENOTEMPTY) #75752 best fix — (+543/-28) — best available partial fix: The diff adds a validated target-venv python -m hermes_cli.main fallback with bounded probing and removes corrupted node_modules before the npm install fallback, directly addressing the original missing-shim and ENOTEMPTY causes. The new @nrsteel evidence narrows the scope verdict because bundled-Node selection and incomplete-rebuild rollback remain unaddressed; this remains consistent with the keep_open review on fix(desktop): recover from interrupted Windows update (missing hermes.exe + ENOTEMPTY) #75752.

Suggested consolidation

The recommendation is unchanged: keep #75752 open as the best existing fix and pursue its salvage path rather than treating it as a complete resolution of #75584.

Complex graph unchanged since our previous triage comment.

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 30 kB of PR diffs, 7 kB of issue/PR text, 1 kB of discussion (1 comments), 3 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.