Claw-Admin is a Vue console that fronts two agent gateways at once

A control panel, not an agent

Claw-Admin describes itself as a modern AI agent management platform built with Vue 3, and the first thing to establish is what it is not. It is not an agent runtime and it does not talk to a model provider on its own. It is a web console that talks to a gateway that already does that, and its job is to make that gateway operable by someone who would rather click than use a terminal.

The gateway question has a specific answer here. The project supports two of them, OpenClaw Gateway and Hermes Agent, and the core features listed in the README are framed as managing agents, sessions, models, channels and skills, plus a full web CLI terminal experience.

The scale of the interface is worth noting, because it is unusually broad for a console. The OpenClaw side covers a dashboard with token usage trends and a live event stream, a chat view, session management with export, memory management, cron scheduling, model management, channel management, skills, multi-agent management, an agent workshop, a virtual company view, a remote terminal, remote desktop, a file browser, system monitoring and settings.

The Hermes side is a parallel set of screens for the same domains, with a dashboard, chat, sessions, models, channels, skills, cron, memory and system management, plus its own CLI terminal.

The licence is MIT, the primary language is Vue, and the project is not archived, with the last push on 2026-04-27.

Two gateways, two transports

The communication split is the part of the architecture that explains most of the code.

For OpenClaw, the transport is WebSocket, and the `.env` example points at a local gateway port.

OPENCLAW_WS_URL=ws://localhost:18789
OPENCLAW_AUTH_TOKEN=1212

For Hermes, the transport is server sent events over HTTP, with two services behind separate URLs.

HERMES_WEB_URL=http://localhost:9119
HERMES_API_URL=http://localhost:8642

The README documents what those two Hermes services are. The Hermes Web UI on port 9119 is the management REST API covering sessions, configuration and skills, and the Hermes API Server on port 8642 is the OpenAI compatible API used for chat, models and runs. A third piece, the Hermes CLI, is a Python tool with no port, and it is what the web terminal drives.

The reason the Hermes terminal deliberately avoids WebSocket is stated in the README, which says it uses pure SSE plus HTTP POST as two channels, and that this keeps it compatible with strict network policies. That is a deliberate constraint, and it explains why the OpenClaw and Hermes halves of the codebase are not symmetrical despite presenting the same features.

The backend stack supports the same picture. The manifest lists `ws` for the WebSocket implementation, `express` for the HTTP layer, `better-sqlite3` for local storage, `node-pty` for the pseudo-terminal, and `ssh2` for SSH access, which is what makes the remote terminal and remote desktop features possible.

A real CLI in the browser that survives a disconnect

The Hermes CLI terminal is the feature the README describes at the greatest length, and it is the one that goes furthest beyond an ordinary web console.

The mechanism is a pseudo-terminal. The README says the real CLI experience works by launching the Hermes CLI process through node-pty, giving full terminal emulation, with the xterm family of packages on the front end, `@xterm/xterm` at version 6, an addon for fitting the terminal to the window and an addon for web links.

The interesting part is persistence. The README says the CLI process is not interrupted when the browser disconnects, with reconnection and output buffer replay supported. A terminal that dies when you close the laptop is a toy, and one that keeps running and lets you reconnect and scroll back through what it printed is a tool. The session model follows from that, with multiple CLI sessions that can be reconnected, detached, renamed and destroyed.

There is also a visual panel for launch arguments, so the CLI flags, which the README names as model, provider, skills, toolsets and yolo, can be set through a form instead of typed. Inside the terminal, the CLI's own commands are available, including `/skills`, `/tools`, `/cron`, `/config` and `/browser`.

The OpenClaw side has a different terminal implementation, described as an SSE based remote terminal with multi-node support, full screen mode and a configurable shell and working directory. So the two gateways get different terminal mechanisms, once again because their backends differ.

One detail to keep in mind when reading the feature list: the Hermes chat supports a large set of slash commands, the README counting 17 or more, with a command palette that autocompletes when you type `/` and supports Tab completion and arrow key selection, and tool calls rendered visually with Markdown, code highlighting and LaTeX formulas.

Memory documents, cron and channels are the real surface

Beyond the dashboard, three functional areas carry most of the operational value.

Memory management is the first. For OpenClaw, the README describes document management for agents with editing support for the AGENTS, SOUL, IDENTITY and USER documents, a Markdown editor and quick insertion of template snippets. The Hermes side does the same for SOUL.md, the persona configuration, and AGENTS.md, the agent instructions. These are the files that define how an agent behaves, and exposing them in a browser editor with a Markdown preview removes the need to edit files on the server by hand.

Task scheduling is the second. The cron module supports cron expressions, fixed intervals and specific times, with execution history and quick templates such as a morning briefing and a health check. The Hermes version adds pause, resume and manual trigger, plus a full CRUD for scheduled jobs. Scheduled jobs are where an agent setup starts to matter on its own, so having them in the console rather than in a config file is a real change.

Channels are the third. The OpenClaw side lists QQ, Feishu, DingTalk and WeCom for Business, with status monitoring, credential management and one click installation, while the Hermes side lists Telegram, Discord and Slack with OAuth authentication management. The channel sets are completely different, which is another reason the two halves of the console are separate code paths rather than one shared abstraction.

