OpenClaw Control Center: A Local Dashboard for OpenClaw Agent Observability

What OpenClaw Control Center Solves and Who It Is For

OpenClaw agents produce a stream of state, decisions, task progress, token spend, and execution output that is not easy to read in raw form. OpenClaw Control Center is a local TypeScript server that connects to an OpenClaw runtime over WebSocket and surfaces that data as a browser UI. The README describes the target user as "non-technical operators who need observability and certainty, not raw backend payloads."

Three defaults enforce a safety-first posture: the dashboard is read-only, authentication uses a local token, and mutation routes are disabled until you explicitly enable them. This means an operator can hand access to a non-developer team member without risk of accidental state changes.

The project covers three specific audiences: OpenClaw users who want one local place for observability, tasks, approvals, and memory; teams running OpenClaw on a single machine or reachable local environment; and maintainers who want a public-ready, safety-first dashboard rather than a generic agent platform.

How the Control Center Connects to OpenClaw

The control center connects to a running OpenClaw instance via WebSocket. The default gateway address is ws://127.0.0.1:18789, set in the .env file via the GATEWAY_URL variable. The UI server listens on port 4310 by default, configurable via UI_PORT. In production the server binds to 0.0.0.0, making it reachable over a local network or Tailscale.

For remote access, setting OPENCLAW_CONTROL_UI_URL to a Tailscale host or IP causes the UI to use that base for outbound bridge links. The README gives the example format as `http://<tailscale-host>:4310/`. You can also override UI_BIND_ADDRESS explicitly if you need to restrict which interface the server listens on.

Optional outbound mirroring for task-room and hall events is available for Discord and Telegram. This is controlled by TASK_ROOM_BRIDGE_ENABLED and its corresponding webhook or bot token variables. The .env.example ships with these disabled; the comment states they should remain disabled unless you explicitly want room events mirrored outside the control center.

The hall runtime dispatch, which routes hall discussion and assignment through the real openclaw agent runtime, is controlled by HALL_RUNTIME_DISPATCH_ENABLED. When enabled, the live draft stream reflects actual session execution. When disabled, it falls back to synthetic orchestrator replies useful for testing.

Installing and Running OpenClaw Control Center

The 5-minute start sequence from the README covers install, build, smoke test, and launch:

npm install
cp .env.example .env
npm run build
npm test
npm run smoke:ui
npm run smoke:hall
npm run dev:ui

After the last command, the UI is available at `http://127.0.0.1:4310/?section=overview&lang=en` for English or at `http://127.0.0.1:4310/?section=overview&lang=zh` for Chinese. The README notes that `npm run dev:ui` is the more reliable cross-platform entry, especially on Windows shells, and that `npm run dev` (without `:ui`) performs only one monitor pass and does not start the HTTP UI.

A Docker option is also present. The Dockerfile uses a multi-stage build based on node:22-bookworm-slim. The production container sets UI_MODE=true, UI_PORT=4310, and UI_BIND_ADDRESS=0.0.0.0, then starts the compiled output:

CMD ["node", "dist/index.js"]

A docker-compose.example.yml is included in the repository for reference. The build step compiles the TypeScript source via tsc and also runs `npm run avatars:export` to extract staff avatar assets into the runtime directory.

For OpenClaw path overrides when your OpenClaw data is not in the default home locations, the .env.example provides OPENCLAW_HOME, OPENCLAW_CONFIG_PATH, OPENCLAW_WORKSPACE_ROOT, and OPENCLAW_AGENT_ROOT variables.

What Each Section of the Dashboard Shows

The dashboard is organized into eight sections. Overview is described as the main operating screen for non-technical users; it shows the current control posture, key action items, runtime issues, stalled runs, and budget information. Usage covers spend, subscription windows, and connector status. A Context pressure card shows which sessions are closer to context limits.

Staff shows who is working now versus only queued, with recent output and schedule state. The token attribution view shows which timed jobs are consuming tokens and how that share splits across them.

