fix(env): strip PYTHONPATH from subprocess env (#74817)

[Enough1122]

What

The Hermes gateway process has PYTHONPATH pointing at the bundled venv's site-packages. Every subprocess spawned via the terminal tool (LocalEnvironment), the execute_code path, and the non-terminal hermes_subprocess_env() helper inherited it.

For a child that runs its own Python (e.g. ComfyUI Desktop's bundled Python 3.13), PYTHONPATH forced import of Hermes' Python 3.11 compiled extensions — production crash loop in ComfyUI's comfy_execution/progress.py PIL import.

Fix

• Add PYTHONPATH to _ACTIVE_VENV_MARKER_VARS (alongside VIRTUAL_ENV / CONDA_PREFIX)
• Refactor the three duplicated for _marker in _ACTIVE_VENV_MARKER_VARS: env.pop(...) strips in _make_run_env / _sanitize_subprocess_env / hermes_subprocess_env into a single _strip_active_venv_markers(env) helper so the fix is uniform across every spawn surface
• Hermes venv stays reachable via PATH (its bin dir is first), so stripping is safe

Tests

Added 3 cases to tests/tools/test_local_env_blocklist.py::TestActiveVenvMarkerStripping:

• test_pythonpath_marker_stripped_end_to_end — terminal tool path
• test_make_run_env_strips_pythonpath — terminal/execute_code path
• test_hermes_subprocess_env_strips_pythonpath — non-terminal spawn surface (browser, ACP, computer-use, etc.)

Plus update to test_markers_constant_contents asserting PYTHONPATH is in the constant.

All 45 tests in the relevant files pass locally (tests/tools/test_local_env_blocklist.py + test_local_env_session_leak.py).

Repro (from issue #74817)

$ hermes -z "Run this exact terminal command and show me the raw output: echo \"PYTHONPATH='\C:\Users\admin\AppData\Local\hermes\hermes-agent;C:\Users\admin\AppData\Local\hermes\hermes-agent\venv\Lib\site-packages'\""
Raw output:
PYTHONPATH='/Users/…/.hermes/hermes-agent:/Users/…/.hermes/hermes-agent/venv/lib/python3.11/site-packages'

After this fix: PYTHONPATH='...' → empty (var stripped before subprocess sees it).

Fixes #74817

[teknium1]

Thanks for tracing the terminal and non-terminal subprocess builders; current main still omits PYTHONPATH from tools/environments/local.py:349.

Problems

• tools/code_execution_tool.py:150, :246-248, and :1399-1403 show that execute_code preserves and then re-appends inherited PYTHONPATH; this tuple change does not cover that claimed surface.
• A blanket strip also removes supported user-owned paths: nix/hermes-agent.nix:116-121 builds extraPythonPackages paths and :206-208 appends them to PYTHONPATH for plugin discovery.
• The PR also includes the unrelated Signal polling commit. In that proposed change, gateway/platforms/signal.py:448-459 logs health failures only, while website/docs/user-guide/messaging/signal.md:215-217 promises reconnection and inactivity detection.

Suggested changes

• Split the Signal rewrite from this fix.
• Selectively remove Hermes-owned venv/site-packages entries rather than all PYTHONPATH entries, and apply that policy to the real execute_code child-environment path with coverage.

This is an automated hermes-sweeper review.

[Enough1122]

cc @teknium1 — addressed both inline comments from 2026-07-30:

#1 — execute_code now consumes the PYTHONPATH marker. tools/code_execution_tool.py:1399-1403 previously re-appended any incoming PYTHONPATH into the sandbox env. The PR's upstream strip in _sanitize_subprocess_env / hermes_subprocess_env / _make_run_env covers three spawn paths, but execute_code slipped through _SAFE_ENV_PREFIXES and re-introduced the cross-project clobber that #74817 was meant to fix. Now child_env.pop("PYTHONPATH", None) runs before composing the sandbox PYTHONPATH from tmpdir + _hermes_root, so the child only sees the controlled entries.

#2 — _health_monitor reworked. The old loop just logged. New behaviour:

1. Probe GET /v1/health every HEALTH_CHECK_INTERVAL (30 s).
2. Track consecutive failures. After HEALTH_MONITOR_MAX_CONSECUTIVE_FAILURES (3) the loop calls connect(is_reconnect=True) against the live self.client to rebuild the receive task. Without this, a daemon restart leaves Hermes on a dead TCP socket that polls return immediately from, silently dropping inbound.
3. Track time since the last successful receive poll via self._last_receive_at (set by _receive_loop after every successful poll, including empty ones). After HEALTH_MONITOR_INACTIVITY_SECONDS (120 s) without activity, log a warning so an operator investigating a stuck bot can see the receive loop hasn't yielded. Empty queues still count as activity because the receive loop updates the timestamp on every successful poll, including empty lists.

Two new module-level constants drive the thresholds:

HEALTH_MONITOR_MAX_CONSECUTIVE_FAILURES = 3
HEALTH_MONITOR_INACTIVITY_SECONDS = 120.0

Tests added in tests/gateway/test_signal.py::TestSignalHealthMonitor:

• test_reconnect_triggered_after_three_consecutive_failures — 3 fails → connect(is_reconnect=True)
• test_inactivity_warning_after_120s_without_receive — 200 s of no receive activity, healthy /v1/health → no reconnect, warning logged
• test_successful_health_resets_failure_counter — fail/fail/success/fail/fail → no reconnect (window never reaches 3 consecutive)
• test_receive_loop_records_last_activity_timestamp — _receive_loop updates _last_receive_at on every successful poll

Local: 62 passed, 1 skipped in tests/gateway/test_signal.py. Head rebased onto current upstream main (ab158e808).

— written by Hermes Agent on behalf of @Enough1122

[Enough1122]

Closing this PR after a full collision scan — two reasons:

1. PYTHONPATH fix (the PR's stated subject, PYTHONPATH leaks into terminal-tool subprocesses on macOS/Linux, can crash unrelated third-party apps #74817): this is one of five concurrent PRs on PYTHONPATH leaks into terminal-tool subprocesses on macOS/Linux, can crash unrelated third-party apps #74817 (fix(terminal): strip Hermes-venv site-packages from terminal subprocess PYTHONPATH #61028, fix(tools): strip PYTHONPATH from subprocess env to prevent leak (#74817) #74951, fix(tools): selectively strip Hermes-venv PYTHONPATH from subprocesses (#74817) #78917, fix(tools): isolate subprocess Python environments (#74817) #82581, and this one). The community-converged approach (fix(tools): isolate subprocess Python environments (#74817) #82581) strips only Hermes-owned PYTHONPATH entries (_strip_hermes_owned_pythonpath — repo root + own venv site-packages), preserving user-configured paths; this PR's blanket addition of PYTHONPATH to _ACTIVE_VENV_MARKER_VARS strips user paths too, which contradicts that approach and risks breaking user setups. Closing in favor of fix(tools): isolate subprocess Python environments (#74817) #82581.

2. Bundled unrelated change: this PR also carries a signal.py SSE→polling rework that belongs to fix(gateway/signal): poll /v1/receive instead of broken /v1/events SSE (#71636) #71884's scope ([Bug]: Signal adapter's SSE endpoint (/v1/events) doesn't exist in signal-cli-rest-api 0.100 (native or json-rpc mode) — incoming messages never delivered #71636), not PYTHONPATH leaks into terminal-tool subprocesses on macOS/Linux, can crash unrelated third-party apps #74817. The bundled commit was noted by triage; splitting would leave a small PYTHONPATH diff that still loses to fix(tools): isolate subprocess Python environments (#74817) #82581's surgical approach.

Branch left for manual cleanup.