hermes_venv_python() only looked at \HERMES_PYTHON\ and \~/.hermes-venv\
(the uv-pip layout), but ClawPanel's default \install_hermes\ runs
\uv tool install\ and lands the Python at
\<uv tool dir>/hermes-agent/{Scripts,bin}/python\. Result: any code path
that funnels through \
un_venv_python_json\ — most importantly the
'可选依赖管理 / Optional Dependencies' page (hermes_lazy_deps_*) — refused
to start with 'Hermes venv 未找到(~/.hermes-venv 不存在)。请先安装 Hermes。',
even on machines where Hermes was already installed and Profile / Channels /
Dashboard pages worked fine.
Refactor:
- Extract \hermes_uv_tool_root()\ (resolves \<uv tool dir>/hermes-agent\).
- Add \hermes_uv_tool_python()\ (returns Scripts/python.exe on Windows,
bin/python on Unix).
- Reuse \hermes_uv_tool_root()\ from the existing
\locate_hermes_cli_package_dir()\ so the two helpers share one source
of truth.
- \hermes_venv_python()\ now falls through to the uv-tool path after
\HERMES_PYTHON\ and \~/.hermes-venv\. Error message updated to list
every probed location so users on truly-uninstalled machines still get
actionable feedback.
Verified end-to-end: the actual installed venv at
\%APPDATA%/uv/tools/hermes-agent/Scripts/python.exe\ runs
\rom tools.lazy_deps import LAZY_DEPS\ cleanly and reports 25 features.
Upstream hermes-agent 0.14.0 (both the PyPI wheel and the public git source
at NousResearch/hermes-agent) ships hermes_cli/web_server.py with hard imports
of hermes_cli.dashboard_auth.{audit,middleware,prefix,routes,ws_tickets} but
those source files are not included in the distribution, and the dashboard
SPA bundle (hermes_cli/web_dist/) is also missing. On Windows this makes
'hermes dashboard' crash on startup, which collapses every ClawPanel page
that talks to port 9119 (Profile / Kanban / OAuth / Channels / Sessions
detail) into a 'request rejected by target machine' error.
Per project policy we do not patch upstream. Instead, after each install /
upgrade and again before spawning the dashboard, ClawPanel now injects a
minimal pass-through stub into the installed venv:
- hermes_cli/dashboard_auth/{__init__,audit,middleware,prefix,routes,
ws_tickets}.py — no-op providers, safe on loopback (127.0.0.1) where
the auth gate is intentionally disabled.
- hermes_cli/web_dist/index.html + assets/ — so mount_spa() takes the
token-injecting branch instead of the 'Frontend not built' 404 branch.
Without this the panel can never scrape window.__HERMES_SESSION_TOKEN__
from the dashboard HTML and every /api/* call fails with 401.
Injection is idempotent: if upstream eventually ships the real files, the
stub writer skips them so the real implementation wins. Failures are
logged-and-swallowed so install/upgrade is never blocked by best-effort
compatibility patches.
Group-chat page is also fixed: hermes_agent_run resolves to the run_id
string (not a result object), so the page was rendering 'run_xxx...' as
the assistant reply. It now listens to hermes-run-{started,delta,done,
error,cancelled} events and resolves to payload.output (with accumulated
delta as fallback).
update_hermes only passed --with croniter, while install_via_uv_tool
passes --with croniter --with httpx --with openai --with aiohttp --with
websockets. After running "Upgrade Hermes" from the panel, the four
missing deps disappeared from the uv tool venv. "hermes gateway run"
then started successfully (cron-only mode) but the api_server platform
adapter failed to construct because aiohttp was absent, so port 8642
never came up and the panel hung on "starting...".
Extract HERMES_RUNTIME_EXTRA_DEPS as a single source of truth plus
append_hermes_runtime_extras and hermes_runtime_extras_log_segment
helpers, and route both install_via_uv_tool and update_hermes through
them so future dep additions cannot drift between the two paths.
Fixes#127 — sync_providers_to_agent_models now uses cleaned (merged+stripped) config instead of raw frontend payload, preventing partial writes from dropping other providers from agents/*/agent/models.json.
Fixes#294 — Move version-manager paths (nvm/fnm) before hardcoded system paths (/usr/local/bin etc.) on macOS and Linux so the user's nvm-managed Node is detected first.
Co-authored-by: friendfish