fix(install,update): restore installs and unblock the update runtime repair

[OutThisLife]

Nobody can install or update Hermes right now. Fresh installs and hermes update both die at the first npm ci:

npm error code EBADENGINE
npm error notsup Required: {"node":">=26.0.0","npm":">=12.0.0"}
npm error notsup Actual:   {"node":"v24.15.0","npm":"11.12.1"}

Root cause

.npmrc sets engine-strict=true, so engines is a hard gate on every install — the installer's workspace step, the update dependency refresh, and CI alike.

The floor was raised to npm >=12.0.0, but no Node release bundles npm 12:

Node	bundled npm
26.5.1	11.17.0
24.18.1	11.16.0
22.23.2	10.9.8
20.20.2	10.8.2

The requirement is unsatisfiable by any stock toolchain. The installer provisions a Node from nodejs.org and is then immediately unable to install anything with it — including the Node it just vendored.

The fix

engines.npm → <11.10.0 || >=11.17.0. This still excludes the band the strictness was actually for. npm 11.10–11.16 honor min-release-age but ignore min-release-age-exclude, both set in .npmrc, so they apply the 14-day age gate to packages we deliberately exempted. Verified rather than assumed:

npm 11.12.1 → npm error notarget No matching version found for vite@8.2.0
              with a date before 7/18/2026
npm 11.17.0 → added 15 packages

engines.node → >=20.0.0, toolchain floor back to Node 22. Nothing in the tree needs 26 — Vite 8.2.0 declares ^20.19.0 || >=22.12.0, Electron 40 declares >=12.20.55. Requiring 26 force-migrated every working install for no dependency reason. apps/desktop drops to Vite's own floor for the same reason, and the desktop bundle builds clean on Node 22.

install.sh gained a second gate. A system Node was accepted on version alone, so a machine with Node 24 + its bundled npm 11.16.0 — the bad band — passed the check and then failed npm ci. npm_supports_npmrc() now rejects that band and installs the managed Node instead.

CI, Docker and nix are hermetic and keep pinning Node 26 / npm 12. They provision their own toolchain and both satisfy the relaxed range.

Verification

Real downloads, temp HERMES_HOME, no mocks:

Path	Result
Fresh install (managed node v22.23.2 / npm 10.9.8)	✓ npm ci — 209 packages
Existing managed tree (v22.22.3 / npm 10.9.8)	✓ npm ci — 209 packages
Node 26.5.1 + bundled npm 11.17.0	✓ npm ci — 208 packages
System npm 11.12.1 (the reported case)	✓ EBADENGINE → recovery provisions managed tree → retry green
apps/desktop npm run build on Node 22	✓ dist built, assert passes

tests/test_engines_satisfiable.py encodes the invariants that would have caught this: the npm floor must be met by an npm some shipping Node actually bundles, the node floor by the runtime install.sh provisions, the desktop floor by its own build toolchain, and the lockfile mirror must match the manifest. Restoring the broken values fails 5 of them, each naming the reason:

AssertionError: engines.npm is '>=12.0.0', which no shipping Node bundles
(checked {20: '10.8.2', 22: '10.9.8', 24: '11.16.0', 26: '11.17.0'}).
With engine-strict=true every fresh install fails at the first `npm ci`.

These are relationships, not snapshots — no version anyone expects to change is pinned.

Note on the revert plan

I dry-ran reverting #76459, #76306, #76295, #75037 against current main: three of the four conflict individually (only #76295, the one-line electron-headers sha, is clean). #75037 also carries the vulnerability patches, so reverting it reintroduces those. This PR is the narrow forward fix for the install break; the nix/security work can be unwound separately if still wanted.

Also worth separating from this outage — the cannot import name 'venv_python_path' from 'hermes_constants' line in the update logs comes from 83314ca38, not from any of the four. It is a caught warning on the managed-Python repair path, not the install failure.

[OutThisLife]

Added a second commit — c51c92a2 — for the venv_python_path error in @Teknium's update log. I originally called it unrelated noise; it is a real update-boundary bug and it does block the managed-Python runtime repair, so it belongs here.

⚠ Managed Python runtime repair skipped: cannot import name
  venv_python_path from hermes_constants
  (/home/teknium/.hermes/hermes-agent/hermes_constants.py)

The named file does contain the symbol; the module in memory does not. main.py imports hermes_constants from the old checkout, git pull replaces the file, and the freshly-pulled managed_uv runs its lazy import against the module object already cached in sys.modules. The ImportError names the new file on disk, which is why it reads as a contradiction. Same class as the ensure_uv() arity skew already documented on _UvResult, and it fires on the first update from any release older than 83314ca38.

Reproduced standalone before touching anything:

1. updater imports old module; has symbol: False
2. git pull rewrote file; disk has symbol: True
3. lazy import in new managed_uv: ImportError ->
   cannot import name 'venv_python_path' from 'hermes_constants' (...)

Fixed at both lazy call sites — managed_uv._venv_python (the reported one) and gateway.get_python_path, which has the identical flaw and is hit by a gateway restarted mid-update.

Worth noting how: my first attempt recomputed <venv>/bin/python inline, and test_no_open_coded_venv_layout_remains_in_hermes_cli correctly failed it — that is exactly the duplication #76105 deduped away. So the recovery reloads the module from disk instead, which fixes the actual problem (a stale module) and keeps one owner for the layout. The regression test asserts recovery resolves through the reloaded shared helper via a sentinel, so an open-coded copy cannot pass it either.

Against origin/main's managed_uv the new tests fail with the exact reported ImportError; with the fix, 6 passed. test_update_zip_two_phase.py (the guard suite) stays green.

Note this is separate from the four PRs in the revert list — it comes from 83314ca38, so unwinding those would not have fixed it.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on c51c92a}

ℹ️ Info

Desktop E2E visual evidence · View test artifacts · View job

3 visual diffs.

_{inline evidence is publishing...}