hermes - 💡(How to fix) Fix [Bug]: hermes dashboard --tui shows [session ended] after v0.13.0 update — TUI build fails when triggered via PTY WebSocket handler [1 pull requests]

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