fix(gateway): stop VIRTUAL_ENV leaking into agent subprocesses - #29980
fix(gateway): stop VIRTUAL_ENV leaking into agent subprocesses#29980TheoLong wants to merge 1 commit into
Conversation
alt-glitch
added
type/bug
Three independent layers shipped on main today silently corrupt a user's Hermes venv: the systemd unit template sets VIRTUAL_ENV explicitly, a gateway-service test asserts it must be present, and the subprocess env blocklist in tools/environments/local.py has no entry for it. The result is that any agent terminal call that runs 'uv sync', 'uv run --active', 'pip install', or 'poetry install' from a user project rebuilds $VIRTUAL_ENV against that project's pyproject.toml, wiping every Hermes runtime dependency. Reproduced 2026-05-16: 'cd ~/Git/fb-operator && uv run --active fb obs' removed ~/.hermes/hermes-agent/.venv (Python 3.11) and recreated it as Python 3.12 with only fb-operator's 11 deps. Gateway restart then ModuleNotFoundError: hermes_cli. Fix (defense in depth): 1. hermes_cli/gateway.py: drop both 'Environment="VIRTUAL_ENV=..."' lines from the systemd unit templates. Gateway invokes python by absolute path; sys.prefix resolves from the interpreter location without VIRTUAL_ENV being set. 2. tests/hermes_cli/test_gateway_service.py: flip the assertion to 'VIRTUAL_ENV not in unit' with an explanatory comment. 3. tools/environments/local.py: add VIRTUAL_ENV, VIRTUAL_ENV_PROMPT, UV_PROJECT_ENVIRONMENT, POETRY_ACTIVE, PIPENV_ACTIVE, CONDA_PREFIX, CONDA_DEFAULT_ENV to _HERMES_PROVIDER_ENV_BLOCKLIST so the case where a user invokes hermes interactively with VIRTUAL_ENV set in their shell is also covered.
9a99495 to
7e19b0d
Compare
|
Rebased on current Verified still needed: |
|
Closing as resolved on Since this PR was opened, upstream removed the My earlier "still needed" bump was accurate against a |
2 participants
Problem
When
hermes-gatewayis launched from a venv (very common: systemd user services,uv run, ad-hoc dev shells),VIRTUAL_ENVis inherited by every agent subprocess. That pins the agent's Python resolution to the gateway's venv instead of the user's project venv — tool resolution breaks,ModuleNotFoundErrors surface in tasks that work fine from the user's own shell.Fix
VIRTUAL_ENV(andPYTHONHOME,PYTHONPATH) in the gateway service launcher before spawning agents._HERMES_PROVIDER_ENV_BLOCKLISTintools/environments/local.pyso terminal-tool subprocesses get the same treatment.Test
tests/hermes_cli/test_gateway_service.pycovers the unset behaviour.Risk
Low. Pure subtractive — strips an env var that shouldn't be propagating in the first place. Anyone relying on inherited
VIRTUAL_ENVin agent subprocesses (rare) would already be using the wrong venv.