Hermes Web UI
A self-hosted browser and phone interface for operating your Hermes Agent.
Per-dimension scores and reasoning
Evidence shows: password auth is off by default but optional password, passkey, OIDC are provided; security headers, SRI, 20MB limit; approval card for dangerous shell commands; attachments stored outside workspace; dependencies only pyyaml and cryptography, but no vulnerability scanning or lock. Deductions: no explicit least-privilege principle, such as process permissions or filesystem access scope; user confirmation only for shell commands, other operations like file deletion or config changes may lack confirmation; data flow transparency limited, no explanation of how data is transmitted to external services; sensitive data handling like API key storage not specified; dependency security lacks vulnerability scanning or lock; external effects like cron jobs or message sending not explicitly limited; rollback mechanism not mentioned; source attribution only via README and pyproject, but publisher unverified.
Evidence shows: README and code comments are consistent, feature descriptions detailed; dependency list clear but no version lock; failure messages like TTS and Office preview return 503 with install hint. Deductions: self-consistency good but no runtime verification; dependency availability no lock or mirror; failure messages exist but not cover all scenarios.
Evidence shows: targets self-hosted users, supports multiple deployment methods (local, Docker, Nix); capability boundaries clear, e.g., no native Windows; trigger precision high, e.g., environment variables and command arguments clear; environment fit good, supports Linux/macOS/WSL2. Deductions: audience and scenarios described well but no specific use cases; capability boundaries clear but no complete limitation list; trigger precision high but no detailed explanation for all configs; environment fit good but no test evidence for all platforms.
Evidence shows: README structure clear, includes TOC, quick start, features, config; install notes detailed, including bootstrap.py, start.sh, ctl.sh; naming stable, e.g., HERMES_WEBUI_* env vars; examples and FAQ via docs directory; known limitations mentioned in README (e.g., Windows not supported); license MIT; version and changelog not provided explicitly, but pyproject uses setuptools-scm; maintenance responsibility via GitHub issues and contributors list. Deductions: information architecture good but no full doc index; install notes detailed but not for all platforms; naming stable but no version history; examples and FAQ not provided with specific content; known limitations not comprehensive; license clear; version and changelog not provided; maintenance responsibility not explicit.
Evidence shows: output usability high, provides multiple export formats (Markdown, JSON); marginal value high, provides CLI parity and Web UI; cost-benefit good, minimal dependencies, no build step. Deductions: output usability no actual output examples; marginal value no comparison data; cost-benefit no performance or resource usage data.
Evidence shows: feature claims in README supported by screenshots and docs; cross-source verification limited, only README and code; fact and inference separation unclear. Deductions: claim traceability insufficient, no specific test results; cross-source verification insufficient, no third-party verification; fact and inference separation unclear, README mixes facts and marketing language.
- Password auth is off by default; enable and configure a strong password if deploying beyond localhost.
- Dependencies are not version-locked; use a virtual environment and update regularly.
- No rollback mechanism; back up the state directory before upgrades.
- Publisher is unverified; review the code before use.
What does this agent do, and when should you use it?
Hermes Web UI is a lightweight browser interface for Hermes Agent, built with a Python standard-library HTTP server and vanilla JavaScript rather than a framework or build pipeline. Its three-panel interface combines session navigation, streaming chat, and workspace file browsing, with model, profile, and workspace controls in the composer footer. By default it runs Hermes Agent in-process and reads the existing HERMES_HOME configuration and model setup instead of routing chat through an external Hermes API server. It exposes sessions, projects, tags, scheduled tasks, skills, memory, profiles, and workspace file operations, with deployment options for SSH tunnels, Tailscale, Docker, and Nix/NixOS. It is best suited to people already operating Hermes Agent who want a persistent graphical client, but WebUI and Hermes Agent should be upgraded or pinned together because the current runtime remains coupled to Agent internals and state layout.
bootstrap.py, start.sh, or ctl.sh starts server.py, which provides HTTP routing, authentication middleware, and the /health endpoint; api/streaming.py runs run_agent through SSE and supports cancellation and compression. messages.js sends turns, handles incremental responses, and recovers sessions, while sessions.js handles session CRUD, search, import/export, and the CLI state.db bridge. workspace.js browses, previews, creates, edits, renames, deletes, and downloads workspace files. api/routes.py dispatches GET and POST handlers; api/auth.py supports passwords, signed cookies, passkeys, and OIDC; api/profiles.py switches Hermes profiles; and the panels operate cron jobs, skills, MEMORY.md, and USER.md. The chat interface renders tool-call cards, subagent delegation cards, Mermaid diagrams, reasoning blocks, context usage, and approval cards for dangerous shell commands.
- A person running Hermes Agent on a home server or VM who wants to reach the same sessions, memory, and workspace from a laptop browser through an SSH tunnel.
- A mobile user who wants access to their self-hosted agent through Tailscale with HERMES_WEBUI_HOST=0.0.0.0 and password protection enabled.
- A researcher or developer who needs to organize ongoing agent work with projects, tags, pinned sessions, archives, full-text search, and Markdown or JSON exports.
- An operator who has Hermes run cron work while they are offline and needs the Tasks panel to create, edit, run, pause, resume, delete, and inspect scheduled jobs.
- A user working against a local project who wants the agent chat beside a workspace panel that previews code, Markdown, images, and Git status and performs file operations.
- A user maintaining multiple model or environment setups who needs to create, clone, and switch Hermes profiles without restarting the WebUI server.
What are this agent's strengths and limitations?
- It runs against the existing Hermes Agent, HERMES_HOME, and configured models in-process, avoiding a separate chat API service and duplicate agent state.
- One self-hosted interface combines streaming chat, session organization, cron jobs, skills, memory, profiles, and editable workspace file browsing.
- SSE streaming includes reconnect handling, queued sends, cancellation, editing earlier user messages, and one-click retries for longer-running work.
- It has documented bootstrap and daemon launchers, Docker Compose including multi-container options, plus a Nix flake and NixOS service module.
- It supports Hermes API providers across multiple vendors, explicitly including OpenAI, Anthropic, Google, DeepSeek, Nous Portal, OpenRouter, MiniMax, Xiaomi MiMo, and Z.AI.
- The runtime currently imports Hermes Agent modules and reads Agent state layout directly; version skew can cause import or behavior drift, and the documented policy is to upgrade or pin both together.
- Adoption requires Hermes Agent, a usable Python environment, and a configured model provider; system Python may lack Agent dependencies such as openai and httpx.
- It binds to localhost by default; network or Tailscale access requires host configuration and should use password protection.
- In the two-container deployment, tools triggered from WebUI run in the WebUI container rather than the Agent container, so missing git, node, or similar tools may require a single container or image extension.
- The bootstrap does not support native Windows, and the documented community-native path has caveats around POSIX-style paths and agent tools that assume bash.
How do you install or deploy this agent?
Configure Hermes Agent and at least one usable model provider first. Then run:
git clone https://github.com/nesquena/hermes-webui.git hermes-webui
cd hermes-webui
python3 bootstrap.pybootstrap.py detects Hermes Agent, attempts the official installer if it is missing, finds or creates a Python environment with WebUI dependencies, starts the server, waits for /health, and opens a browser. Native Windows is not supported by this bootstrap; use Linux, macOS, or WSL2. You can also start with ./start.sh. The test runner supports Python 3.11, 3.12, and 3.13.
How do you use this agent?
Complete the in-browser onboarding after the first launch. If no provider is configured, the wizard directs you to run hermes model. The default server is 127.0.0.1:8787 and chat uses the active Hermes Agent configuration under HERMES_HOME. Send turns from the composer and use commands such as /help, /model <name>, /workspace <name>, /new, /usage, and /theme; use Hermes Control Center for import/export, preferences, and system settings. For remote use, keep the server local and run ssh -N -L 8787:127.0.0.1:8787 user@host, then open http://127.0.0.1:8787 locally. If you use ./ctl.sh start for a daemon, manage it with ./ctl.sh status, ./ctl.sh logs --lines 100, and ./ctl.sh stop.
How does this agent compare with similar options?
The repository compares Hermes with OpenClaw, Claude Code, Codex CLI, and OpenCode. Its stated distinction is Hermes's automatic cross-session memory, self-hosted cron, access through more than ten messaging platforms, and self-saved skills; this repository supplies the self-hosted Web UI for those Hermes capabilities. Compared with Claude Code or Codex CLI, the WebUI can also display subagent delegation activity, and the README states that Hermes can orchestrate Claude Code or Codex for heavy coding work.