Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug]: hermes-tui npmDepsHash is out of date (same root cause as #15272/#15244) [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#15314•Fetched 2026-04-25 06:22:59
View on GitHub
Comments
2
Participants
3
Timeline
9
Reactions
2
Author
sudermansuderman
Participants
alt-glitchalt-glitchjerome-benoitjerome-benoitsudermansuderman
Timeline (top)
labeled ×4commented ×2cross-referenced ×1referenced ×1

Error Message

ERROR: npmDepsHash is out of date

The package-lock.json in src is not the same as the in /nix/store/...-npm-deps.

Root Cause

In the commit that introduced the regression (merged around 2026-04-24 14:26–14:48 UTC), ui-tui/package-lock.json was updated but the corresponding npmDepsHash in nix/tui.nix was not refreshed.

The stale hash in nix/tui.nix line 7:

hash = "sha256-RU4qSHgJPMyfRSEJDzkG4+MReDZDc6QbTD2wisa5QE0=";

The lockfile it should match corresponds to:

sha256-/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=

Fix Action

Fixed

PR fix notes

PR #15420: fix(nix): refresh tui + web npmDepsHash to unblock CI on every PR (#15244, #15272, #15314)

Description (problem / solution / changelog)

What does this PR do?

The `Nix Lockfile Check` on `main` has been failing across every open PR for several days because two pinned `fetchNpmDeps` hashes drifted out of sync with the actual `package-lock.json` contents in `ui-tui/` and `web/`.

The CI run prints the correct hash on each failure, so this is a one-character-precision drive-by — both new hashes are exactly what every recent `Nix Lockfile Check` run is reporting (e.g. run 24916813199 from a few minutes ago):

FileOld → New
`nix/tui.nix``RU4qSHgJPMyfRSEJDzkG4+MReDZDc6QbTD2wisa5QE0=` → `/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=`
`nix/web.nix``TS/vrCHbdvXkPcAPxImKzAd2pdDCrKlgYZkXBMQ+TEg=` → `4Z8KQ69QhO83X6zff+5urWBv6MME686MhTTMdwSl65o=`

The drift was caused by recent dependency-touching commits in:

  • `ui-tui/`: PTY WebSocket bridge (`f49afd31`), package.json updates across the chat-unification series (`c61547c0`), `fix(tui): warn on bare null sections in config.yaml` (`bfa60234`)
  • `web/`: docs embedding (`0fdbfad2`), sidebar layout (`e5d2815b`), dashboard extension points (`f593c367`)

None of those PRs ran the `nix flake update` follow-up, so the cached hashes never got refreshed.

Related Issues

  • Closes #15244 (`nix ubuntu check failing on main again`)
  • Closes #15272 (`nix CI broken on main — npmDepsHash out of date`)
  • Closes #15314 (`hermes-tui npmDepsHash is out of date`)

Type of Change

  • 🐛 Bug fix (CI infrastructure)
  • No tests required — pure config update; the existing `Nix Lockfile Check` workflow IS the regression guard for this kind of drift

Test plan

  • Both new hashes are taken verbatim from `Nix Lockfile Check` failure output: the CI computes the correct hash from the actual `package-lock.json` and prints "To correct the hash mismatch for npm-deps, use ..."
  • No production code touched — only the two pinned hashes
  • Once merged: every open PR's `Nix Lockfile Check` lane goes from FAILURE to SUCCESS on its next CI run

Why a separate PR (vs piggybacking on another fix)

This fix unblocks ~30 open PRs at once, including all of mine. Keeping it isolated makes the merge low-risk (1 line per file), explicit in git history, and easy to cherry-pick onto release branches if needed.

Out of scope

  • Automating the hash refresh on every `package-lock.json` change (would need a CI job to compute and commit the hash). `#13136` proposed this with `automatic lockfile fixing to keep main building with nix` but was reverted in `688c9f5b`. Restoring that automation is a bigger conversation; this PR is a narrow unblock for today.

Changed files

  • nix/tui.nix (modified, +1/-1)
  • nix/web.nix (modified, +1/-1)

Code Example

ERROR: npmDepsHash is out of date

The package-lock.json in src is not the same as the in /nix/store/...-npm-deps.

---

hash = "sha256-RU4qSHgJPMyfRSEJDzkG4+MReDZDc6QbTD2wisa5QE0=";

---

sha256-/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=

---

nix build github:NousResearch/hermes-agent#tui
# or
nix flake check

---

hash = "sha256-RU4qSHgJPMyfRSEJDzkG4+MReDZDc6QbTD2wisa5QE0=";

---

hash = "sha256-/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=";
RAW_BUFFERClick to expand / collapse

Bug Description

The hermes-tui derivation (in nix/tui.nix) has a stale npmDepsHash. When building on a clean store, the build fails with:

ERROR: npmDepsHash is out of date

The package-lock.json in src is not the same as the in /nix/store/...-npm-deps.

This is the same class of bug as reported in #15272 (and #15244), but for hermes-tui rather than hermes-web.

Root Cause

In the commit that introduced the regression (merged around 2026-04-24 14:26–14:48 UTC), ui-tui/package-lock.json was updated but the corresponding npmDepsHash in nix/tui.nix was not refreshed.

The stale hash in nix/tui.nix line 7:

hash = "sha256-RU4qSHgJPMyfRSEJDzkG4+MReDZDc6QbTD2wisa5QE0=";

The lockfile it should match corresponds to:

sha256-/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=

Steps to Reproduce

On a clean nix store (or any environment without cached hermes-tui artifacts):

nix build github:NousResearch/hermes-agent#tui
# or
nix flake check

Both fail with the hash mismatch error above.

Expected Behavior

hermes-tui builds successfully on main.

Actual Behavior

Build fails during npmConfigHook consistency check between package-lock.json and the prefetched npm deps.

Affected Component

  • nix/tui.nix — npmDepsHash value
  • ui-tui/package-lock.json — updated without corresponding hash bump

Proposed Fix

Update nix/tui.nix line 7 from:

hash = "sha256-RU4qSHgJPMyfRSEJDzkG4+MReDZDc6QbTD2wisa5QE0=";

to:

hash = "sha256-/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=";

This is the same remediation as suggested in #15272 for hermes-web.

Related Issues

  • #15244: hermes-web stale npmDepsHash (same root cause)
  • #15272: Nix CI broken — duplicate of #15244

extent analysis

TL;DR

Update the npmDepsHash value in nix/tui.nix to match the hash of the updated package-lock.json file.

Guidance

  • Verify the hash mismatch by checking the package-lock.json file in ui-tui and comparing it with the npmDepsHash value in nix/tui.nix.
  • Update the npmDepsHash value in nix/tui.nix to the correct hash: sha256-/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=.
  • Rebuild the hermes-tui derivation using nix build github:NousResearch/hermes-agent#tui or nix flake check to verify the fix.
  • Check the related issues #15244 and #15272 for similar problems and solutions.

Example

# Update the npmDepsHash value in nix/tui.nix
hash = "sha256-/lL0IXurF4WlyFYVVwDI0Btcx0uChHdmKQ8ZW3NQf5E=";

Notes

This fix assumes that the updated package-lock.json file is correct and the npmDepsHash value is the only issue. If the problem persists, further investigation may be needed.

Recommendation

Apply the workaround by updating the npmDepsHash value in nix/tui.nix to the correct hash, as this is a straightforward fix that has worked for similar issues in the past.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#API middleware#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING