# OpenClaw Dashboard reads your agent config instead of storing it

> OpenClaw Dashboard is a Next.js and TypeScript interface that reads `~/.openclaw/openclaw.json` and local session files rather than a database, then layers model tests, token charts, Feishu alerts and a pixel-art office on top. The rough edges are a single built-in provider table, an operator token you paste into localStorage by hand, and a Docker stage that expects a build output nothing published shows.

**xmanrui/OpenClaw-bot-review** — A lightweight web dashboard for viewing all your OpenClaw Bots/Agents/Models/Sessions status at a glance.

- Repository: https://github.com/xmanrui/OpenClaw-bot-review
- Stars: 2,020 · Forks: 381
- Language: TypeScript
- License: MIT
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/xmanrui-openclaw-bot-review

## Reading one config file instead of running a database

OpenClaw Dashboard is a Next.js and TypeScript web interface that renders whatever `~/.openclaw/openclaw.json` and the local session files contain when a page is requested. There is no schema to migrate and no cached copy to reconcile, but every card on the Bot Overview wall is only as fresh as the last read. Each card carries an agent name, an emoji, its bound model, platform bindings, session counters and a gateway health badge.

Session Management goes deeper, splitting conversations into DM, group and cron types and pairing token usage with a connectivity test for each one. Statistics then charts token consumption and average response time as SVG lines, grouped by day, week or month. The bargain is explicit: this is a reader, not a recorder, so anything your config does not already track simply has no column here.

The prerequisite is equally strict. Node 18 and above plus an OpenClaw install with its config at the default path are the stated requirements, so on a machine that has never run an agent this dashboard has nothing at all to draw.

## Four npm commands and a comment naming the wrong script

Getting started is the four command block printed under Getting Started, then a browser pointed at `http://localhost:3000`.

```bash
git clone https://github.com/xmanrui/OpenClaw-bot-review.git
cd OpenClaw-bot-review
npm install
npm run build
npm run start
```

The comment printed above that last line reads `# Start dev server`, yet package.json binds `start` to `next start` and keeps a second script wired to `next dev`. Your first run therefore serves the compiled production output rather than hot reloading, and any component edit needs another `npm run build` before it appears. The dependency line is Next.js 16 on React 19, styled with Tailwind CSS 4 through the `@tailwindcss/postcss` plugin. Version floor and container base disagree as well: Node 18 and above is the stated requirement, while the image pins node 22 alpine.

The Chinese half of the README repeats the same quick start, then breaks off mid-command at `git clone https://github.com/xmanrui/` with no repository name after the trailing slash. Copying that line verbatim clones nothing.

## A runner stage that expects a standalone build output

The Dockerfile is a two stage build on `node:22-alpine`. The builder installs and compiles, and the runner copies three paths out of that stage, one of which is the standalone build output.

```dockerfile
FROM node:22-alpine AS builder
RUN npm install && npm run build
COPY --from=builder /app/.next/standalone ./
CMD ["node", "server.js"]
```

`/app/.next/standalone` exists only when Next.js is configured to emit standalone output. `next.config.mjs` does sit at the repository root, but the documentation never reproduces what is inside it, so that switch cannot be verified from what a reader is given. Leave it off and the copy step has no source directory, so the image never gets as far as `server.js`.

The two run commands make the exposure explicit. The plain form publishes container port 3000 on every host interface, with no volume mount and no token variable set:

```bash
docker run -d -p 3000:3000 openclaw-dashboard
```

The longer form binds a host directory into `/opt/openclaw` and points `OPENCLAW_HOME` at it, which is the route for a config that does not live under the container user's home.

## An operator token traveling from the shell into localStorage

The Self-Improvement and R&D Council actions are the only part of this project documented to write to disk, touching `rd-council-items.json`, `idea_ledger.json`, decision logs and local work-order handoff state. Those endpoints are gated by a token handed over through the environment:

```bash
OPENCLAW_OPERATOR_TOKEN="replace-with-a-long-random-token" npm run start
```

The same value is then pasted into the browser for the dashboard origin by hand, and there is no login form to do it for you:

```js
localStorage.setItem("openclaw_operator_token", "replace-with-a-long-random-token")
```

An escape hatch exists, and the README names exactly where not to pull it:

```bash
OPENCLAW_ALLOW_UNAUTHENTICATED_LOCAL_OPERATOR_UI=true npm run start
```

That mode falls back to localhost checks only, and the documentation rules it out on a tunnel, a shared host, a reverse proxy or a public network. Mind the scope: the token covers the operator APIs, and no other page of this interface has any documented authentication. One detail rewards a closer look, since both `idea_ledger.json` and `rd-council-items.json` also appear among the repository's top level entries, meaning the files those calls write are shipped inside the clone.

## One provider in the metadata table, two models, one API type

Automatic enrichment of model details is hardcoded for exactly one provider. The supported table lists MiniMax with `MiniMax-M2.7` and `MiniMax-M2.7-highspeed`, described as OpenAI-compatible against the base URL `https://api.minimax.io/v1`.

Against that, the Model List panel promises context window, max output, reasoning support and a per-model test for every configured provider. Anything outside the single row is drawn from whatever fields your own config happens to carry, so context window and max output fill in for MiniMax and stay empty everywhere else. Registering a provider means hand editing a JSON file:

