OpenClaw Control Center: Turn Your AI Agent System from a Black Box into a Transparent Operations Dashboard

If you’ve ever stared at your OpenClaw setup wondering what’s actually running, how much it’s costing, or why a task seems stuck — you’re not alone. OpenClaw Control Center exists to answer exactly those questions. It transforms OpenClaw from an opaque execution engine into a local management console you can actually see, trust, and control.

This isn’t a replacement for OpenClaw. Think of it as the instrument panel for a system that was previously flying blind.

What Problem Does This Actually Solve?

The core issue: observability is the first thing that breaks when multi-agent AI systems move from experimentation to production.

Running a multi-agent OpenClaw setup looks effortless on the surface — AI agents working in parallel, tasks being routed automatically, memory being updated. But in practice, you quickly run into a familiar set of frustrating questions:

  • How much did we spend in tokens today, and why did the bill spike?
  • Three agents say they’re “working” — so why is nothing finished?
  • Did the task handoff between agents actually succeed, or did it silently drop?
  • Is the memory file for this agent still being updated correctly?

These questions share a common root: there’s no unified visibility layer. OpenClaw focuses on execution. OpenClaw Control Center adds the observation and management layer on top — so you don’t have to dig through logs or query APIs just to understand what’s happening.

Eight Sections, Eight Specific Questions Answered

Each section of the Control Center is designed to answer one class of question precisely, rather than dumping everything onto a single screen.

Overview: Is the System Healthy Right Now?

The Overview page is the main entry point for non-technical users. At a glance, it shows:

  • Current system status and operational posture
  • Pending action items
  • Runtime errors and stalled executions
  • Budget risk signals
  • Which agents are busy and where attention is needed first

Real-world scenario: Every morning, open the Control Center and check the Overview. Within five seconds, you know whether the system is healthy — without opening a single log file or running a status command.

Usage: Is Spending Starting to Become a Risk?

The Usage section tracks token consumption and cost trends across today, the last 7 days, and the last 30 days. It includes:

  • Subscription window and quota consumption
  • Context pressure indicators (which sessions are approaching context limits)
  • Data connection status
  • Token attribution by task

The context pressure metric deserves special attention. It surfaces which sessions are getting close to their context limits before things slow down or get expensive — giving you a chance to act rather than react after seeing an unexpected bill.

Real-world scenario: Your scheduled task ran overnight. This morning you open the Usage page and immediately see which specific tasks consumed the most tokens and what percentage each accounts for. You spot the outlier in under a minute.

Staff: Who’s Actually Working vs. Just Queued?

This section solves a specific and common misread: “queued” and “actively executing” are completely different states, but without explicit separation, it’s easy to mistake a growing backlog for a busy, productive team.

The Staff page draws a hard line between the two, showing:

  • Each agent’s current execution state
  • Recent output and schedule status
  • Who’s busy, idle, blocked, or waiting

A candid observation: in multi-agent systems, the gap between “looks like it’s working” and “is actually working” is one of the most common sources of operational confusion. This section’s value isn’t in technical sophistication — it’s in getting a simple but critical distinction right.

Collaboration: Where Did That Task Actually Go?

The Collaboration section is a newly added standalone view that shows exactly how agents hand off work to each other:

  • Parent session and child session relay chains
  • Verified cross-session communication like Main ⇄ Pandas via sessions_send / inter-session message
  • Who picked up the task first, who delegated to whom, and which session the reply came back from

Real-world scenario: A task was dispatched two hours ago with no response. Instead of guessing or scanning through logs, you open the Collaboration page and trace the handoff chain directly. You can see exactly where the task stalled — whether it was never successfully routed, or whether it’s sitting with a specific agent that’s overloaded.

Tasks: What’s Being Done vs. What’s Just Planned?

The Tasks section consolidates the task board, scheduling, approvals, execution chains, and run evidence in a single view. It helps you distinguish:

  • Tasks that exist only as Kanban mappings (planned, not running)
  • Tasks that have real execution evidence
  • Tasks that are blocked and need follow-up or approval

The core question this section answers: “What’s actually happening right now, what’s just planned, and what needs me to step in?”

Memory: Are Agent Memories Functioning Correctly?

The Memory section is a direct file-based workbench for viewing and editing daily and long-term memory files. Key features:

  • Scope follows the active agents defined in openclaw.json — deleted agents don’t linger in the view
  • Explicit status indicators showing whether each agent’s memory is available, searchable, and in good shape

Real-world scenario: An agent’s behavior has been drifting over the past few days. You open the Memory page and check its long-term memory file directly — confirming whether there’s stale data, missing updates, or memory corruption, without touching any code.

Documents: Edit the Files That Are Actually in Effect

The Documents section opens actual source files. When you save, changes write back to the same source file. This isn’t a preview layer — it’s a direct workbench for the operational documents your system is actually running on.

Settings: Connection Status and Security Risk Summary

