Hermes Agent
Hermes makes installer failures speak before killing their descendants
A Hermes installer report shows blocking npm installs running silently, leaving operators with an abort and no cause. Two proposed fixes replay captured npm output and make timeout enforcement terminate descendant processes rather than only the wrapper.
NousResearch/hermes-agent issue #87340 is the inspected primary source: “install.sh: both install-blocking `npm install` sites run --silent with no output capture, so the failure that now aborts the install is undiagnosable.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- NousResearch/hermes-agent issue #87340 was created 2026-08-16T00:46:19Z and was open at inspection; its title is “install.sh: both install-blocking `npm install` sites run --silent with no output capture, so the failure that now aborts the install is undiagnosable.” - NousResearch/hermes-agent PR #87343 was created 2026-08-16T00:53:04Z and was open at inspection; its title is “fix(install): replay captured npm output when a blocking npm install fails.” - NousResearch/hermes-agent PR #87347 was created 2026-08-16T00:58:55Z and was open at inspection; its title is “fix(install): drop --foreground from run_with_timeout so deadlines kill descendants (#87320).” - The repository reported 231088 stars, 32236 open issues, default branch main, and last push 2026-08-16T01:02:02Z. - The latest tagged-release baseline checked was v2026.8.13 published 2026-08-13T20:37:37Z.
What changed
NousResearch/hermes-agent issue #87340 reports: Summary Since #85537 a failed npm install aborts the installer — correctly, that PR fixed a real false-success bug (#77003). But both install-blocking call sites run npm install --silent with no output capture, so the failure that now stops the install prints exactly one line and no npm diagnostics: There is no way to tell EBADENGINE from ETARGET from a network timeout from a registry 5xx. The failure is fatal and silent at the same time. Affected call sites scripts/install.sh:2311 — browser tools (install_node_deps) scripts/install.sh:2417 — TUI The same file already has the right pattern The camofox path at scripts/install.sh:2799-2804 captures and replays npm's output on failure: So this is a consistency gap, not a new design — the two sites that can abort an install are the two that don't do it. Why this matters now Real users are hitting it and cannot report it.** #87093 (Debian 13.6, clean install via curl | bash) ends on this exact line. It is labelled needs-repro, and the reporter has nothing further to paste, because the installer printed nothing further. That issue cannot progress until this output exists. CI has been red on every scheduled run since 2026-08-13 19:40 UTC**, every leg on the same line: last green: https://github.com/NousResearch/hermes-agent/actions/runs/31679596155 (08-13 07:52 UTC)
NousResearch/hermes-agent PR #87343 reports: What does this PR do? Since #85537, a failed npm install correctly aborts the installer — but both install-blocking call sites run npm install --silent with no output capture, so the failure that now stops the install prints exactly one line and no npm diagnostics (#87340). There is no way to tell EBADENGINE from ETARGET from a network timeout from a registry 5xx; #87093 is stuck at needs-repro precisely because the installer printed nothing further to paste. This PR applies the capture-and-replay pattern the same file already uses for the camofox global install (mktemp log, redirect stdout+stderr, cat the log to stderr on failure, remove it on both paths) to the two blocking sites: install_node_deps root package.json install (browser tools) install_node_deps TUI install The happy path stays --silent; only failures gain output. Related Issue Fixes #87340 Type of Change [x] Bug fix (non-breaking change that fixes an issue) Changes Made scripts/install.sh: both blocking npm install sites now capture npm's output to a temp file and replay it to stderr on failure before returning 1, mirroring the camofox install's existing pattern; comments note why (#87340). tests/test_install_sh_node_deps_failure.py: the two fatal-failure tests now also assert that the stub npm's stderr diagnostic ("simulated npm lifecycle failure") is replayed in the stage's stderr —
NousResearch/hermes-agent PR #87347 reports: What does this PR do? Fixes the root cause behind #87320 ("Install scripts gets stuck on Playwright on Arch"): run_with_timeout() in scripts/install.sh wraps npx playwright install... in timeout --foreground -k 10. Per GNU coreutils' own docs, --foreground means *"children of COMMAND will not be timed out."* npx (the COMMAND passed to run_with_timeout) spawns the actual Playwright install/download work as a **child** node process — the download itself never runs inside npx directly. So when the 600s deadline fires, timeout kills npx, run_with_timeout returns 124, the installer logs "Playwright browser installation failed" and moves on... but the orphaned child node process (the one actually talking to the CDN) is never signaled and keeps running in the background indefinitely. That's what makes the whole curl | bash install look permanently stuck even though the script itself has logically continued — the orphan keeps stdout/the terminal alive. Dropping --foreground lets timeout put COMMAND in its own process group, so the deadline-triggered SIGTERM/SIGKILL escalation (-k 10) reaches that whole group — descendants included — instead of just the immediate process. Verified locally (not just theorized) Reproduced the exact shape with a real npx-wrapped binary that spawns a child node process and backgrounds it: with --foreground, the child process was still alive well
Why it matters
An installer that fails closed but hides the failing command still transfers diagnosis to the operator. Deadlines are also fiction if grandchildren survive the timed process. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-16. The tagged-release baseline was v2026.8.13 published 2026-08-13T20:37:37Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/NousResearch/hermes-agent/issues/87340. Supporting records are https://github.com/NousResearch/hermes-agent/pull/87343 and https://github.com/NousResearch/hermes-agent/pull/87347. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Capture bounded install output, return the real failing stage and exit code, and verify timeout cleanup across the full process tree. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.