Docker: Chat tab broken — npm install fails with EACCES due to root-owned node_modules

[renne]

Summary

When running the dashboard via Docker with HERMES_DASHBOARD_TUI=1, the Chat tab immediately shows [session ended] and no input is accepted.

Root Cause

/opt/hermes/ui-tui and its subdirectories (including packages/hermes-ink/node_modules) are owned by root in the Docker image, but the dashboard process runs as uid 10000 (hermes) after privilege drop in entrypoint.sh.

When the Chat tab opens a WebSocket connection, _make_tui_argv() in hermes_cli/main.py calls npm install in /opt/hermes/ui-tui. This fails with:

npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: '/opt/hermes/ui-tui/packages/hermes-ink/node_modules/@esbuild/aix-ppc64'

_make_tui_argv then calls sys.exit(1), which is caught as SystemExit in pty_ws() (web_server.py line ~3007) and results in the WebSocket closing immediately — shown to the user as [session ended].

The same issue affects /opt/hermes/node_modules.

Steps to Reproduce

1. Run hermes-dashboard via Docker Compose (standard setup from docs)
2. Set HERMES_DASHBOARD_TUI=1
3. Open the dashboard and click the Chat tab
4. Observe [session ended] — typing is not possible

Fix

Add a chown in the Dockerfile before the image is finalized:

RUN chown -R hermes:hermes /opt/hermes/ui-tui /opt/hermes/node_modules

This ensures the hermes user (uid 10000) can write to node_modules when npm install runs at Chat tab startup.

Environment

• Image: nousresearch/hermes-agent:latest (v0.12.0, 2026.4.30)
• HERMES_DASHBOARD_TUI=1
• Linux/amd64, Docker Compose

[alt-glitch]

Related to #12243 — same Docker npm install failure pattern, but root cause here is specifically file ownership (EACCES) after privilege drop to uid 10000.

[alt-glitch]

Related to #12243

[vroomfondel]

Adding a second-trigger finding from a v2026.4.30 deployment that's still broken even with #19520 cherry-picked locally.

_tui_need_npm_install() has two independent false-positive paths; PR #19520 only addresses one of them.

Trigger 1 (FIXED by #19520): npm 9 drops "peer": true from the hidden node_modules/.package-lock.json for dev-deps that are also peers; the field-level diff fires comparable() != comparable(). #19520 adds "peer" to _NPM_LOCK_RUNTIME_KEYS, fixing this.

Trigger 2 (UNFIXED in main): the ui-tui/ tree is an npm-monorepo workspace setup. The root package-lock.json lists the workspace package explicitly:

"packages/hermes-ink": { "link": true, "resolved": "packages/hermes-ink" }

plus 8 transitive deps under packages/hermes-ink/node_modules/.... The hidden lockfile (node_modules/.package-lock.json) intentionally omits those workspace packages/... entries — it only records the symlink wrapper at node_modules/@hermes/ink with "resolved": "file:packages/hermes-ink".

The "missing-from-installed" check in _tui_need_npm_install thus fires for 9 entries on every launch, regardless of #19520:

# pod that's been running for 30s, no edits to ui-tui:
import json; from pathlib import Path
root = Path("/opt/hermes/ui-tui")
wanted    = json.loads((root/"package-lock.json").read_text())["packages"]
installed = json.loads((root/"node_modules/.package-lock.json").read_text())["packages"]
missing   = [k for k in wanted if k not in installed
             and not (wanted[k].get("optional") or wanted[k].get("peer"))]
print(len(missing), missing[:3])
# 9  ['', 'packages/hermes-ink', 'packages/hermes-ink/node_modules/@alcalzone/ansi-tokenize']

Suggested patch: skip workspace-link entries in the missing-check, e.g.

missing = [k for k in wanted
           if k not in installed
           and not (wanted[k].get("optional") or wanted[k].get("peer")
                    or wanted[k].get("link"))]

Reproducible at nousresearch/hermes-agent:v2026.4.30. With both triggers defeated (or with a writable-node_modules workaround like a tmpfs/initContainer copy + chown), the chat tab launches normally.