OpenClaw Mission Control

OpenClaw Mission Control is the centralized operations and governance platform for running OpenClaw across teams and organizations, with unified visibility, approval controls, and gateway-aware orchestration. It gives operators a single interface for work orchestration, agent and gateway management, approval-driven governance, and API-backed automation.

Platform overview

Mission Control is designed to be the day-to-day operations surface for OpenClaw. Instead of splitting work across multiple tools, teams can plan, execute, review, and audit activity in one system.

Core operational areas:

• Work orchestration: manage organizations, board groups, boards, tasks, and tags.
• Agent operations: create, inspect, and manage agent lifecycle from a unified control surface.
• Governance and approvals: route sensitive actions through explicit approval flows.
• Gateway management: connect and operate gateway integrations for distributed environments.
• Activity visibility: review a timeline of system actions for faster debugging and accountability.
• API-first model: support both web workflows and automation clients from the same platform.

Use cases

• Multi-team agent operations: run multiple boards and board groups across organizations from a single control plane.
• Human-in-the-loop execution: require approvals before sensitive actions and keep decision trails attached to work.
• Distributed runtime control: connect gateways and operate remote execution environments without changing operator workflow.
• Audit and incident review: use activity history to reconstruct what happened, when it happened, and who initiated it.
• API-backed process integration: connect internal workflows and automation clients to the same operational model used in the UI.

What makes Mission Control different

• Operations-first design: built for running agent work reliably, not just creating tasks.
• Governance built in: approvals, auth modes, and clear control boundaries are first-class.
• Gateway-aware orchestration: built to operate both local and connected runtime environments.
• Unified UI and API model: operators and automation act on the same objects and lifecycle.
• Team-scale structure: organizations, board groups, boards, tasks, tags, and users in one system of record.

Who it is for

• Platform teams running OpenClaw in self-hosted or internal environments.
• Operations and engineering teams that need clear approval and auditability controls.
• Organizations that want API-accessible operations without losing a usable web UI.

Get started in minutes

Option A: One-command production-style bootstrap

If you haven't cloned the repo yet, you can run the installer in one line:

curl -fsSL https://raw.githubusercontent.com/abhi1693/openclaw-mission-control/master/install.sh | bash

This clones the repository into ./openclaw-mission-control if no local checkout is found in your current directory.

If you already cloned the repo:

./install.sh

The installer is interactive and will:

• Ask for deployment mode (docker or local).
• Install missing system dependencies when possible.
• Generate and configure environment files.
• Bootstrap and start the selected deployment mode.

Installer support matrix: docs/installer-support.md

Option B: Manual setup

Prerequisites

• Supported platforms: Linux and macOS. On macOS, Docker mode requires Docker Desktop; local mode requires Homebrew and Node.js 22+.
• Docker Engine
• Docker Compose v2 (docker compose)

1. Configure environment

cp .env.example .env

Before startup:

• Set LOCAL_AUTH_TOKEN to a non-placeholder value (minimum 50 characters) when AUTH_MODE=local.
• Ensure BASE_URL matches the public backend origin if you are not using http://localhost:8000.
• NEXT_PUBLIC_API_URL=auto (default) resolves to http(s)://<current-host>:8001.
  • Set an explicit URL when your API is behind a reverse proxy or non-default port.

2. Start Mission Control

docker compose -f compose.yml --env-file .env up -d --build

If you are iterating on the UI in Docker and want automatic frontend rebuilds on source changes, run:

docker compose -f compose.yml --env-file .env up --build --watch

Notes:

• Compose Watch requires Docker Compose 2.22.0+.
• You can also run watch separately after startup:

docker compose -f compose.yml --env-file .env up -d --build
docker compose -f compose.yml --env-file .env watch

After pulling new changes, rebuild and recreate all services:

docker compose -f compose.yml --env-file .env up -d --build --force-recreate

For a fully clean rebuild (no cached build layers):

docker compose -f compose.yml --env-file .env build --no-cache --pull
docker compose -f compose.yml --env-file .env up -d --force-recreate

3. Open the application

• Mission Control UI: http://localhost:3000
• Backend health: http://localhost:8000/healthz

4. Stop the stack

docker compose -f compose.yml --env-file .env down

Authentication

Mission Control supports two authentication modes:

• local: shared bearer token mode (default for self-hosted use)
• clerk: Clerk JWT mode

Local auth mode

Set AUTH_MODE=local (backend) and NEXT_PUBLIC_AUTH_MODE=local (frontend).

Option 1 — Token in environment (recommended for self-hosted)

Set NEXT_PUBLIC_LOCAL_AUTH_TOKEN in the frontend environment. The app loads directly with no login screen. The token is used automatically for every API call.

NEXT_PUBLIC_AUTH_MODE=local
NEXT_PUBLIC_LOCAL_AUTH_TOKEN=your-bearer-token-here

Option 2 — Token entered on load

Leave NEXT_PUBLIC_LOCAL_AUTH_TOKEN unset. On first load, users are presented with a login screen and must paste their bearer token before accessing the app. The token is stored in sessionStorage for the duration of the browser session.

NEXT_PUBLIC_AUTH_MODE=local
# NEXT_PUBLIC_LOCAL_AUTH_TOKEN is not set — login screen will appear

The bearer token must match LOCAL_AUTH_TOKEN set on the backend (minimum 50 characters).

Clerk mode

Set AUTH_MODE=clerk and configure NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY.

Environment templates

• Root: .env.example
• Backend: backend/.env.example
• Frontend: frontend/.env.example

AI provider credentials

When running in AUTH_MODE=local, Mission Control automatically configures AI provider credentials on startup by reading the credential files written by the Claude Code and Codex CLI VS Code extensions.

What gets read and where

Provider	File	Field
Anthropic / Claude	~/.claude/.credentials.json	claudeAiOauth.accessToken
OpenAI / GPT	~/.codex/auth.json	tokens.access_token

These are the same files the extensions update when you log in or out. No manual configuration is required if either extension is installed and authenticated.

How it works

On every boot the backend seeds provider_credentials rows from those files. A background watcher then polls the file modification times every 60 seconds. When a change is detected (login, logout, token refresh) the affected row is updated automatically — you are reconfigured within one polling cycle of any credential change.

Seeding is idempotent: rows are only written when the stored token differs from what is on disk. If a file is absent or the token has expired, that provider is skipped without error.

Override credential file paths

Set environment variables to point to non-default locations:

CLAUDE_CREDENTIALS_PATH=/path/to/.credentials.json
CODEX_CREDENTIALS_PATH=/path/to/auth.json

Supplement with explicit API keys

Session tokens from the local files grant subscription-level access. To also configure standard API keys (for rate-limit or billing endpoints), add these to .env:

ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...
OPENAI_BASE_URL=http://localhost:11434/v1   # Ollama, Azure, or any OpenAI-compatible endpoint

Run the seeder manually

# one-shot seed
python backend/scripts/seed_provider_credentials.py

# continuous watcher (re-seeds every 60 s when files change)
python backend/scripts/seed_provider_credentials.py --watch

# custom poll interval
python backend/scripts/seed_provider_credentials.py --watch --interval 30

Documentation

Complete guides for deployment, production, troubleshooting, and testing are in /docs.

Project status

Mission Control is under active development.

• Features and APIs may change between releases.
• Validate and harden your configuration before production use.

Contributing

Issues and pull requests are welcome.

• Contributing guide
• Open issues

License

This project is licensed under the MIT License. See LICENSE.

Star History