The skill management screens complete the picture, with lists of skill plugins, built-in and user categories, installation and update, and a control over whether a skill is visible in chat. Multi-agent management adds identity, model and tool permissions per agent, session statistics, token usage and workspace file management.

Running the console, and the same-node deployment rule

The quick start is a standard Node project, and the requirements are listed precisely.

Node.js 18.0.0 or newer, npm 9.0.0 or newer, and Python 3.10 or newer but only for the Hermes CLI terminal. The dependencies install with a normal npm command.

npm install

The environment file is copied from the example.

cp .env.example .env

For development there are three scripts, one for the front end, one for the back end and one for both.

npm run dev

npm run dev:server

npm run dev:all

The `dev:all` variant runs them together through concurrently, with the frontend and backend given separate labels and colours, and the console is then reachable on port 3001, which is the development port in the example environment file.

Production is a build followed by a start.

npm run build

npm run start

Both the dev server and the production server read the environment file directly through the Node `--env-file` flag, which is visible in the scripts in the package manifest.

    "start": "node --env-file=.env server/index.js"

The deployment rule is the one constraint that can block a plan. The README states that the console must be deployed on the same node as the gateway, and that when the address is written in the `.env` file only `127.0.0.1` or `localhost` are supported. The reason is implicit in the rest of the design, since the console drives a local gateway over a WebSocket and a local pseudo-terminal, and the remote terminal and desktop features reach outward through SSH instead. A console on a separate management host is not something this deployment model supports.

Default credentials are the first thing to change

The example environment file is useful as a map of the configuration, and it is also a list of things to change before anyone else can reach the port.

The defaults are visible.

AUTH_USERNAME=admin
AUTH_PASSWORD=admin

The OpenClaw side has its own token and password, and the example ships a placeholder token value.

OPENCLAW_AUTH_TOKEN=1212
OPENCLAW_AUTH_PASSWORD=

The Hermes side has an API key with a local development value, and the file also carries a `LOG_LEVEL` setting and an optional `OPENCLAW_HOME` path, commented out.

None of this is unusual for an example file, and the point is that the console ships with a public default password for its own login and a token that is not a secret. A console that manages agent memory documents, channel credentials, API keys for model providers and a shell on the gateway node is a sensitive surface, so the credentials have to be changed before the port is exposed to anything but localhost.

There is a second layer in the feature list, and it is worth noticing. API keys in the model management screens are shown masked, and the Hermes environment variable management supports masked display with a plain text view. So the console is designed to hold provider keys, and its own access control is the thing standing in front of them.

The TTS configuration in the same file, with a voice set to zh-CN and rate, volume and pitch values, was added in the v1.0.2 release, and the frontend flag `VITE_TTS_ENABLED` means the text to speech layer is part of the browser build rather than the server.

Three releases in ten days, then a pause

The release history is short and tells a story about the project's stage.

v1.0.0 was published on 2026-04-16 and added Hermes agent support, v1.0.1 followed on 2026-04-18 to fill in Hermes capabilities, and v1.0.2 on 2026-04-26 added the text to speech feature and interface refinements. The package version in the manifest is 1.0.2, matching the newest tag.

The last push was on 2026-04-27. Since then the repository has not moved, and the releases stopped at 1.0.2.

There is a small inconsistency in the documentation that is worth flagging rather than repeating. The version compatibility table in the README lists OpenClaw Admin 0.2.7 as verified against OpenClaw Gateway 2026.4.5 and Hermes Agent 2026.4.9, while the package manifest and the release tags are at 1.0.2. So the table documents a compatibility check for an older build of the console than the one currently shipped, which leaves the supported gateway versions for 1.0.x unstated. Anyone deploying against a specific gateway version should confirm the pairing themselves rather than relying on that row.

The repository itself is a well formed project for this kind of application. There is a `CHANGELOG.md`, a `CONTRIBUTING.md`, an `AGENTS.md` for agent-oriented instructions, a `VERIFICATION_CHECKLIST.md`, a `docs/` directory with the screenshots the README embeds, an English README alongside the Chinese one, and a `server/` directory beside the `src/` front end. The `data/` directory and the `wolai-config.yaml` file suggest some local state and an external notes integration, and the presence of `DYNAMIC_AGENTS_FIX_SUMMARY.md`, `DYNAMIC_AGENTS_ISSUE.md` and `DYNAMIC_AGENTS_USER_GUIDE.md` at the top level points to a feature that was being reworked around the time the releases stopped.

The licence is MIT, so the console can be modified and self-hosted, which is the normal expectation for a tool that has to sit on the same node as your gateway.

Editorial conclusion

Claw-Admin fits an operator who already runs OpenClaw Gateway or Hermes Agent and wants one place to watch sessions, edit agent memory documents, manage channels and skills, and drive a real terminal in the browser. Skip it if you are looking for an agent runtime, since this is a client and control plane, or if you need the console on a different host from the gateway, which the deployment rule forbids. Verify first which gateway versions you have, since the compatibility table names a different admin version than the package manifest, and change the default credentials and tokens in `.env` before you expose the port.

Frequently asked questions

Official sources

1. itq5/OpenClaw-Admin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases