a11aed1acc
fix(cli): local backend CLI always uses launch directory, stops .env sync of TERMINAL_CWD (#19334)
Siddharth Balyan
2026-05-04 11:36:19 +05:30
434d70d8bc
Merge pull request #19540 from NousResearch/single_container_for_all
Ben Barclay
2026-05-04 15:38:19 +10:00
5671059f62
feat(docker): launch dashboard as side-process via HERMES_DASHBOARD=1 Adds an optional dashboard side-process to the container entrypoint, toggled by HERMES_DASHBOARD=1 (also accepts true / yes). When set, the entrypoint backgrounds hermes dashboard before exec-ing the main command so the user's chosen foreground process (gateway, chat, sleep infinity, …) remains PID-of-interest for the container runtime. docker run -d \ -v ~/.hermes:/opt/data \ -p 8642:8642 -p 9119:9119 \ -e HERMES_DASHBOARD=1 \ nousresearch/hermes-agent gateway run Defaults chosen for the container case: - Host: 0.0.0.0 (reachable through published port; can override to 127.0.0.1 via HERMES_DASHBOARD_HOST for sidecar/reverse-proxy setups) - Port: 9119 (matches hermes dashboard) - Auto-adds --insecure when binding to non-localhost, matching the dashboard's own safety gate for exposing API keys - HERMES_DASHBOARD_TUI is read by hermes dashboard directly — no entrypoint plumbing needed Dashboard output is prefixed with [dashboard] via stdbuf+sed -u so it's easy to separate from gateway logs in docker logs. No supervision: if the dashboard crashes it stays down until the container restarts (documented in the :::note panel). Other changes bundled in: - Deprecate GATEWAY_HEALTH_URL / GATEWAY_HEALTH_TIMEOUT env vars in hermes_cli/web_server.py with a DEPRECATED block comment and a .. deprecated:: note on _probe_gateway_health. The feature still works for this release; it'll be removed alongside the move to a first-class dashboard config key. - Rewrite the "Running the dashboard" doc section around the new single-container pattern. Drops the previously-documented dashboard-as-its-own-container setup — that pattern relied on the deprecated env vars for cross-container gateway-liveness detection, and without them the dashboard would permanently report the gateway as "not running". - Collapse the two-service Compose example (gateway + dashboard container) into a single service with HERMES_DASHBOARD=1. Removes the now-unnecessary bridge network and depends_on. - Drop the ":::warning" caveat about "Running a dashboard container alongside the gateway is safe" — that case no longer exists.
Ben
2026-05-04 15:37:27 +10:00
95f395027f
Merge pull request #19520 from NousResearch/fix_docker_tui
Ben Barclay
2026-05-04 14:29:43 +10:00
2f2998bb1b
fix(tui): tolerate npm's peer-flag drop in lockfile comparison _tui_need_npm_install() compares the canonical package-lock.json against the hidden node_modules/.package-lock.json to decide whether npm install needs to re-run. npm 9 drops the "peer": true field from the hidden lock on dev-deps that are *also* declared as peers (the canonical lock preserves the dual annotation). That made the check flag 16 packages (@babel/core, @types/node, @types/react, @typescript-eslint/*, react, vite, tsx, typescript, …) as mismatched on every launch, triggering a runtime npm install. Inside the Docker image, that runtime install then fails with EACCES because /opt/hermes/ui-tui/node_modules/ is root-owned from build time, so docker run … hermes-agent --tui prints: Installing TUI dependencies… npm install failed. …and exits 1, with no preview. The empty preview is a second bug: the launcher captured only stderr, but npm 9 writes EACCES to stdout, which was DEVNULL'd. Fixes: - Add "peer" to _NPM_LOCK_RUNTIME_KEYS so the comparison ignores the non-deterministic field, alongside the existing "ideallyInert". - Capture stdout as well as stderr in the install subprocess so future failures surface a useful preview instead of a bare "failed." line. Regression tests: - test_no_install_when_only_peer_annotation_differs — the exact scenario - test_install_when_version_differs_even_with_peer_drop — guards against the peer-drop tolerance masking a real version skew On-host impact: the same false-positive was firing on every hermes --tui invocation from a normal checkout, silently running a no-op npm install each time (it converged because the host's node_modules/ is writable). Startup time on the TUI should drop noticeably.
Ben
2026-05-04 14:13:38 +10:00
363cc93674
fix(cron): bump skill usage when cron jobs load skills
Chris Danis
2026-05-02 07:51:22 -04:00
808fee151d
fix(auxiliary): propagate explicit_api_key to _try_anthropic()
nftpoetrist
2026-05-04 00:12:58 +03:00
tmdgusya