```json
{
  "providers": {
    "minimax": {
      "baseUrl": "https://api.minimax.io/v1",
      "api": "openai-completions",
      "apiKey": "your-minimax-api-key",
      "models": [
        { "id": "MiniMax-M2.7", "name": "MiniMax-M2.7" },
        { "id": "MiniMax-M2.7-highspeed", "name": "MiniMax-M2.7-highspeed" }
      ]
    }
  }
}
```

That snippet puts a live `apiKey` into a file the dashboard reads and renders. Nothing published states whether the Model List page masks key values before they reach HTML, so treat every port 3000 you expose as one that might show them.

## Two test harnesses chained and work files in the tree

The test script in package.json drives two different runners back to back:

```bash
vitest run __tests__ && node --test tests/*.test.mjs
```

Because the two are joined by a shell AND, a failing Vitest pass short circuits the Node runner, and you learn nothing at all about the second tree. Both `__tests__/` and `tests/` sit at the top level next to `test-results/`. That same level also holds `prd/`, `myconfig.txt` and `docs/` beside the application code under `app/`, `components/` and `lib/`, which reads like a working checkout rather than a cleaned up handoff. Vitest 4.1.1 is the only entry in devDependencies.

The package is named `openclaw-bot-review` and marked `"private": true`, so this is something you run from a clone rather than install as a dependency. The last push landed on 2026-07-18, and package.json carries version 3.0.0.

## Alert rules with one delivery channel and no documented home

The Alert Center covers two rule types, a model that has gone unavailable and a bot that has stopped responding, and delivers notifications through Feishu. Discord shows up elsewhere in the same feature list as a bindable platform with a one-click connectivity test, yet no documented route carries an alert to it. A Discord user gets the read-only views and nothing from the alerting side.

Where the rules themselves persist is the part nobody documented. With no database anywhere in the design and no write path described for alert rules, there is no stated place to look for them after a restart.

For plain gateway state the README already offers a different route: the gateway indicator carries a one-click jump to the OpenClaw web UI, which is the same status without any file parsing. What this project adds is derived from the config and session files on the machine where it runs, so it sees only what is readable from `~/.openclaw/openclaw.json` there and nowhere else.

## Ten second polling set against a manual refresh option

Auto refresh offers manual, 10s, 30s, 1min, 5min and 10min. Gateway health polls on its own 10s cycle, so even the fastest automatic setting can leave a badge up to 10 seconds behind the gateway it watches, and the manual option leaves every figure frozen until you reload the page yourself. No push channel or websocket is documented anywhere, so the choice is between stale and chatty rather than between polling and live.

The same shell carries a Chinese and English language switch and a dark and light theme switcher in the sidebar. Pixel Office is the piece with no functional counterpart in the rest of the project: agents appear as pixel characters that walk, sit at desks and interact with furniture in real time, described as inspired by Pixel Agents. It reads the same agent list as the card wall, which makes it another rendering of that config file rather than a second data source.

## Conclusion

Adopt this when you already run several OpenClaw agents on one machine and want a single screen for session types, token usage and gateway state. Leave it for a multi-host setup, because everything is derived from one local config file. Code is MIT licensed, so forking is unobstructed. Before exposing port 3000, check three things: that your Node version builds cleanly under `next start`, that `OPENCLAW_OPERATOR_TOKEN` is set if you will touch the R&D Council endpoints, and that one provider row covers your model list.

## FAQ

### What does OpenClaw Dashboard read to show agent status?

It reads `~/.openclaw/openclaw.json` plus local session files directly, so there is no database to provision and no migration to run. `Node.js 18+` and an existing OpenClaw install are the stated requirements, and the dashboard has nothing to draw without them.

### How do I run OpenClaw Dashboard with a config file outside the home directory?

Set the `OPENCLAW_HOME` environment variable to that directory before `npm run build` and `npm run start`. In Docker, mount the host directory into the container and pass the same variable, as in the documented `-v /path/to/openclaw:/opt/openclaw` example.

### Do the R&D Council actions in OpenClaw Dashboard need authentication?

They do by default, because they write local files such as `rd-council-items.json` and `idea_ledger.json`. Set `OPENCLAW_OPERATOR_TOKEN` in the environment and paste the same value into the browser for the local dashboard origin, since `OPENCLAW_ALLOW_UNAUTHENTICATED_LOCAL_OPERATOR_UI` is documented as unsafe outside localhost.

### Which providers get automatic model details in OpenClaw Dashboard?

Only MiniMax, with `MiniMax-M2.7` and `MiniMax-M2.7-highspeed` against `https://api.minimax.io/v1`. Any other provider is shown from the fields your own config carries, so context window and max output tend to stay empty.

### Can OpenClaw Dashboard be built and run with Docker?

The repository ships a Dockerfile with a two stage `node:22-alpine` build, and `docker run -d -p 3000:3000 openclaw-dashboard` starts the result. The runner stage copies `/app/.next/standalone`, which depends on standalone output being enabled in the Next.js config.

## Sources

- [Issues](https://github.com/xmanrui/OpenClaw-bot-review/issues)
- [License: MIT](https://github.com/xmanrui/OpenClaw-bot-review/blob/main/LICENSE)
- [README](https://github.com/xmanrui/OpenClaw-bot-review/blob/main/README.md)
- [Releases](https://github.com/xmanrui/OpenClaw-bot-review/releases)
- [xmanrui/OpenClaw-bot-review on GitHub](https://github.com/xmanrui/OpenClaw-bot-review)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xmanrui-openclaw-bot-review