Summary
On Windows, hermes update reliably fails its dependency step with uv pip install -e . returning exit status 2, even though the ZIP extraction succeeds. The code updates; dependencies never finish, leaving the install in a half-updated state on every run.
Root cause appears to be that the quarantined dependency install runs with cwd=PROJECT_ROOT, where:
# hermes_cli/main.py
PROJECT_ROOT = Path(__file__).parent.parent.resolve()
PROJECT_ROOT therefore resolves to the directory of the running hermes_cli package, not the install root the updater just extracted into. When the hermes entry point on PATH lives somewhere other than the managed install (in my case a conda/miniforge site-packages, while the agent install is under %LOCALAPPDATA%\hermes\hermes-agent), the editable install uv pip install -e . runs against the wrong directory and exits 2.
Traceback
File "...\hermes_cli\main.py", line 6329, in _update_via_zip
_install_python_dependencies_with_optional_fallback([uv_bin, "pip"], env=uv_env)
File "...\hermes_cli\main.py", line 7660, in _install_python_dependencies_with_optional_fallback
_install(["install", "-e", "."])
File "...\hermes_cli\main.py", line 7647, in _install
_run_quarantined_install(install_cmd_prefix + args, env=env, scripts_dir=scripts_dir)
File "...\hermes_cli\main.py", line 7528, in _run_quarantined_install
_run_install_with_heartbeat(cmd, env=env)
File "...\hermes_cli\main.py", line 7171, in _run_install_with_heartbeat
subprocess.run(cmd, cwd=PROJECT_ROOT, check=True, env=env)
subprocess.CalledProcessError: Command '['...\hermes\bin\uv.exe', 'pip', 'install', '-e', '.']' returned non-zero exit status 2.
The updater prints ⚠ Optional extras failed, reinstalling base dependencies and retrying extras individually... immediately before the base install -e . fails, then exits with code 2.
Workaround (confirms the diagnosis)
Running the identical command manually, but with cwd set to the actual extracted install dir, succeeds every time:
cd %LOCALAPPDATA%\hermes\hermes-agent
set VIRTUAL_ENV=%LOCALAPPDATA%\hermes\hermes-agent\venv
%LOCALAPPDATA%\hermes\bin\uv.exe pip install -e .
# -> Built hermes-agent, Installed 1 package, hermes-agent==0.18.0
So the resolver, build, and deps are all fine — the only difference is the working directory. This strongly suggests the quarantined install should use the extracted install root (the target of the ZIP extraction), not PROJECT_ROOT-of-the-running-CLI.
Suggested fix
Thread the extracted install directory through to _run_quarantined_install / _run_install_with_heartbeat and use it as cwd (and as the editable target), rather than the module-relative PROJECT_ROOT. When the running hermes shim and the managed install diverge, PROJECT_ROOT is not a safe assumption.
Two secondary Windows issues observed in the same flow
- Gateway not restarted after update. When the gateway runs from an OS scheduler entry (Windows Task Scheduler) rather than a hermes-managed profile, the updater logs
Stopped 1 gateway process(es) without profile mapping — Restart manually after update and never brings it back, so the agent goes offline after every update until hermes gateway run is re-launched.
- Desktop backend venv lock. The desktop app's backend runs from the same venv and holds
.pyd files locked; the updater correctly detects this and refuses (good message), but combined with (1) above, a routine update is fragile on a desktop+gateway install.
Environment
- Windows 11
hermes-agent 0.18.0 (2026.7.1), upstream 605727e3- venv Python 3.11.9,
uv 0.11.26
hermes entry point installed in a separate conda/miniforge env from the managed agent install (the divergence that surfaces the bug)
Summary
On Windows,
hermes updatereliably fails its dependency step withuv pip install -e .returning exit status 2, even though the ZIP extraction succeeds. The code updates; dependencies never finish, leaving the install in a half-updated state on every run.Root cause appears to be that the quarantined dependency install runs with
cwd=PROJECT_ROOT, where:PROJECT_ROOTtherefore resolves to the directory of the runninghermes_clipackage, not the install root the updater just extracted into. When thehermesentry point on PATH lives somewhere other than the managed install (in my case a conda/miniforge site-packages, while the agent install is under%LOCALAPPDATA%\hermes\hermes-agent), the editable installuv pip install -e .runs against the wrong directory and exits 2.Traceback
The updater prints
⚠ Optional extras failed, reinstalling base dependencies and retrying extras individually...immediately before the baseinstall -e .fails, then exits with code 2.Workaround (confirms the diagnosis)
Running the identical command manually, but with cwd set to the actual extracted install dir, succeeds every time:
So the resolver, build, and deps are all fine — the only difference is the working directory. This strongly suggests the quarantined install should use the extracted install root (the target of the ZIP extraction), not
PROJECT_ROOT-of-the-running-CLI.Suggested fix
Thread the extracted install directory through to
_run_quarantined_install/_run_install_with_heartbeatand use it ascwd(and as the editable target), rather than the module-relativePROJECT_ROOT. When the runninghermesshim and the managed install diverge,PROJECT_ROOTis not a safe assumption.Two secondary Windows issues observed in the same flow
Stopped 1 gateway process(es) without profile mapping — Restart manually after updateand never brings it back, so the agent goes offline after every update untilhermes gateway runis re-launched..pydfiles locked; the updater correctly detects this and refuses (good message), but combined with (1) above, a routine update is fragile on a desktop+gateway install.Environment
hermes-agent0.18.0 (2026.7.1), upstream605727e3uv0.11.26hermesentry point installed in a separate conda/miniforge env from the managed agent install (the divergence that surfaces the bug)