Summary

After upgrading from v0.9.0 (v2026.4.13) to v0.10.0 (v2026.4.16) via
pip install --upgrade 'hermes-agent @ git+https://github.com/NousResearch/hermes-agent@v2026.4.16',
every Hermes dashboard /api/* request returns
{"detail":"Unauthorized"} (HTTP 401), making the entire dashboard UI
unusable (Sessions, Logs, Cron, Skills, Analytics tabs all empty/error).

This is the pip-install equivalent of #12177 (Docker, CLOSED) and is
related to #12243 (Docker overlayfs blocks the runtime fallback build).
The Dockerfile fix from #12177 doesn't help wheel users — the wheel
itself still ships only the backend.

Root cause

The 0.10.0 wheel does not include hermes_cli/web_dist/ files in its
RECORD. After install, only two hermes_cli files touch the web area:

$ grep -i "hermes_cli/web" hermes_agent-0.10.0.dist-info/RECORD
hermes_cli/web_server.py,sha256=...,89621
hermes_cli/webhook.py,sha256=...,7606

So:

1. Fresh installs have no web_dist/ at all → page itself 404s.
2. Upgrade installs keep whatever web_dist/ was there from the
   previous version. In my case the v0.9.0 SPA from a previous install
   (index-CqypI-we.js dated Apr 14) survived. v0.10.0's new
   web_server.py introduces ephemeral session-token auth on every
   /api/* route via window.__HERMES_SESSION_TOKEN__ injection into
   index.html, but the old SPA bundle has no code that reads that
   token or sets the Authorization: Bearer ... header. Result: every
   API request → 401.

There's also no hermes_cli/web/ source directory in the wheel, so
the runtime "Building web UI..." fallback path mentioned in #12243
can't fire on pip-install hosts either — there's nothing to build
from. (And many production hosts won't have npm/Node installed at
all.)

Verification (server side is fine)

With a valid token extracted from index.html, every endpoint works:

TOKEN=$(curl -s http://localhost:9119/ | grep -oE '__HERMES_SESSION_TOKEN__="[^"]+"' | sed 's/.*="//;s/"//')
for ep in /api/sessions /api/cron/jobs /api/skills /api/tools/toolsets /api/logs /api/analytics/usage; do
  curl -s -o /dev/null -w "%{http_code} $ep\n" -H "Authorization: Bearer $TOKEN" "http://localhost:9119$ep"
done
# 200 /api/sessions
# 200 /api/cron/jobs
# 200 /api/skills
# 200 /api/tools/toolsets
# 200 /api/logs
# 200 /api/analytics/usage

So web_server.py + auth middleware are correct — the gap is purely
that the SPA dist files needed for the new auth scheme were left out
of the wheel.

Repro (clean install)

python -m venv /tmp/herm-test
/tmp/herm-test/bin/pip install 'hermes-agent @ git+https://github.com/NousResearch/hermes-agent@v2026.4.16'
ls /tmp/herm-test/lib/python*/site-packages/hermes_cli/web_dist/ 2>&1
# → No such file or directory
ls /tmp/herm-test/lib/python*/site-packages/hermes_cli/web/ 2>&1
# → No such file or directory

Suggested fix

Either:

1. Build SPA at wheel-build time and ship the web_dist/ artifacts
   in the wheel (likely a missing MANIFEST.in or pyproject.toml
tool.hatch.build.targets.wheel.force-include / package-data
   entry). This is the simplest path for end users — pip install just
   works.
2. Or ship hermes_cli/web/ source in the wheel and document that
   end users need Node/npm + a manual hermes dashboard --build step
   on first run. (Less friendly; many production hosts don't have
   Node.)
3. Or split the SPA into a separate hermes-agent-web package on
   PyPI with the prebuilt artifacts.

Workaround

Until fixed: stop hermes-dashboard.service and use Telegram / MCP /
CLI access for everything. Backend functionality is unaffected.
Downgrading to v0.9.0 (v2026.4.13) restores the matched
backend+frontend pair.

Environment

• Hermes Agent: v0.10.0 (v2026.4.16)
• Install: pip install --upgrade 'hermes-agent @ git+https://github.com/NousResearch/hermes-agent@v2026.4.16'
• Python: 3.12.3
• OS: Ubuntu 24.04
• Dashboard service: hermes dashboard --no-open --host <Tailscale IP> --port 9119 --insecure

Happy to test a patch.