[Bug]: hermes dashboard --tui shows [session ended] after v0.13.0 update — TUI build fails when triggered via PTY WebSocket handler

Bug Description

After updating to v0.13.0, hermes dashboard --tui opens the web UI but the Chat tab immediately shows [session ended] without ever starting a session. hermes chat and hermes --tui both work fine.

Steps to Reproduce

Steps to reproduce

1. Install or update to Hermes v0.13.0
2. Configure a custom provider (e.g. Ollama) — Anthropic/OpenAI keys not required to reproduce
3. Run hermes gateway
4. Run hermes dashboard --tui
5. Wait for "Hermes Web UI → http://127.0.0.1:9119" to appear
6. Browser opens automatically (or open manually)
7. Click the Chat tab
8. Observe [session ended] immediately with no session starting

What you will NOT see (confirming it's dashboard-specific):

• hermes chat works fine
• hermes --tui works fine
• npm run build inside ui-tui/ succeeds fine
• The web dashboard itself loads and all non-chat tabs work

Expected Behavior

hermes dashboard --tui should either skip the staleness rebuild when dist/entry.js already exists and is valid, or the rebuild triggered from the PTY WebSocket context should succeed the same way it does from the CLI.

Actual Behavior

After updating to v0.13.0, hermes dashboard --tui opens the web UI but the Chat tab immediately shows [session ended] without ever starting a session. hermes chat and hermes --tui both work fine.

Affected Component

CLI (interactive chat), Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

N/A (CLI only)

Debug Report

Report       https://paste.rs/mCE3R
  agent.log    https://paste.rs/jT3Xc
  gateway.log  https://paste.rs/DjhAw

Operating System

macOS (Apple Silicon / x86_64)

Python Version

3.11.15

Hermes Version

v0.13.0 (2026.5.7)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

When the browser connects to /api/pty, _resolve_chat_argv calls _make_tui_argv which calls _tui_build_needed. Since the v0.13.0 git pull updates .ts/.tsx source file mtimes, the staleness check always returns True and triggers a rebuild. The rebuild fails silently inside the web server's async context, _make_tui_argv calls sys.exit(1), pty_ws catches it as SystemExit and tries to send an error frame to the WebSocket, but the client has already disconnected — resulting in a silent [session ended].

The TUI build itself (npm run build in ui-tui/) succeeds fine when run manually from the CLI.

Evidence from logs

tui_gateway_crash.log showed:

gateway exit · reason=startup write failed (broken stdout pipe before first event)
BrokenPipeError: [Errno 32] Broken pipe

errors.log showed repeated:

WARNING tui_gateway.server: display.personality is set but agent.personalities is empty/null

Server-side ASGI traceback showed:

File "web_server.py", line 3022, in pty_ws
    await ws.send_text(f"\r\n\x1b[31mChat unavailable: {exc}\x1b[0m\r\n")
starlette.websockets.WebSocketDisconnect

Additional notes

The display.personality / agent.personalities warning appears on every TUI gateway startup after v0.13.0 — the personality config schema changed but the migration doesn't carry over existing display.personality values to the new agent.personalities block.

Proposed Fix (optional)

Setting HERMES_TUI_DIR to the absolute path of ui-tui/ bypasses the staleness check and goes straight to node dist/entry.js:

export HERMES_TUI_DIR=/absolute/path/to/.hermes/hermes-agent/ui-tui
hermes dashboard --tui

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[jeffkerby]

I wanted to add another data point here because I ran into what appears to be the same issue on a Hostinger VPS using Docker Manager.

Symptoms I saw:

• Hermes dashboard loaded successfully
• Gateway showed as running
• Model showed live
• Manual TUI worked
• /api/ws returned 101 Switching Protocols
• /api/pty was the failing point
• Dashboard Chat initially showed [session ended] or would load but not accept input
• Running /usr/bin/node /opt/hermes/ui-tui/dist/entry.js manually worked
• PtyBridge.spawn(...) also worked manually
• Docker PTY support was working

The breakthrough was adding this to both my main project .env and the Hermes data .env:

HERMES_TUI_DIR=/opt/hermes/ui-tui

Then I recreated the container cleanly:

docker compose down --remove-orphans
docker compose up -d --force-recreate

After that, the embedded Hermes Dashboard Chat tab started working. I was able to type in the dashboard chat and receive responses.

One small remaining quirk: the model/events panel initially showed disconnected, but after clicking Reconnect a couple of times, the model showed live and the chat continued working.

Hope this helps confirm the workaround for others using Hostinger/Docker deployments.

[willgryan]

Adding below to my compose fixed this issue.

HERMES_TUI_DIR=/opt/hermes/ui-tui

[teknium1]

Triage note: PR #22734 (titled 'fix(web): sync dashboard chat URL after TUI session changes') does NOT fix this issue — that PR addresses dashboard URL-sync polish (PTY → URL direction) and assumes a TUI session has started successfully. Your bug is upstream of that: the TUI session never starts because _tui_build_needed returns True after git pull (mtimes refreshed), _make_tui_argv triggers a rebuild from inside the PTY WebSocket async context, the rebuild fails silently, sys.exit(1) propagates, pty_ws swallows it, and the client sees [session ended].

The right fix is either: (a) skip the staleness rebuild when dist/entry.js exists and is non-empty, or (b) make the rebuild succeed in the async/ws context (no sys.exit on failure, surface the build error). Issue stays open.

[yigit-hur]

The right fix is either: (a) skip the staleness rebuild when dist/entry.js exists and is non-empty

Confirming the triage note is accurate — this matches exactly what I traced. The workaround of setting HERMES_TUI_DIR to the absolute ui-tui/ path bypasses _tui_build_needed entirely and resolves the issue. Option (a) from the triage note would be the cleaner fix. (sent the issue with alt account by mistake will follow through this.)