# Mission Control
Self-hosted control plane for operating AI agents.
Dispatch tasks, inspect runs, review failures, track spend, and coordinate agent runtimes
from one local dashboard backed by SQLite.
An open-source project by [Builderz Labs](https://builderz.dev), created and maintained by [nyk](https://nyk.dev).
It works with OpenClaw, Claude Code, Codex, and other runtimes - it is not part of any one of them.
[](https://github.com/builderz-labs/mission-control/actions/workflows/quality-gate.yml)
[](https://github.com/builderz-labs/mission-control/releases)
[](LICENSE)
[](https://github.com/sponsors/builderz-labs)
> [!WARNING]
> Mission Control is alpha software. APIs, schemas, and configuration may change between
> releases. Read the [security guidance](#security-boundary) before exposing it to a network.
## Start locally
Node.js 22 or newer and pnpm are required for a source install.
```bash
git clone https://github.com/builderz-labs/mission-control.git
cd mission-control
bash install.sh --local
```
Open `http://localhost:3000/setup`, create the first admin account, then copy the API key
from Settings if an agent or script needs headless access.
The manual path is useful when you already manage Node and pnpm:
```bash
nvm use 22
pnpm install
pnpm dev
```
Windows users can run `./install.ps1 -Mode local` in PowerShell.
### Start with Docker
```bash
docker compose up
```
Or run the published multi-architecture image:
```bash
docker pull ghcr.io/builderz-labs/mission-control:latest
docker run --rm -p 3000:3000 ghcr.io/builderz-labs/mission-control:latest
```
Use the hardened Compose overlay for a network-accessible deployment:
```bash
docker compose -f docker-compose.yml -f docker-compose.hardened.yml up -d
```
The [deployment guide](docs/deployment.md) covers persistent data, TLS termination,
gateway connectivity, and standalone builds.
## What Mission Control governs
The control plane sits above agent runtimes. It does not replace their reasoning or tool
loops. It gives operators one place to see and govern the work around those loops.
| Area | Shipped surface |
|---|---|
| Tasks | Inbox, assignment, execution, review, Aegis quality gate, and completion receipts |
| Agents | Registration, presence, sessions, runtime adapters, configuration, and workspace sync |
| Operations | Activity stream, schedules, alerts, webhooks, logs, token use, and cost views |
| Knowledge | Memory browser, relationship graph, skills registry, and local skill synchronization |
| Governance | Roles, API keys, security events, trust signals, approvals, audits, and evals |
| Interfaces | Web UI, CLI, MCP server, OpenAPI-described REST API, WebSocket, and SSE |
The runtime is self-hosted and workspace-aware. SQLite stores local control-plane state.
Shared workspaces can use deployment-level runtime integrations. Strict workspaces block
those integrations until the underlying resources carry workspace ownership. A gateway is
optional for task, project, agent, scheduler, webhook, alert, and cost work; live session
messaging needs a connected runtime gateway.
## Operator field notes
Dashboards compress a sequence into current state. When a run needs review, record the
identity, task, tool call, approval, result, and verification evidence before changing it.
Keep unresolved items distinct from accepted risk.
Logs show what ran. A completion receipt or inspected artifact shows what finished.
## Pick the right fit
Use Mission Control when multiple agents or runtimes make it hard to answer who owns a
task, what executed, which result passed review, or where spend and failures accumulated.
It is probably the wrong tool when:
- one agent on one machine already stays understandable from its native CLI;
- you need a managed multi-tenant SaaS rather than a self-hosted control plane;
- you want an agent framework to define planning and tool use;
- your deployment cannot tolerate alpha schema or API changes.
Adapters and observation surfaces cover OpenClaw, Claude Code, Codex,
CrewAI, LangGraph, AutoGen, and Claude SDK workflows. Adapter depth varies by runtime; see
[agent setup](docs/agent-setup.md) and [CLI integration](docs/cli-integration.md) before
assuming feature parity.
## Connect an agent
The shortest gateway-free loop uses the REST API. Export the URL and API key shown in
Settings:
```bash
export MC_URL=http://localhost:3000
export MC_API_KEY=replace-with-your-api-key
```
Register an agent and create work:
```bash
curl -s -X POST "$MC_URL/api/agents/register" \
-H "Authorization: Bearer $MC_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name":"scout","role":"researcher"}'
curl -s -X POST "$MC_URL/api/tasks" \
-H "Authorization: Bearer $MC_API_KEY" \
-H "Content-Type: application/json" \
-d '{"title":"Review open incidents","assigned_to":"scout","priority":"medium"}'
```
The agent can then claim its queue:
```bash
curl -s "$MC_URL/api/tasks/queue?agent=scout" \
-H "Authorization: Bearer $MC_API_KEY"
```
Continue with the [first-agent quickstart](docs/quickstart.md) for heartbeats, task results,
queue behavior, CLI equivalents, and MCP setup.
### CLI
```bash
pnpm mc agents list --json
pnpm mc tasks queue --agent scout --json
pnpm mc events watch --types agent,task
```
### MCP server
```bash
claude mcp add mission-control -- \
env MC_URL=http://127.0.0.1:3000 MC_API_KEY=replace-with-your-api-key \
node /absolute/path/to/mission-control/scripts/mc-mcp-server.cjs
```
Use the [CLI and MCP reference](docs/cli-agent-control.md) for the current command and tool
surface. The REST contract lives in [`openapi.json`](openapi.json). A running instance serves
the interactive reference at `/docs` and the OpenAPI JSON at `/api/docs`.
## Product surfaces
### Tasks and quality review
The task board tracks work through inbox, assignment, execution, review, quality review,
and completion. Aegis review requires an approval record before a task reaches done.
### Agents and runtimes
Agent views combine registration state, heartbeats, sessions, configuration, local runtime
discovery, and workspace files.
### Memory and skills
The memory browser and relationship graph inspect filesystem-backed memory and linked
session knowledge. The Skills Hub discovers local skill roots and scans registry content
before installation.
### Schedules and activity
Recurring task templates create dated work on a cron schedule. The activity stream combines
agent, task, and system events for operator review.
## Documentation
| Guide | Use it for |
|---|---|
| [Quickstart](docs/quickstart.md) | Register an agent and run the first task loop |
| [Agent setup](docs/agent-setup.md) | Sources, identities, SOUL files, and heartbeats |
| [Orchestration](docs/orchestration.md) | Dispatch, handoffs, workflows, and review gates |
| [CLI and MCP](docs/cli-agent-control.md) | Headless commands and agent tools |
| [CLI integration](docs/cli-integration.md) | Claude Code, Codex, and gateway-free connections |
| [Deployment](docs/deployment.md) | Local, Docker, standalone, reverse proxy, and VPS setup |
| [Security hardening](docs/SECURITY-HARDENING.md) | Network, container, CSP, and secret controls |
| [Support](SUPPORT.md) | Questions, bugs, feature proposals, and security-report routing |
| [OpenClaw compatibility](docs/openclaw-config-compatibility.md) | Config and state-directory behavior |
| [Release process](RELEASE.md) | Versioning, tags, images, and release checks |
## Architecture
```text
Web UI ─┐
CLI ────┼── auth ─ dispatch ─ events ─ policy ─ receipts
MCP ────┤ │
REST ───┘ SQLite + agent runtimes
```
| Layer | Technology |
|---|---|
| Application | Next.js 16 App Router, React 19, TypeScript 5 |
| Interface | Tailwind CSS 4, Zustand, Recharts, xterm.js |
| State | SQLite through better-sqlite3, with WAL mode |
| Boundaries | REST/OpenAPI, MCP, CLI, WebSocket, and SSE |
| Access | Session cookies, API keys, Google sign-in, and role checks |
| Validation | Zod at input boundaries |
| Verification | Vitest, Playwright, ESLint, TypeScript, build, and API parity checks |
Runtime data defaults to `.data/`. Set `MISSION_CONTROL_DATA_DIR` to an absolute persistent
path for standalone deployments. The complete environment contract is in
[`.env.example`](.env.example).
## Security boundary
- Keep Mission Control on a trusted network unless a TLS reverse proxy and
`MC_ALLOWED_HOSTS` are configured.
- Replace or securely store generated credentials before broader access.
- Use the hardened Compose overlay for production-like container deployments.
- Treat agent messages, skill packages, webhooks, and MCP content as untrusted input.
- Report vulnerabilities through [SECURITY.md](SECURITY.md), not a public issue.
Access controls and security inspection surfaces are included, but alpha status
still applies. Read [SECURITY-HARDENING.md](docs/SECURITY-HARDENING.md) before relying on a
network-accessible deployment.
## Develop
```bash
pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm test
pnpm build
pnpm test:e2e
```
`pnpm quality:gate` runs the full repository gate. Useful diagnostics:
```bash
bash scripts/station-doctor.sh
bash scripts/security-audit.sh
pnpm api:parity
```
Common local failures:
| Symptom | Check |
|---|---|
| Login returns an internal error after changing Node versions | Run `pnpm rebuild better-sqlite3` |
| Docker cannot reach the gateway | Set `OPENCLAW_GATEWAY_HOST=host.docker.internal` |
| Browser WebSocket cannot connect | Leave `NEXT_PUBLIC_GATEWAY_HOST` empty or set a browser-reachable host |
| Password text after `#` disappears | Quote `AUTH_PASS` or use `AUTH_PASS_B64` |
See [CONTRIBUTING.md](CONTRIBUTING.md) for contribution scope, coding standards, and review
expectations. Community conduct is defined in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
## Project status and support
Release notes live in [CHANGELOG.md](CHANGELOG.md). Open issues are the current roadmap;
the project does not promise dates for unassigned work.
- Bugs and feature proposals: [GitHub Issues](https://github.com/builderz-labs/mission-control/issues)
- Vulnerabilities: [private reporting instructions](SECURITY.md)
- Builderz Labs: [builderz.dev](https://builderz.dev)
- Maintained by [Nyk](https://nyk.dev). Sponsor [Nyk](https://github.com/sponsors/0xNyk) or [Builderz Labs](https://github.com/sponsors/builderz-labs). Follow [@nykdotdev](https://x.com/nykdotdev).
```
**Inline styles** (ReactFlow, recharts):
```ts
import { hsl, voidAccents } from '@/styles/design-tokens'
const stroke = hsl(voidAccents.cyan) // "hsl(187 82% 53%)"
const dim = hsl(voidAccents.cyan, 0.4) // "hsl(187 82% 53% / 0.4)"
```
---
## 3. Typography
| Role | Font | CSS Variable | Tailwind Class |
|------|------|-------------|----------------|
| Body/UI | Inter | `--font-sans` | `font-sans` |
| Code/Data | JetBrains Mono | `--font-mono` | `font-mono` |
Both fonts are loaded via `next/font/google` (self-hosted, no external requests).
### Type Scale
Follow Tailwind's default scale. Key usage:
- `text-2xl font-bold font-mono` — stat card values
- `text-sm font-medium` — labels, nav items
- `text-xs font-mono` — metadata, timestamps, model names
- `text-[10px] tracking-wider font-semibold` — section headers (OBSERVE, AUTOMATE, etc.)
---
## 4. Spacing
Base grid: **4px**
Use Tailwind's spacing scale (1 = 0.25rem = 4px). Panel padding is typically `p-4` (16px) or `p-6` (24px). Gaps between grid items use `gap-6` (24px).
---
## 5. Border Radius
| Token | Value | Usage |
|-------|-------|-------|
| `rounded-xl` | 16px | Large panels, modals |
| `rounded-lg` | 12px | Standard panels, cards |
| `rounded-md` | 10px | Buttons, inputs |
| `rounded-sm` | 8px | Small elements |
| `rounded-xs` | 6px | Badges, tags |
---
## 6. Elevation & Glow
### Glow Utilities
| Class | Color | Usage |
|-------|-------|-------|
| `.glow-cyan` | Cyan | Active states, primary focus |
| `.glow-mint` | Mint | Success states |
| `.glow-amber` | Amber | Warning states |
| `.glow-violet` | Violet | Special/lead roles |
### Badge Glow
| Class | Usage |
|-------|-------|
| `.badge-glow-success` | Success status badges |
| `.badge-glow-warning` | Warning status badges |
| `.badge-glow-error` | Error status badges |
### Panel Classes
| Class | Description |
|-------|-------------|
| `.void-panel` | Glass card with luminous border, inner highlight, float shadow |
| `.void-border-glow` | Animated gradient border via `::before` pseudo-element |
| `.panel` | Basic card: `bg-card border rounded-xl` |
| `.btn-neon` | Button with cyan glow on hover |
---
## 7. Component Patterns
### Panel Anatomy
```html
Title
```
### Stat Card
- Use `void-panel` base
- Numeric values: `font-mono text-2xl font-bold`
- Icons: SVG, 24x24 (w-6 h-6), colored with void accent classes
- Color-specific glow via `badge-glow-*` classes
### Agent Node (ReactFlow)
- Base: `void-panel` with status-based border color
- Active: `border-void-cyan glow-cyan`
- Idle: `border-void-amber/50`
- Error: `border-void-crimson badge-glow-error`
- Badges: `font-mono text-xs` with accent background/border
### CORE Node
- Central orchestration hub in agent network
- Concentric pulsing rings (CSS keyframes, no framer-motion)
- `font-mono tracking-widest` for "CORE" label
---
## 8. Animation
### Keyframe Inventory
| Name | Duration | Effect | Usage |
|------|----------|--------|-------|
| `glowPulse` | 3s | Opacity + brightness oscillation | Active agent indicators |
| `float` | 6s | Vertical float (-6px) | Floating UI elements |
| `gridFlow` | 20s | Background position shift | Background grid animation |
| `edgeGlow` | 2s | Opacity oscillation | Border glow effects |
| `pulse-live` | 2s | Opacity fade | Live status indicators |
| `pulse-dot` | 2s | Scale + opacity | Connection status dots |
### Guidelines
- Prefer CSS `@keyframes` over JavaScript animation
- Duration: 2-3s for ambient loops, 150-200ms for interactions
- Easing: `ease-in-out` for loops, `ease-out` for entrances
- Always respect `prefers-reduced-motion: reduce`
---
## 9. Icon System
- **ViewBox**: `0 0 16 16`
- **Style**: Stroke-based, not filled
- **Stroke width**: `1.5`
- **Line caps/joins**: `round`
- **Size in UI**: `w-5 h-5` (nav), `w-4 h-4` (inline), `w-6 h-6` (stat cards)
- **Color**: Inherits via `stroke="currentColor"`
Example:
```tsx
```
---
## 10. Accessibility
### Contrast
- Text on void background: minimum 4.5:1 ratio (WCAG AA)
- `--foreground` (92% lightness) on `--background` (4% lightness) exceeds 15:1
- Cyan accent on dark: 5.2:1 — passes AA for normal text
### Focus Indicators
- Use `ring` utility: `focus-visible:ring-2 focus-visible:ring-ring`
- Ring color matches `--void-cyan`
### Reduced Motion
Global rule in `globals.css`:
```css
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
}
}
```
### Semantic HTML
- Nav uses `role="navigation"` and `aria-label`
- Active nav items use `aria-current="page"`
- Disabled items use `aria-disabled`
- Decorative elements use `aria-hidden="true"`
---
### Plans 2026 03 10 Onboarding Walkthrough Hardening (`docs/plans/2026-03-10-onboarding-walkthrough-hardening.md`)
# Onboarding + Walkthrough hardening plan
Base branch: `fix/refactor`
Working branch: `fix/refactor-onboarding-walkthrough`
## Goals
- Verify current onboarding and walkthrough flows are functional.
- Fix edge cases for first-run, skip, replay, and recovery states.
- Improve UX discoverability of walkthrough entry points.
- Add regression tests to keep flows stable.
## Phase 1: audit and test map
1. Identify current onboarding/walkthrough code paths.
2. Document triggers, persistence flags, and routing.
3. Add failing tests for first-run, skip, replay, and already-seen states.
## Phase 2: implementation hardening
1. Fix state transitions and persistence updates.
2. Ensure walkthrough can be reopened from primary UI.
3. Add visible hint/help entry to improve discoverability.
4. Handle corrupted or partial onboarding state safely.
## Phase 3: verification
1. Run targeted tests for onboarding/walkthrough.
2. Run full project checks.
3. Validate end-to-end flow manually in local dev.
## Deliverables
- Code changes in onboarding/walkthrough modules
- Automated tests covering key onboarding paths
- Updated docs/help text for walkthrough discoverability
---
### Plans 2026 03 20 Mission Control Platform Cli Tui Prd (`docs/plans/2026-03-20-mission-control-platform-cli-tui-prd.md`)
# Mission Control Platform Hardening + Full Agent CLI/TUI PRD
> For Hermes: execute this plan in iterative vertical slices (contract parity -> CLI core -> TUI -> hardening), with tests at each slice.
Goal
Build a production-grade Mission Control operator surface for autonomous agents via a first-party CLI (and optional lightweight TUI), while fixing platform inconsistencies discovered in audit: API contract drift, uneven reliability controls, and incomplete automation ergonomics.
Architecture
Mission Control remains the source of truth with REST + SSE endpoints. A first-party CLI consumes those APIs with profile-based auth and machine-friendly output. TUI is layered on top of CLI API client primitives for shared behavior. API contract reliability is enforced through route-to-spec parity checks in CI.
Tech Stack
- Existing: Next.js app-router API, SQLite, Node runtime, SSE
- New: Node CLI runtime (no heavy deps required for v1), optional TUI in terminal ANSI mode
- Testing: existing Playwright/Vitest patterns + CLI smoke tests + OpenAPI parity checks
---
## 1) Problem statement
Current Mission Control backend has strong capabilities for agent orchestration, but external automation quality is constrained by:
1. API surface drift between route handlers, openapi.json, and /api/index.
2. No first-party comprehensive CLI for operators/agents.
3. Uneven hardening around operational concerns (auth posture defaults, multi-instance rate limiting strategy, spawn history durability).
4. Incomplete UX for non-interactive agent workflows (idempotent commands, stable JSON output, strict exit codes).
Result: agents can use Mission Control partially, but not yet with high confidence as a full control plane.
## 2) Product objectives
Primary objectives
1. Deliver a first-party CLI with functional parity across core agent workflows.
2. Add optional TUI for rapid situational awareness and interactive operations.
3. Establish API contract parity as an enforceable quality gate.
4. Improve reliability and security defaults for autonomous operation.
Success criteria
- 95%+ of documented operator workflows executable via CLI without web UI.
- Contract parity CI gate blocks drift between route handlers and OpenAPI.
- CLI supports machine mode: stable JSON schemas and deterministic exit codes.
- TUI can monitor and trigger core actions (agents/tasks/sessions/events).
Non-goals (v1)
- Replacing the web UI.
- Building an advanced ncurses framework dependency stack if not needed.
- Supporting all historical/legacy endpoint aliases immediately.
## 3) Personas and workflows
Personas
1. Autonomous agent runtime (headless, non-interactive).
2. Human operator (terminal-first incident response).
3. Platform maintainer (release and contract governance).
Critical workflows
- Poll task queue and claim work.
- Manage agents (register/update/diagnose/wake).
- Manage sessions (list/control/continue/transcript).
- Observe events in real time.
- Track token usage and attribution.
- Manage skills, cron jobs, and direct CLI connections.
## 4) Functional requirements
### A. API contract governance
- FR-A1: A parity checker must compare discovered route handlers and OpenAPI paths/methods.
- FR-A2: CI fails on non-ignored mismatches.
- FR-A3: Ignore list must be explicit and reviewable.
- FR-A4: /api/index should be validated or generated from same contract source.
### B. CLI v1 requirements
- FR-B1: Profile-based configuration (URL + auth mode + key/cookie).
- FR-B2: Commands must support --json output and strict exit codes.
- FR-B3: Support key domains:
- auth
- agents
- tasks
- sessions
- connect
- tokens
- skills
- cron
- events watch
- raw request fallback
- FR-B4: Non-interactive defaults suitable for autonomous agents.
- FR-B5: Request timeout + retry controls for reliable automation.
### C. TUI v1 requirements (optional but included)
- FR-C1: Dashboard with agents/tasks/sessions summary panels.
- FR-C2: Keyboard-driven refresh/navigation.
- FR-C3: Trigger key operations (wake agent, queue poll, session controls).
- FR-C4: Clear degraded mode messaging if endpoints unavailable.
### D. Platform hardening requirements
- FR-D1: Document and enforce least-privilege auth guidance for agent keys.
- FR-D2: Expose explicit warning/controls for global admin API key usage.
- FR-D3: Add durable spawn history persistence (DB-backed) replacing log scraping fallback.
- FR-D4: Add scalable rate-limit strategy plan (in-memory now, pluggable backend next).
## 5) CLI command map (v1)
mc auth
- login --username --password
- logout
- whoami
mc agents
- list
- get --id
- create --name --role
- update --id ...fields
- delete --id
- wake --id
- diagnostics --id
- heartbeat --id
- memory get|set --id
- soul get|set --id
mc tasks
- list [filters]
- get --id
- create --title [--description --priority --assigned-to]
- update --id ...fields
- delete --id
- queue --agent [--max-capacity]
- comments list/add --id
- broadcast --id
mc sessions
- list
- control --id --action monitor|pause|terminate
- continue --kind claude-code|codex-cli --id --prompt
- transcript --id [--source]
mc connect
- register --tool-name --agent-name [...]
- list
- disconnect --connection-id
mc tokens
- list
- stats
- by-agent [--days]
- export --format json|csv
mc skills
- list
- content --source --name
- upsert --source --name --file
- delete --source --name
- check --source --name
mc cron
- list
- create/update/pause/resume/remove/run
mc events
- watch [--types]
mc raw
- raw --method GET --path /api/... [--body '{}']
## 6) UX and interface requirements
- Default output must be concise human-readable; --json returns machine-stable payload.
- All non-2xx responses include normalized error object and non-zero exit.
- Exit code taxonomy:
- 0 success
- 2 usage error
- 3 auth error
- 4 permission error
- 5 network/timeout
- 6 server error
- Pagination/filter flags normalized across list commands.
## 7) Security requirements
- Do not log raw API keys or cookies.
- Redact sensitive headers in verbose/debug output.
- Provide per-profile auth scope awareness (viewer/operator/admin implied risk labeling).
- Strong guidance: prefer agent-scoped keys over global admin key.
## 8) Reliability requirements
- Configurable timeout/retry/backoff.
- Safe JSON parsing and clear error surfaces.
- SSE reconnection strategy for watch mode.
- Graceful handling for partial endpoint availability.
## 9) Testing strategy
Unit
- CLI arg parsing and request mapping.
- Output modes and exit codes.
- API parity checker route extraction and mismatch detection.
Integration
- CLI against local Mission Control test server.
- Auth modes (API key, login session where enabled).
- Session control, queue polling, skills CRUD.
E2E
- Playwright/terminal-driven smoke for critical command paths.
- TUI render and keyboard navigation smoke tests.
Contract tests
- OpenAPI parity check in CI.
- Optional index parity check in CI.
## 10) Rollout plan
Phase 0: Contract stabilization
- Add parity checker and fail CI on drift.
- Resolve existing mismatches.
Phase 1: CLI core
- Ship profile/auth client + core command groups (auth/agents/tasks/sessions/connect).
Phase 2: CLI expansion
- tokens/skills/cron/events/raw + transcript ergonomics.
Phase 3: TUI
- Live dashboard + action shortcuts.
Phase 4: Hardening
- durable spawn history
- auth warnings and safeguards
- scalable rate-limit backend abstraction
## 11) Risks and mitigations
Risk: Large API surface causes long-tail parity gaps.
Mitigation: enforce parity checker + allowlist for temporary exceptions.
Risk: Auth complexity across cookie/key/proxy modes.
Mitigation: profile abstraction + explicit mode selection and diagnostics.
Risk: CLI churn if endpoint contracts continue changing.
Mitigation: typed response normalizers + compatibility layer + semver release notes.
## 12) Acceptance criteria
- PRD approved by maintainers.
- CLI provides end-to-end control for core workflows.
- Contract parity CI gate active and green.
- TUI displays operational state and triggers key actions.
- Security and reliability hardening changes documented and tested.
## 13) Immediate implementation tasks (next 1-2 PRs)
PR 1
1. Add API parity checker script and CI command.
2. Add first-party CLI scaffold with command routing and normalized request layer.
3. Add docs for CLI profiles/auth/output contract.
PR 2
1. Implement full command matrix.
2. Add TUI dashboard shell.
3. Add CLI integration tests.
4. Introduce durable spawn history model and endpoint alignment.
---
### Releases 2.0.0 (`docs/releases/2.0.0.md`)
# Mission Control 2.0.0
Released: 2026-03-11
Mission Control 2.0.0 is the major release that lands the `feat/refactor` branch as the new baseline for the project. It rolls up 189 commits on top of `main` and shifts Mission Control from an early dashboard into a broader agent operations console for both local and gateway-driven setups.
## Highlights
### Dual-mode operation
- Mission Control now supports both OpenClaw gateway mode and local workstation mode cleanly.
- Onboarding, runtime detection, security checks, and panel behavior were reworked so the app can adapt to the active environment instead of assuming one deployment shape.
### Broader agent observability
- Hermes observability was added across sessions, memory, tasks, cron, and transcripts.
- OpenClaw coverage was expanded across channels, chat, sessions, cron, devices, approvals, logs, usage, and config editing.
- Agent communication, session routing, and inline transcript visibility were strengthened throughout the app.
### Memory system redesign
- The memory panel was redesigned into an Obsidian-style knowledge surface.
- Mission Control now ships with a filesystem memory browser, link/context endpoints, memory health signals, and an interactive graph view for linked knowledge.
- Loading and navigation performance in the memory panel were improved substantially, including lazy tree loading and graph prefetching.
### Onboarding, security, and doctor workflows
- The onboarding experience was rebuilt into a guided walkthrough with stronger separation between per-user progress and per-session display behavior.
- The security scan now has clearer severity handling, improved autofix behavior, and better reporting of manual vs auto-fixable issues.
- OpenClaw doctor warnings, doctor fix, and state-integrity handling are now surfaced directly in the UI.
### Deployment and runtime hardening
- Node support was standardized on `22.x` across local development, CI, Docker, and standalone deploys.
- Build-time SQLite handling was isolated from runtime SQLite state to avoid noisy or fragile deploy behavior.
- Standalone deploys were hardened around asset inclusion, runtime data directories, backups, and restart detection.
- Dynamic host handling and safer env mutation behavior improved self-hosted reliability.
### Agent lifecycle and operator UX
- Agent/workspace creation and deletion flows were hardened end to end, including OpenClaw config normalization and cleanup.
- The boot loader was redesigned with real progress phases and framework logos.
- Cost tracking, approvals, channels, chat, and session controls were all tightened during the refactor.
## Everything Included In The v2 Update
### Core platform and mode handling
- Local mode and OpenClaw gateway mode were hardened into first-class operating modes.
- Gateway discovery and connection handling improved across configured runtimes, systemd-managed gateways, Tailscale Serve, proxied websocket paths, forwarded-proto setups, and token-preserving websocket URLs.
- Mission Control can register itself as the dashboard for an OpenClaw runtime without the earlier device-auth and dashboard URL failure cases.
- Managed-gateway UX was tightened across health, status, mode badges, and startup auto-connect behavior.
### Agents, sessions, chat, and comms
- Embedded chat became a shared workspace rather than a fragmented set of views.
- Session navigation was unified into Chat, with local Claude/Codex sessions included alongside gateway sessions.
- Hermes sessions, transcripts, memory, tasks, and cron surfaced throughout the app.
- Session transcript handling improved across local, Hermes, aggregated gateway, and disk-backed OpenClaw transcript sources.
- Agent comms, runtime tool visibility, coordinator inbox behavior, session-thread routing, and agent feed ergonomics were hardened.
- Agent registration, self-registration, rate limiting, attribution, wake/spawn actions, and agent detail editing all received follow-up fixes.
### Tasks, quality flow, and automation
- Task dispatch now polls assigned tasks and runs agents through OpenClaw with session linkage.
- Aegis quality review became an automated scheduled workflow for review-stage tasks.
- Natural-language recurring tasks now parse into cron-backed template spawning.
- Spawn/task flows were consolidated, old spawn-only UI was removed, and task/session linking became more traceable.
- Cost tracking moved into a unified Cost Tracker panel.
### Memory, knowledge, and browsing
- The memory experience was redesigned into a graph-first, Obsidian-style knowledge system.
- The memory browser now supports faster loading, lazy directory hydration, better overflow handling, and improved graph fitting behavior.
- Memory APIs expanded around graph, health, links, context, and processing actions.
- Boot-time prefetching and panel persistence reduced the need to re-fetch heavy memory state on every navigation.
### Skills and local discovery
- Skills Hub support expanded across browsing, installation, bidirectional sync, registry search, security scanning, and local disk roots.
- Local agent discovery now covers `~/.agents`, `~/.codex/agents`, and Claude agent roots more reliably.
- Skill roots and E2E skill paths can now be overridden cleanly for isolated test and self-hosted environments.
### Security, audit, and approvals
- Security audit posture scoring, secret detection, evals, optimization, and security events were substantially expanded.
- Security scan severity scoring, infrastructure checks, OpenClaw hardening checks, autofix behavior, and agent-side scan APIs improved.
- Global exec approval overlay and approval flows were added/refined.
- Auth hardening covered timing-safe behavior, CSRF, session revocation, host allowlists, and safer trusted-host resolution.
- Audit trail coverage expanded across grouped action types and more complete operator activity logging.
### Onboarding and first-run experience
- The onboarding wizard went through several iterations and now combines runtime capability detection, gateway setup, security scan, credentials, and guided getting-started flow.
- Walkthrough visibility is session-aware while progress persists per user.
- The loading experience was redesigned with branded motion, framework logos, and real boot phases instead of generic spinner states.
### UI, navigation, and operator polish
- Agent cards, the agent detail modal, the cron calendar, activity/history views, interface mode toggles, sidebar categories, and panel loading states were redesigned.
- Shared loader patterns replaced ad-hoc spinners across more panels.
- Navigation state, URL synchronization, and panel persistence were tightened to reduce remount churn and stale data flashes.
- Branding assets and logos for Mission Control, OpenClaw, Claude, Codex, and Hermes were refreshed across the interface.
### Runtime, deployment, and template hardening
- Standalone deploys were hardened across static assets, runtime data directories, sqlite migration/backup flow, restart detection, and build/runtime separation.
- Build-time DB/token isolation removed noisy runtime coupling during `next build`.
- Node support was standardized on `22.x`, with matching local, CI, Docker, and deploy expectations.
- Proxy and host validation logic became more template-safe and more dynamic for self-hosted environments.
- OpenClaw doctor drift handling, doctor fix, config normalization, and workspace lifecycle cleanup were tightened to better support real self-hosted installs.
### E2E, CI, and release readiness
- The E2E harness now uses isolated OpenClaw runtime state, isolated skill roots, deterministic scheduler behavior, and safer env handling.
- Several regressions that only showed up in CI were fixed around security autofix, workload signals, and agent deletion behavior.
- README, landing page assets, and release documentation were refreshed for the v2 release.
## Notable Improvements
- Unified cost tracker replacing the split token/cost views
- Global exec approval overlay
- Better local agent discovery and skill sync behavior
- More reliable gateway config concurrency handling
- Better navigation responsiveness and less panel reload churn
- Stronger E2E runtime isolation for CI and local test harnesses
## Detailed Functional Additions
- Framework adapters and normalized multi-agent registration flow
- Self-update banner and admin-triggered update flow
- Tenant-scoped workspaces and free-tier extraction cleanup
- Google Workspace integration
- Plugin capabilities system and Hyperbrowser integration
- Claude Code task bridge
- OpenClaw backup creation and restore-oriented backup directory handling
- Embedded `/chat` panel and provider-session-first chat workspace
- Memory graph upgrades from Canvas to Reagraph WebGL
- Security audit panel, agent eval framework, and optimization endpoint
- OpenClaw update-now trigger from the UI
- Approvals overlay, channels parity, chat parity, usage parity, device parity, and logs parity with the newer OpenClaw surface
## Detailed Fix Areas
- Login autofill, redirect race, CSP/theme flash, and auth/session regressions
- Channels auth and RPC fallback behavior
- Gateway websocket stability and device identity handshake behavior
- Memory graph blank states, overflow, sizing, auto-fit, and speed issues
- Agent detail/model-shape crashes and delete/provisioning edge cases
- Doctor warning misclassification and state-integrity surfacing
- Security scan autofix false positives and active-host preservation
- Standalone deploy asset/runtime drift and SQLite migration contention
- README and docs freshness so product marketing reflects the shipped interface
## Upgrade Notes
- Mission Control 2.0.0 expects Node `22.x`.
- Self-hosted installs should verify env files, host allowlist configuration, and runtime data directory settings after upgrade.
- If you run OpenClaw, use the in-app doctor and security panels after upgrade to catch any stale config drift.
## Links
- Changelog: [`CHANGELOG.md`](../../CHANGELOG.md)
- README: [`README.md`](../../README.md)
- Security hardening guide: [`docs/SECURITY-HARDENING.md`](../SECURITY-HARDENING.md)
---
### Releases 2.0.1 (`docs/releases/2.0.1.md`)
# Mission Control 2.0.1
Released: 2026-03-18
Mission Control 2.0.1 is the patch release that consolidates everything shipped after the `v2.0.0` launch. It includes the operational fixes that stabilized HTTP/Tailscale deployments, a zero-config first-run path, full application internationalization, broader task-routing automation, and the latest OpenClaw compatibility updates needed for current self-hosted installs.
## Highlights
### HTTP, Tailscale, and gateway stability
- Login now works reliably on HTTP Docker installs and Tailscale-served deployments.
- CSP handling was tightened so SSR nonces, theme bootstrapping, and inline script policy stay aligned during login and chunk loading.
- Public websocket URL selection and Tailscale Serve detection were hardened for proxied gateway setups.
- Gateway startup and runtime checks now better tolerate read-only configs, missing `OPENCLAW_HOME`, and container health-probe requirements.
### Better first-run setup
- A first-time setup wizard now guides fresh installs through bootstrap and initial configuration.
- Zero-config startup paths reduce the amount of manual environment setup needed for local and Docker-based installs.
- Doctor and onboarding follow-ups are more resilient, including banner persistence and safer health-check behavior.
### Stronger task and automation flow
- Task routing now preserves implementation metadata, targets the correct gateway session/agent identifiers, and can classify complexity for model-tier routing.
- GNAP sync landed for git-native task persistence.
- `awaiting_owner` state detection and other dispatch/runtime fixes improve workflow accuracy after the v2 cut.
### Broader self-hosted platform support
- Full app localization now ships across 10 languages.
- Windows setup improved with a PowerShell installer and stronger password-generation behavior.
- Workspace skill-root discovery and filtering are now surfaced throughout the app for operators running mixed local/gateway environments.
- The Docker/image pipeline now supports publishing the official image to Docker Hub when release secrets are configured.
## Full Changelog
### Added
- First-time setup wizard and zero-config startup flow
- Full i18n across the app with 10 language packs
- Trusted reverse proxy/header-auth support
- Gateway health history timeline
- Port-based Tailscale Serve proxy detection
- Task implementation-target persistence, session targeting, and complexity-based model-tier routing
- GNAP sync for git-native task persistence
- Hybrid gateway/local dashboard mode
- Workspace skill-root discovery and per-agent display
- Windows PowerShell installer
- `awaiting_owner` task status detection
### Changed
- Node runtime support is now `>=22`
- CSP/browser-security helpers were split into dedicated modules
- Release automation now supports Docker Hub publishing when configured
- Repository/release metadata now consistently points at `builderz-labs/mission-control`
### Fixed
- HTTP/Tailscale login and CSP nonce regressions
- Fresh HTTP Docker login failures caused by secure-cookie mismatch
- Gateway auth/token detection in mixed runtime setups
- Task dispatch using display names instead of gateway IDs
- Docker/runtime regressions around Compose, assets, probes, `OPENCLAW_HOME`, and read-only configs
- SQLite `SQLITE_BUSY` contention during build/runtime crossover
- Doctor banner persistence, cron panel crash handling, and null-safe model config editing
- Public websocket URL preference and onboarding gateway health probe handling
- Notification refresh timing, agent empty-state UX, delete handling, and duplicate task-title behavior
- Memory diagnostics scoping, gateway notification delivery, session labels, and missing i18n namespaces
- Windows installer password generation via CSPRNG
- Reagraph CSP regression from `style-src` nonce handling
- OpenClaw spawn compatibility when agents use configured default models
- Regression coverage for gateway dashboard registration preserving device-auth posture
### Security
- Removed `unsafe-inline` in favor of nonce-based CSP
- Added stronger SSRF/path-traversal detection in the skill registry
- Stopped forcing `dangerouslyDisableDeviceAuth` when registering Mission Control as a dashboard
### Tests
- Utility coverage improvements to satisfy the Vitest coverage threshold
- Gateway health history E2E coverage
- Docker-mode integration coverage for gateway connectivity regressions
- Regression tests for spawn compatibility and gateway registration behavior
## Contributors
- @0xNyk
- @Brixyy
- @clintbaxley
- @dk-blackfuel
- @firefloc-nox
- @HonzysClawdbot
- @hectorse.88
- @jonathan-squaredlemons
- @jonboirama
- @joshua-mo-143
- @jrrcdev
- @lucascr
- @RazorFin
- @topshelfmedia
---
### Releases 2.2.0 (`docs/releases/2.2.0.md`)
# Mission Control 2.2.0
Mission Control 2.2.0 is a security and workspace-isolation release. It rolls the post-2.1 work into a reviewed baseline for self-hosted operators while keeping the existing trunk-based OSS workflow.
## Highlights
- Native workspace brand and isolation fields, backed by migration `052`
- Strict workspace boundaries across request, scheduler, event, audit, gateway, filesystem, and background-dispatch paths
- Safer host CLI dispatch with explicit tool, budget, and workspace-root constraints
- Hardened privileged mutations for gateway control, runtime setup, users, skills, backups, updates, approvals, and host maintenance
- Tailwind CSS v4 migration with visual verification across core surfaces and themes
- Stronger protected CI with immutable action-pin and standalone artifact-boundary checks
- Structured OSS issue and PR intake with clearer provenance, risk, and verification contracts
## Security posture
The security work in this release concentrates on authority boundaries rather than UI-only controls. Ambiguous workspace ownership fails closed, sensitive mutations are throttled and strictly validated, command output is bounded or redacted, audit records avoid host paths and secrets, and privileged client calls reject failed API responses.
The release-preparation audit found no known high-severity dependency vulnerabilities. The protected quality gate covers API parity, lint, typecheck, unit tests, production build, standalone artifact boundaries, and the full Playwright suite.
## Upgrade notes
1. Back up the Mission Control database and runtime configuration.
2. Upgrade from a protected `v2.2.0` tag or corresponding immutable container digest.
3. Run migrations before enabling strict isolation on existing workspaces.
4. Review `MC_WORKSPACE_ROOT`, trusted proxies, gateway credentials, and host-runtime permissions.
5. Re-test downstream theme customizations against Tailwind CSS v4 CSS tokens.
Workspace classification and isolation metadata do not grant execution authority. The declarative approval-policy engine remains future roadmap work.
## Compatibility
- Node.js 22 or newer remains required.
- Existing shared workspaces remain supported.
- The release does not intentionally remove public API routes.
- Custom Tailwind configuration is the primary downstream migration surface.
## Verification
The release commit must pass the repository's protected `quality-gate` and screenshot-drift checks before tagging. Tags are created only from the merged `main` commit.
---
### Releases 2.3.0 (`docs/releases/2.3.0.md`)
# Mission Control 2.3.0
Mission Control 2.3.0 is a dependency-security and maintenance release. It patches 13 known vulnerabilities in the dependency tree (8 high severity), refreshes the test toolchain to current majors, and closes a locale-integrity gap — all behind the same protected quality gate as feature work.
## Highlights
- 13 OSV advisories patched: next 16.2.11 (SSRF in Server Actions, middleware/proxy bypass, cache confusion, DoS), sharp 0.35.3, brace-expansion across three major lines, transitive postcss ≥8.5.18
- Supply-chain posture retained: fixes younger than the 7-day release-age gate are excluded explicitly and age out naturally; every workspace override carries an explicit major-line upper bound
- `MC_DISABLE_RUNTIME_SCAN` opt-out for local CLI probing during runtime detection
- Locale parity restored across all 10 locales, now enforced by a guard test in the quality gate
- Test toolchain on current majors: vite 8, vitest 4, @vitejs/plugin-react 6 (production builds remain webpack)
## Security posture
This release concentrates on the dependency boundary. The patched advisories include server-side request forgery in Server Actions and a middleware/proxy bypass in the framework the dashboard runs on — self-hosted operators exposing Mission Control beyond localhost should treat this as a priority upgrade. No Mission Control application code required security changes; the protected quality gate (API parity, lint, typecheck, unit tests, production build, standalone artifact boundaries, Playwright suite) passed on the patch series unchanged.
A note for downstream forks: pnpm overrides replace a dependent's declared version range entirely, so an unbounded override range can jump major API lines in transitive dependencies. Every override this release ships carries an explicit upper bound; keep that pattern if you extend them.
## Upgrade notes
1. Back up the Mission Control database and runtime configuration.
2. Upgrade from the protected `v2.3.0` tag or corresponding immutable container digest.
3. No migrations in this release; no configuration changes are required.
4. Optionally set `MC_DISABLE_RUNTIME_SCAN=1` on hosts where local CLI probing is unwanted.
5. Forks that patched dependencies independently should reconcile against the `pnpm-workspace.yaml` overrides and release-age exclusions.
## Compatibility
- Node.js 22 or newer remains required.
- No public API routes were added or removed.
- No database schema changes.
- The vite/vitest major migration affects the test toolchain only; downstream forks with custom tests should review the vitest 4 mock-constructor semantics (constructible implementations for mocks invoked with `new`).
## Verification
The release commit must pass the repository's protected `quality-gate` before tagging. Tags are created only from the merged `main` commit.
---
--- METRICS ---
- Files Extracted: 21
- Estimated Token Budget: ~33825 tokens
- Canonical Reference: https://codewiki.google/github.com/builderz-labs/mission-control
