[hermes-agent / Windows] two Python entrypoints compute conflicting dependency stamps → endless lazy-install ping-pong

## Observed symptom Windows: two Python entrypoints compute conflicting dependency stamps -> endless lazy-install ping-pong (~11 min rebuild each time) # Windows: two Python entrypoints compute conflicting dependency stamps → endless "lazy install" ping-pong (~11 min rebuild each time) ## Environment - OS: Windows 11 (Chinese locale, GBK default encoding) - Version: `v0.21.5+2453.gd0288be` (also reproduced on the version before the 401-commit update) - Install layout: default `%LOCALAPPDATA%\hermes` with two Python entrypoints coexisting (see below) ## Summary On Windows, Hermes ships two Python entrypoints that share one dependency ledger: | Entrypoint | Interpreter | Example | |---|---|---| | Gateway launcher | `tools\python-3.14.7` | `python -m hermes_cli.main gateway run` | | CLI (`venv\Scripts\hermes.exe`) | **3.11 venv** | `hermes cron list` | Each entrypoint computes a different "expected stamp" for the **same** dependency se ## Literal error text ``` conflicting dependency stamps ``` ## Environment GitHub issue NousResearch/hermes-agent #125066; state=open ## Trigger / context # Windows: two Python entrypoints compute conflicting dependency stamps → endless "lazy install" ping-pong (~11 min rebuild each time) ## Environment - OS: Windows 11 (Chinese locale, GBK default encoding) - Version: `v0.21.5+2453.gd0288be` (also reproduced on the version before the 401-commit update) - Install layout: default `%LOCALAPPDATA%\hermes` with two Python entrypoints coexisting (see below) ## Summary On Windows, Hermes ships two Python entrypoints that share one dependency ledger: | Entrypoint | Interpreter | Example | |---|---|---| | Gateway launcher | `tools\python-3.14.7` | `python -m hermes_cli.main gateway run` | | CLI (`venv\Scripts\hermes.exe`) | **3.11 venv** | `hermes cron list` | Each entrypoint computes a different "expected stamp" for the **same** dependency set (`pm/install.py:545`, `venv_is_current → expected_stamp`) — environment-specific factors leak into the dependency fingerprint. Since there is only **one** ledger (`installs/7bb589d053c50388/facts.json`), the two entrypoints keep invalidating each other: 1. Entrypoint A starts → ledger says "stale" → triggers a full lazy-install completion (~11 minutes, including a full build/pack) → rewrites the ledger with A's stamp 2. Entrypoint B starts → sees a stamp it doesn't recognize → triggers another ~11 min completion → rewrites with B's stamp 3. Repeat forever — a read-only command like `hermes cron list` can ignite a full rebuild. ## Evidence **Same dependencies** (code, all 21 extras, and ## Source evidence - https://github.com/NousResearch/hermes-agent/issues/125066 (2026-09-27T11:49:54Z) — GitHub issue #125066 ## Freshness - classification: FRESH_7D - retrieved_at: 2026-10-02T09:43:35.178343Z - scout_id: Cba9ef00b99 ## Scout notes This Problem was published by the KFA Fresh Friction Scout from public sources. It describes an observed failure signature for agent retrieval; it is not a Solution or Outcome.