fix(cli): target the managed install root in the ZIP update path

[dtarkent2-sys]

What does this PR do?

Makes the Windows ZIP update path write to the install it is actually managing.

PROJECT_ROOT is derived from the running hermes_cli package, so it equals the install root only when the hermes entry point on PATH belongs to the managed install. When they diverge — a hermes shim in a conda/miniforge env in front of an agent installed under %LOCALAPPDATA%\hermes\hermes-agent — _update_via_zip copies the freshly downloaded tree into the shim's site-packages and then runs uv pip install -e . in that same directory. There is no pyproject.toml there, so uv exits 2 on every run and the install is left half updated: files replaced in the wrong place, dependencies never installed.

_resolve_managed_install_root() probes, in order:

1. PROJECT_ROOT — so nothing changes when both roots already agree
2. $HERMES_INSTALL_DIR — the installer's own --install-dir override
3. the parent of sys.prefix / $VIRTUAL_ENV — the managed venv lives at <install root>/venv
4. get_default_hermes_root() / "hermes-agent" — the installer default (%LOCALAPPDATA%\hermes\hermes-agent on Windows, $HERMES_HOME/hermes-agent on POSIX)
5. /usr/local/lib/hermes-agent — the Linux root-install location

The first candidate that looks like a hermes-agent checkout (pyproject.toml + hermes_cli/main.py) wins, and PROJECT_ROOT is also the final fallback — an unrecognized layout keeps today's behavior rather than updating some unrelated directory.

Related Issue

Fixes #59850

Builds on @liuhao1024's #59866, which correctly identified the cwd plumbing but kept passing PROJECT_ROOT at the ZIP call sites, so the failing directory selection was unchanged (per the review on that PR). This adds the distinct resolved install root that review asked for, uses it for both the replacement and the dependency install, and adds the divergent-root regression test. Happy to close this in favour of #59866 if @liuhao1024 would rather fold the diff into their branch.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• hermes_cli/main.py
  • new _looks_like_hermes_checkout() / _resolve_managed_install_root()
  • _update_via_zip() resolves the install root once and uses it for the file replacement, bytecode clear, VIRTUAL_ENV, dependency install, web build, and model-catalog seed; prints both paths when they diverge
  • cwd threaded through _install_python_dependencies_with_optional_fallback → _run_quarantined_install → _run_install_with_heartbeat (defaults to PROJECT_ROOT)
  • _venv_scripts_dir(root=None) so shim quarantine follows the venv being written to
• tests/hermes_cli/test_update_zip_install_root.py — new
• tests/hermes_cli/test_verify_console_scripts.py — mock assertion picks up the new cwd kwarg

How to Test

Reproduce (Windows, hermes entry point outside the managed install):

hermes update
# → ⚠ Optional extras failed, reinstalling base dependencies and retrying extras individually...
# → subprocess.CalledProcessError: '...\hermes\bin\uv.exe pip install -e .' returned non-zero exit status 2

The same command with the cwd corrected by hand succeeds, which is what isolates it to the directory selection:

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

Automated:

pytest tests/hermes_cli/test_update_zip_install_root.py tests/hermes_cli/test_verify_console_scripts.py -q

test_update_via_zip_writes_and_installs_into_managed_root builds the divergent case — a site-packages module root that is not a checkout plus a separate managed checkout — and asserts the ZIP content lands in the managed root, not in the module root, and that the dependency install receives that same directory as its cwd with its venv as VIRTUAL_ENV. All six tests in the new file fail against main and pass with this change.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs — fix(cli): pass cwd to install functions to support update when PROJECT_ROOT diverges from install root #59866 is the related one, addressed above
• My PR contains only changes related to this fix
• I've run the affected tests and they pass
• I've added tests for my changes
• I've tested on my platform: Windows 11, Python 3.11.9, uv 0.11.26

Test run: tests/hermes_cli/ update+install files — 112 passed. Two pre-existing failures in test_cmd_update.py (test_resolve_rejects_windows_npm_and_rescans_path, test_update_refreshes_repo_and_tui_node_dependencies) reproduce unchanged on main on a native-Windows host; they simulate a WSL npm layout.

Documentation & Housekeeping

