[earmark-halt]

Summary

Fixes #35. With the default Hermes installer, --gateway-runtime never finds a Python that can import httpx, so the page shows "Found Python without httpx on this Gateway". This happens on Linux too, not only on macOS.

The installer starts the gateway on a bare bundled interpreter, ~/.hermes/tools/python-3.14.7+…/bin/python3 -I. Hermes's own packages, httpx included, live in a generated venv, <HERMES_HOME>/installs/<install-id>/environments/<hash>/venv, and the hash changes on every update. On a Linux SSH backend I traced Desktop's shell.exec calls during a poll:

• "$HERMES_PYTHON" expands to nothing; hermes-agent/.venv and hermes-agent/venv don't exist;
• python3 and python resolve to the bundled interpreter, because its bin is first on the gateway's PATH. A system python3 with httpx installed is never reached;
• inside the probe, _gateway_python_candidates() finds the same bundled interpreter as the parent's argv[0], and import httpx fails there too.

The installer already records the active environment in installs/<install-id>/facts.json under packages.venv.environment, as #35 suggests.

Changes

• _hermes_install_pythons() reads packages.venv.environment from each installs/*/facts.json under the Hermes homes, then adds the other installs/*/environments/*/venv interpreters newest first (by pyvenv.cfg mtime) for installs whose facts are missing or unreadable. Interpreters that don't exist are skipped, and venv paths stay unresolved, like the other candidates. A named profile home (<base>/profiles/<name>) also checks the base home, where installs live.
• _gateway_python_candidates() appends these after the existing candidates, so HERMES_PYTHON, VIRTUAL_ENV and parent interpreters keep their priority. The 5-second budget in _use_gateway_python is unchanged; on this layout the bare interpreter fails its check at once.
• Catalog probe regenerated with scripts/build_catalog.py.
• Tests: the active venv comes from facts ahead of a newer stale one; without facts, environments are tried newest first and a missing interpreter is skipped; a named profile uses the base installs; and _use_gateway_python re-execs from the bare interpreter into the installer venv. Three existing tests that assert exact candidate lists now patch _hermes_homes, so they don't depend on the machine's ~/.hermes.

Testing

• Every unittest and node suite from CI passes locally (Python 3.13, httpx 0.28.1, PyYAML 6.0.3), and scripts/build_catalog.py --check is clean.
• The four new tests fail on main (8 failures across both probe copies) and pass with the change.
• On a live Linux gateway from the default installer, running the catalog probe exactly the way Desktop does (bundled python3 first on PATH, --gateway-runtime --profile default --pin-snapshot --slice=0:8): on main it returns only the "probe cannot import httpx" card. With this change it re-execs into installs/<id>/environments/<hash>/venv/bin/python and returns the OpenRouter, Claude and DeepSeek cards.

I couldn't test macOS. There's no /proc there, so the facts and glob candidates are what discovery relies on. The Scripts/python.exe branch for Windows follows the existing VIRTUAL_ENV handling and is untested.

🤖 Generated with Claude Code

[Adolanium]

Thanks for tracking this down and for testing it against a live Linux gateway. Reading facts.json first, with the newest-first glob as a fallback, is a good fit for an install path that changes on every update.

I pushed one small commit (2be17ee) so the new facts test also passes on Windows. The /proc walk only accepts POSIX interpreter paths, and on Windows the temp-dir path became C:\..., so the walk skipped it. Merging now.