The Settings page received three significant additions in this release:

  • Connection Status: tells you exactly which data sources are connected, which are partially wired, and what you need to do to complete the connection
  • Security Risk Summary: translates current risks, their impact, and recommended next steps into plain language
  • Update Status: shows your current version, latest available version, update channel, and installation method

Security Design: Read-Only by Default, High-Risk Actions Disabled

The Control Center ships with security-first defaults — you don’t have to configure safety options yourself. They’re already on.

Here’s the full default configuration:

Setting Default What It Means
READONLY_MODE true System-wide read-only mode
LOCAL_TOKEN_AUTH_REQUIRED true Local token authentication required
IMPORT_MUTATION_ENABLED false Write operations via import disabled
IMPORT_MUTATION_DRY_RUN false Dry-run for imports also off by default
APPROVAL_ACTIONS_ENABLED false Hard switch for approval actions — off
APPROVAL_ACTIONS_DRY_RUN true Approval actions default to dry-run

When authentication is enabled, import/export and all state-changing endpoints require a local token. Approval actions have their own hard switch — disabled by default, and when enabled, they default to dry-run mode.

One additional constraint worth noting: the Control Center does not modify ~/.openclaw/openclaw.json. All operations are scoped to the control-center/ directory.

This design philosophy matters. Many tools leave security configuration to users — and users either don’t know the options exist or skip them for convenience. Making security the default, rather than an opt-in, is the more responsible engineering choice.

Get Running in 5 Minutes

The fastest path to a working installation is straightforward. The entire sequence takes under five minutes, excluding dependency download time.

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

Once running, open either of these URLs:

  • Chinese interface: http://127.0.0.1:4310/?section=overview&lang=zh
  • English interface: http://127.0.0.1:4310/?section=overview&lang=en

Important: Always use npm run dev:ui to start the UI — not UI_MODE=true npm run dev. The former is significantly more stable, especially on Windows shells. Note that npm run dev only runs the monitor once and does not start the HTTP UI server.

Prerequisites

Before installing, confirm you have the following:

  • A working OpenClaw installation
  • A reachable OpenClaw Gateway
  • node and npm on the current machine
  • Read access to the OpenClaw home directory

For fuller Usage and subscription data, you’ll also want read access to:

  • ~/.openclaw
  • ~/.codex
  • The OpenClaw subscription snapshot file (especially if it’s not in the default location)

Installation

git clone https://github.com/TianyiDataScience/openclaw-control-center.git
cd openclaw-control-center
npm install
cp .env.example .env

If OpenClaw reports “missing src/runtime” or “missing core source files,” don’t touch the code. This type of error almost always means one of the following:

  • You’re not in the openclaw-control-center repository root
  • You cloned the wrong repository
  • The checkout or download was incomplete
  • An agent is executing in the wrong workspace

A correct repository structure includes: package.json, src/runtime, src/ui, and .env.example.

The Recommended Approach: Let OpenClaw Wire Itself Up

Rather than manually configuring each setting, the recommended first-time setup is to hand the installation prompt directly to your own OpenClaw instance.

The project ships with INSTALL_PROMPT.md (Chinese) and INSTALL_PROMPT.en.md (English) — both can be copied directly into an OpenClaw session to handle the full installation.

The prompt is structured into five phases and is designed to handle a wide range of real-world complications:

  • No GPT or Codex subscription, or no readable subscription snapshot
  • Underlying provider is an API key or alternative (OpenAI API, Anthropic, OpenRouter, etc.)
  • Non-default paths for ~/.openclaw, ~/.codex, Gateway address, or port
  • Multiple OpenClaw home directories or multiple possible Gateways on one machine
  • Machine can only build locally — can’t reach a live Gateway yet
  • Some data sources are missing, but the Control Center should still start in safe read-only mode

Five-phase execution summary:

Phase Goal
Phase 1: Confirm Environment Check Gateway reachability, confirm paths, identify missing prerequisites
Phase 2: Install the Project Verify repository integrity, install dependencies, create or correct .env
Phase 3: Configure Safe First Connection Preserve security defaults, only modify parameters that genuinely differ
Phase 4: Validate the Installation Run build / test / smoke; stop and report clearly on any failure
Phase 5: Deliver a Startable Result Output what changed, the exact start command, which pages to check first

The advantage here is significant: OpenClaw already knows your local environment. Letting it handle environment detection and configuration is more accurate than manual setup, and far less likely to miss edge cases.

Environment Configuration Reference

In most cases, you’ll need to change only a handful of environment variables. Everything else should stay at its default.

# If your Gateway isn't at the default address
GATEWAY_URL=<your Gateway URL>

# If your OpenClaw home directory is non-standard
OPENCLAW_HOME=<path to your OpenClaw home>

# If your Codex home is non-standard (leave empty if you don't have Codex)
CODEX_HOME=<path to your Codex home>