• Docs — N/A (internal update-path behavior; the divergent case now prints both paths)
• cli-config.yaml.example — N/A (no new config keys; HERMES_INSTALL_DIR is the installer's existing flag)
• CONTRIBUTING.md / AGENTS.md — N/A
• Cross-platform impact considered — the resolver is ordered so POSIX and dev-checkout installs hit PROJECT_ROOT first and are unaffected
• Tool descriptions/schemas — N/A

Known remaining gap

_update_node_dependencies() is still PROJECT_ROOT-relative, as is the git-pull update path in _cmd_update_impl. Both are the same class of assumption, but threading a root through them is a wider change than this fix needs, so it is left for a follow-up — _resolve_managed_install_root() is written to be reusable there. On a divergent install the Node step is a no-op today (no package.json in the shim's directory) rather than a corruption.

[teknium1]

Thanks for isolating the divergent-root ZIP-update failure; the current implementation still has that premise: hermes_cli/update_cmd.py:617 copies ZIP contents to PROJECT_ROOT, and :658-662 sets that root’s venv and installs without a caller-selected cwd.

Problems

• The resolver’s HERMES_INSTALL_DIR candidate does not cover the Windows installer’s -InstallDir: scripts/install.ps1:33 defines -InstallDir independently, while :2312 persists only HERMES_HOME. A custom prior install is therefore not recoverable through that candidate.
• The proposed ZIP path leaves Node refresh rooted at the running package tree. Current _update_node_dependencies() checks PROJECT_ROOT/package.json at hermes_cli/update_cmd.py:1779 and invokes npm with PROJECT_ROOT at :1843; this can skip dependencies for the managed checkout before its web build.

Suggested changes

• Port the patch to hermes_cli/update_cmd.py; 927463efcc mechanically moved the update pipeline, so the current PR conflicts.
• Persist/discover custom Windows -InstallDir durably, or explicitly scope the guarantee to the default HERMES_HOME/hermes-agent layout.
• Pass the resolved root through the Node-update path and extend the divergent-root regression accordingly.

This is an automated hermes-sweeper review.

[GottZ]

This was generated by AI during triage.

Summary

Two PRs address the same reported Windows ZIP-update failure. #59866 adds cwd plumbing but still passes PROJECT_ROOT at the failing call sites, while #71510 resolves the managed install root and uses it for replacement and dependency installation, with a divergent-root regression test.

Related pull requests

• fix(cli): pass cwd to install functions to support update when PROJECT_ROOT diverges from install root #59866 best fix — (+13/-15) — n/a: Adds optional cwd plumbing through the installer chain, but the ZIP path still passes PROJECT_ROOT, so the failing directory selection remains unchanged. Despite the keep_open review on fix(cli): pass cwd to install functions to support update when PROJECT_ROOT diverges from install root #59866, it is superseded by fix(cli): target the managed install root in the ZIP update path #71510, which implements the requested managed-root resolution and regression coverage; close as duplicate of fix(cli): target the managed install root in the ZIP update path #71510.
• fix(cli): target the managed install root in the ZIP update path #71510 best fix — (+265/-16) — n/a: Resolves the managed checkout separately from the running module root, targets it for ZIP replacement, dependency installation, virtualenv selection, cache cleanup, and web build, and adds divergent-root tests. Keep open with a salvage path: address the maintainer-bot keep_open findings by porting the change to the current update pipeline, covering persisted custom Windows -InstallDir discovery, and threading the resolved root through Node dependency updates.

Duplicates

#59866 and #71510 overlap on the cwd-plumbing portion; #59866 is superseded by #71510, whose diff additionally resolves and consistently uses the managed install root. Close #59866 as a duplicate once #71510's salvage work is incorporated.

Suggested consolidation

Keep #71510 open with a salvage path, specifically addressing the maintainer-bot keep_open review: port the implementation to the current update pipeline, resolve or explicitly scope custom Windows -InstallDir handling, and pass the managed root through Node dependency updates. Close #59866 as a duplicate of #71510 because its ZIP call sites still use PROJECT_ROOT and do not fix the reported divergent-root cause.

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
    I59850(["issue #59850 (open)"])
    subgraph Dup59866 ["PRs duplicating each other"]
        P59866["PR #59866 (open)"]
        P71510["PR #71510 (open)"]
    end
    P71510 -->|best fix| I59850
    class I59850 open
    class P59866 open
    class P71510 open
    class P59866 best
    class P71510 best
    class P71510 target
    click I59850 "https://github.com/NousResearch/hermes-agent/issues/59850"
    click P59866 "https://github.com/NousResearch/hermes-agent/pull/59866"
    click P71510 "https://github.com/NousResearch/hermes-agent/pull/71510"

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 2 pull requests and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 24 kB of PR diffs, 14 kB of issue/PR text, 3 kB of discussion (3 comments), 5 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.