Skip to content

fix(dashboard): enable embedded chat by default so the GUI connects - #38907

Closed
teknium1 wants to merge 1 commit into
mainfrom
hermes/hermes-8246dc0a
Closed

fix(dashboard): enable embedded chat by default so the GUI connects#38907
teknium1 wants to merge 1 commit into
mainfrom
hermes/hermes-8246dc0a

Conversation

@teknium1

@teknium1 teknium1 commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Plain hermes dashboard now produces a dashboard the GUI can actually connect to — embedded chat is on by default instead of requiring --tui.

Root cause: cmd_dashboard minted embedded_chat = args.tui or HERMES_DASHBOARD_TUI==1, so with no flag the chat WebSocket (/api/ws, /api/pty) closed every upgrade with 4403/4404 before the auth ticket was ever consumed. The desktop GUI needs that socket, so it could never connect unless the operator knew to pass --tui. PR #38743 improved the refusal messaging (split close codes, log reasons) but never flipped the default — so the connection blocker survived.

Changes

  • hermes_cli/main.py: embedded chat is ON by default. --no-tui (or HERMES_DASHBOARD_TUI=0/false/off) is the explicit opt-out for hardened public binds. --tui / =1 remain as explicit-on and win over a stale =0 env.
  • hermes_cli/web_server.py: start_server(embedded_chat=...) default flipped False → True so programmatic callers (desktop app) match the CLI default.
  • Added --no-tui arg; --tui help updated to note default-on.

Security note

The embedded /chat PTY tab spawns a shell-capable agent. With this change it's reachable by default on any bind that passes the auth gate (ticket/internal credential + host/origin + dashboard basic-auth). Operators who bind 0.0.0.0 for a hardened deployment and don't want the in-browser shell should pass --no-tui or set HERMES_DASHBOARD_TUI=0.

Validation

Scenario embedded_chat
hermes dashboard (no flag) True (was False — the bug)
--host 0.0.0.0, no flag True
--tui True
--no-tui False
HERMES_DASHBOARD_TUI=0 / false / off False
--tui + stale HERMES_DASHBOARD_TUI=0 True (explicit-on wins)

10-case argparse E2E all pass. tests/hermes_cli/test_web_server.py + test_web_server_host_header.py: 238 passed (incl. test_rejects_when_embedded_chat_disabled, the explicit-disable path).

Infographic

dashboard-chat-on-by-default

Plain `hermes dashboard` minted embedded_chat=False, so the chat
WebSocket (/api/ws, /api/pty) closed every upgrade with 4403/4404
before the auth ticket was ever consumed. The desktop GUI's chat
connection requires that socket, so it could never connect unless the
operator knew to pass --tui. PR #38743 improved the refusal messaging
but never flipped the default, so the blocker survived.

- main.py: embedded chat is now ON by default. --no-tui (or
  HERMES_DASHBOARD_TUI=0/false/off) is the explicit opt-out for
  hardened public binds; --tui / =1 stay as explicit-on and win over a
  stale =0 env.
- web_server.py: start_server(embedded_chat=...) default flipped to
  True so programmatic callers (desktop app) match the CLI default.
- Added --no-tui flag; --tui help updated to note default-on.

Validation: 10-case argparse E2E (plain/public->ON, --no-tui/env-off
->OFF, --tui wins over stale =0). tests/hermes_cli/test_web_server.py
+ test_web_server_host_header.py 238 passed.
@teknium1

teknium1 commented Jun 4, 2026

Copy link
Copy Markdown
Contributor Author

Closing as redundant. PR #38591 (cae6b54, @benbarclay) already merged the complete fix — embedded chat is unconditional and the dashboard --tui flag is removed entirely. I built this on a stale worktree base from before #38591 landed and didn't check existing PRs first; #38591 is the correct and more thorough fix (also updates the desktop electron spawn, docs, and zh-Hans translations). My apologies for the noise.

@teknium1 teknium1 closed this Jun 4, 2026
@teknium1
teknium1 deleted the hermes/hermes-8246dc0a branch June 4, 2026 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant