[Bug]: Windows Desktop self-update rebuild fails because running Hermes.exe locks release/win-unpacked files

[katanumahotori]

Summary

On Windows Desktop, the in-app self-update handoff can still rebuild while the running Hermes Desktop process tree is holding files inside apps/desktop/release/win-unpacked. The update applies the git update, but the Desktop GUI rebuild fails because Electron/app-builder cannot clean the existing unpacked app directory.

This is related to the broader Windows lock issues in #37731 and #38789, but this report is specifically about the Desktop executable/process tree locking the GUI release directory (release/win-unpacked), not only the venv or .pyd native modules.

Environment

• OS: Windows 11 / Windows_NT 10.0.26200
• Hermes Desktop: v0.16.0 (2026.6.5)
• Python: 3.11.15
• Install path: C:\Users\katan\AppData\Local\hermes\hermes-agent
• Observed upstream commits during the failure sequence: 136dae779, then repaired to 9e631095
• Interface: Hermes Desktop app, using the staged hermes-setup.exe --update --branch main flow

What happened

1. Triggered Desktop update from the app.
2. The Desktop handed off to the staged updater and logged:

[updates] restart: Handing off to the Hermes updater…
[updates] venv shim unlocked; safe to proceed
[updates] launched updater: C:\Users\katan\AppData\Local\hermes\hermes-setup.exe --update --branch main; exiting desktop to release venv shim

3. The update fetched/applied the new source commit and started rebuilding the Desktop GUI.
4. The rebuild failed because the existing unpacked Desktop app directory could not be cleaned:

[before-pack] could not clean C:\Users\katan\AppData\Local\hermes\hermes-agent\apps\desktop\release\win-unpacked
(EPERM, Permission denied: \\?\C:\Users\katan\AppData\Local\hermes\hermes-agent\apps\desktop\release\win-unpacked); continuing

⨯ remove C:\Users\katan\AppData\Local\hermes\hermes-agent\apps\desktop\release\win-unpacked\d3dcompiler_47.dll: Access is denied.

C:\Users\katan\AppData\Local\hermes\hermes-agent\node_modules\app-builder-bin\win\x64\app-builder.exe process failed ERR_ELECTRON_BUILDER_CANNOT_EXECUTE

5. A follow-up retry/repair then failed earlier in bootstrap because the backend had relaunched and was holding the venv Python executable:

項目 C:\Users\katan\AppData\Local\hermes\hermes-agent\venv\Scripts\python.exe を削除できません: パス 'python.exe' へのアクセスが拒否されました。

Locking processes observed

Immediately before manual repair, these Hermes processes were still running and using files under the install root:

Hermes.exe
Hermes.exe --type=gpu-process ...
Hermes.exe --type=utility ...
Hermes.exe --type=renderer ... --app-path=...\release\win-unpacked\resources\app.asar
python.exe -m hermes_cli.main dashboard --no-open --host 127.0.0.1 --port 9120

After force-stopping only Hermes-local processes, both lock probes succeeded:

UNLOCKED ...\venv\Scripts\python.exe
UNLOCKED ...\apps\desktop\release\win-unpacked\d3dcompiler_47.dll

Then the same scripts\install.ps1 -Branch main -NonInteractive -IncludeDesktop flow completed successfully.

Expected behavior

The Windows Desktop update path should not attempt to clean/rebuild release/win-unpacked until all Hermes Desktop processes that loaded files from that directory have fully exited.

At minimum, the staged updater should detect and wait for/stop:

• Hermes.exe main process
• Electron child processes (gpu-process, renderer, utility)
• Desktop-spawned backend venv\Scripts\python.exe -m hermes_cli.main dashboard ...
• Any stale hermes-setup.exe/update subprocess from a previous attempt

Suggested fixes

• Use Windows Restart Manager API or an equivalent lock probe before deleting/rebuilding apps/desktop/release/win-unpacked.
• Have the staged updater wait for the full Hermes Desktop process tree to exit, not just the venv shim/backend.
• Do not immediately re-enter bootstrap/update while the freshly relaunched backend is running and locking venv\Scripts\python.exe.
• If a lock remains, surface the locking process in the UI instead of showing a generic install failure.
• Consider a separate external broker/update directory so the updater can build into a clean temp path and atomically swap after all locks are released.

Workaround used

# Stop only Hermes-local processes first
Get-CimInstance Win32_Process |
  Where-Object {
    $_.ExecutablePath -like 'C:\Users\katan\AppData\Local\hermes\*' -or
    $_.CommandLine -like '*C:\Users\katan\AppData\Local\hermes\hermes-agent*' -or
    $_.CommandLine -like '*hermes-setup*' -or
    $_.Name -like '*Hermes*'
  } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

# Then repair/build while Hermes Desktop is not running
powershell -NoProfile -ExecutionPolicy Bypass `
  -File C:\Users\katan\AppData\Local\hermes\hermes-agent\scripts\install.ps1 `
  -Branch main -NonInteractive -IncludeDesktop

I then restored the npm-touched package-lock.json and repacked once from a clean tree so install-stamp.json ended with dirty: false.

Related

• Windows installer fails with "Access denied" — wipes venv while app + leaked child processes still hold files open #37731 — Windows installer fails with Access denied while app/leaked child processes hold venv files
• [Bug]: Windows hermes update fails when Gateway/Dashboard lock native .pyd dependencies #38789 — Gateway/Dashboard lock native .pyd dependencies during update