Tasks covers current work, approvals, execution chains, and runtime evidence. Collaboration is the hall-first multi-agent work view described in more detail in the next section. Documents and Memory provide source-backed workbenches scoped to active OpenClaw agents. The Memory section includes a Memory status card that shows whether each visible agent's memory is usable and searchable.

Settings includes three cards added in the current release: a Connection health card that identifies what is wired, what is partial, and what needs finishing; a Security risk summary that translates current risk and next-step guidance into plain operator language; and an Update status card showing the current version, latest version, update channel, and install method.

The Hall: Multi-Agent Collaboration with Structured Execution

The hall is a shared discussion thread where multiple OpenClaw agents can discuss a task, be assigned ownership, hand off work, and submit it for review. The workflow runs through three phases: discussion, execution, and review.

A task starts in discussion. Unless a specific agent is addressed with @, the hall aims to collect at least two replies so a second agent can add a perspective rather than repeat the first. The repo-root HALL.md file injects a shared collaboration style into every discussion, execution, and handoff turn; editing it changes the behavior of the whole hall without requiring code changes.

To start execution, use the Arrange execution order feature to specify the first owner, later owners, and what each person hands off. Saving the order does not start execution; the decision card shows a Start execution control when the queue is ready. During execution, each owner completes their own step and explicitly @ the next owner in the same thread. Review happens only after the last queued owner finishes or when a human stops the chain.

The hall reads the current OpenClaw roster directly from the runtime environment and uses the live agent IDs and display names it finds. Existing users do not need to rename agents to control-center-specific defaults. Role suggestions are heuristic: if the roster has names like manager, planner, builder, or qa, the hall uses them; otherwise it falls back without blocking the workflow.

Task rooms linked to the hall act as detail and evidence threads with live streaming, assignment, review, and optional Discord or Telegram mirroring.

What OpenClaw Control Center Does Not Cover

The dashboard is useful only when OpenClaw is already running and reachable at the configured gateway address. If OpenClaw is not running, or if the WebSocket address in GATEWAY_URL is wrong, the dashboard has nothing to display. The README does not document what OpenClaw itself requires to install or run; that is out of scope for this project.

Mutation routes are disabled by default and the README does not describe the process for enabling them. Operators who need write operations beyond what the hall dispatch provides will need to investigate configuration options not visible in the truncated .env.example.

The repository has no published GitHub releases and the version in package.json is 1.0.0. There is no documented upgrade or migration path between versions. The last push was on 2026-04-13. For teams that require stable, versioned releases with changelogs, this project's release posture is a real constraint.

OpenClaw's CLI as the Direct Alternative

The README's framing points directly to the comparison: the control center exists for operators who do not want to work with raw backend payloads. The natural alternative is OpenClaw's own command-line interface, which provides access to the same runtime data in raw form.

Using the CLI directly requires understanding the session data structures, WebSocket message formats, and execution state machine that OpenClaw uses internally. This is appropriate for a developer debugging the runtime but not for a non-technical operator monitoring a running deployment.

The control center's advantage is presentation: it translates agent state, task execution chains, memory status, and token attribution into pages that require no knowledge of the underlying data format. Its limitation is that it is tightly coupled to OpenClaw specifically. It cannot be adapted to monitor a different agent runtime without rebuilding the data model. If your team uses multiple agent runtimes or a different system entirely, a generic observability platform (such as a custom dashboard connected to structured logs) would be more portable, at the cost of losing the OpenClaw-specific semantics the control center provides.

Editorial conclusion

Teams running OpenClaw who need a browser-based view of agent health, execution state, and token usage without handling backend WebSocket payloads directly should try OpenClaw Control Center. The critical prerequisite to verify before setup: OpenClaw must be running and reachable at the address configured in GATEWAY_URL; the dashboard has no function without an active OpenClaw instance behind it. The last push to this repository was on 2026-04-13, and the repository has no published releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. TianyiDataScience/openclaw-control-center on GitHub