# If the subscription snapshot file isn't in the default location
OPENCLAW_SUBSCRIPTION_SNAPSHOT_PATH=<path to snapshot file>

# If the default port is occupied
UI_PORT=<your preferred port>

Critical note on CODEX_HOME: If the directory doesn’t exist, or if this machine has no Codex or GPT subscription data, leave this empty. Do not fill in a placeholder path. The Usage and Subscription panels will partially degrade — that’s expected behavior, not a failure. All other sections remain fully functional.

Who Is This Built For?

OpenClaw Control Center is well-suited to three specific types of users:

Teams or individuals already using OpenClaw who want a unified control point. No more switching between tools or manually tailing logs. One interface for the full operational picture.

People running OpenClaw locally or in a reachable local environment. The Control Center defaults to connecting a local Gateway, and local operation is the most stable configuration.

Anyone who wants to publish a security-first OpenClaw console rather than a general-purpose agent platform. The project has a clear scope: it is not a replacement for OpenClaw, not a universal agent platform, and not a hosted SaaS console. That specificity is a feature, not a limitation.

What’s New in This Release

Several additions in this version address problems that previously required guesswork or log-diving:

Standalone Collaboration section: Previously, you could only infer agent-to-agent relationships by reading execution chains. Now you can see parent/child session relays and verified cross-session communication (like Main ⇄ Pandas) directly, without reverse-engineering the handoff from logs.

Connection Status in Settings: Tells you exactly which data sources are connected, which are partially wired, and where to go to complete the connection. No more guessing why a panel shows no data.

Security Risk Summary in Settings: Translates current risks, their impact, and recommended next steps into plain language — not a list of configuration parameters, but actionable guidance.

Update Status in Settings: Current version, latest version, update channel, and installation method in one card.

Context Pressure in Usage: Surfaces which sessions are approaching their context limits before slowdowns or cost spikes occur.

Memory Status in Memory: Shows whether each agent’s memory is available, searchable, and in good condition — at a glance.

Release Hygiene and Open Source

The repository includes .gitignore, LICENSE, and publishable package metadata. GATEWAY_URL is configurable and no longer bound to a single local socket. Public-facing documentation uses the canonical ~/.openclaw/... path format — no machine-private home directories in the docs.

Before any public push, it’s recommended to run:

npm run release:audit

The standalone repository publishing workflow is documented in docs/PUBLISHING.md. Ready-to-use showcase copy for X and Discord is in docs/SHOWCASE.md.

Quick Reference Checklist

Before first launch:

  • [ ] Confirm you have a working OpenClaw installation and a reachable Gateway
  • [ ] Confirm node and npm are available on the machine
  • [ ] Clone the repository and verify the root contains package.json, src/runtime, src/ui

Installation:

  • [ ] npm install
  • [ ] cp .env.example .env
  • [ ] Modify only the environment variables that genuinely differ from defaults
  • [ ] Leave all security defaults unchanged
  • [ ] npm run build
  • [ ] npm test
  • [ ] npm run smoke:ui
  • [ ] npm run dev:ui

On first open, prioritize:

  • [ ] Overview — is the system healthy?
  • [ ] Usage — what’s the token spend and context pressure?
  • [ ] Settings — what’s connected and what’s the current security posture?

One-Page Summary

Question Where to Look
Is the system healthy overall? Overview
How much have we spent today? Usage
Which agents are actually running? Staff
Did the task handoff succeed? Collaboration
Which tasks are blocked? Tasks
Is agent memory functioning correctly? Memory
What do the active operational documents say? Documents
Why is a data source missing? Settings

Frequently Asked Questions

Can OpenClaw Control Center replace OpenClaw itself?
No. The Control Center is a management console focused on observation and control. OpenClaw handles execution. They’re complementary, not interchangeable.

Can I use it without a Codex or GPT subscription?
Yes. The Usage and Subscription panels will partially degrade, but all other sections work normally. Leave CODEX_HOME empty — don’t fill in a placeholder path.

What’s the default port, and how do I change it?
The default port is 4310. To change it, set UI_PORT in your .env file.

Does it work on Windows?
Yes. Use npm run dev:ui rather than UI_MODE=true npm run dev — the former is considerably more stable on Windows shells.

Can approval actions be enabled?
Yes, but they’re disabled by default (APPROVAL_ACTIONS_ENABLED=false). Before enabling, make sure you understand the implications. Running in dry-run mode first is strongly recommended.

Will the Control Center modify any OpenClaw configuration files?
No. All operations are scoped to the control-center/ directory. The Control Center does not write to ~/.openclaw/openclaw.json.

What if the Gateway is unreachable — can I still use it?
Yes. The Control Center will run in a degraded state: “local UI available, live observation not yet connected.” This is not treated as an installation failure.

How do I confirm the installation succeeded?
Run npm run build, npm test, and npm run smoke:ui in sequence. If all three pass, the installation is successful. If any step fails, the output will tell you exactly what went wrong and what to do next.