Mission Control
A self-hosted operations console for dispatching, reviewing, and tracking multi-runtime AI work.
What does this agent do, and when should you use it?
Mission Control is a self-hosted control plane for dispatching tasks, inspecting runs, reviewing failures, and tracking spend from a local dashboard. It sits above agent runtimes rather than replacing their reasoning or tool loops, governing the operational work around tasks, sessions, approvals, events, and completion receipts. The project exposes a Next.js web UI, CLI, MCP server, OpenAPI-described REST API, WebSocket, and SSE, with local control-plane state stored in SQLite. It documents integrations with OpenClaw, Claude Code, Codex, and other workflows including CrewAI, LangGraph, AutoGen, and Claude SDK, although adapter depth varies by runtime. It can run from a local Node.js/pnpm install, Docker Compose, or a published container image; network-facing deployments require the documented TLS, host, and hardening measures.
An operator creates the first administrator account at /setup and copies an API key from Settings. A script or runtime registers an identity through POST /api/agents/register, creates or assigns work through POST /api/tasks, and an agent retrieves queued work with GET /api/tasks/queue?agent=scout. The task board moves work through inbox, assignment, execution, review, quality review, and completion; Aegis review requires an approval record before a task reaches done. The console aggregates heartbeats, sessions, activity, schedules, webhooks, logs, token usage, and cost views, while the CLI supports pnpm mc agents list --json, pnpm mc tasks queue --agent scout --json, and pnpm mc events watch --types agent,task. Its MCP entry point is scripts/mc-mcp-server.cjs, and a running instance serves API references at /docs and /api/docs.
- An engineering lead running several Codex or Claude Code workers who needs to establish ownership, execution state, and review status for a task.
- A team operating agents on a local machine or trusted private network that wants SQLite-backed task, session, event, and cost operations instead of a managed multi-tenant service.
- A developer building a script-driven loop that registers an agent such as `scout`, creates work through the REST API, and polls that agent’s queue.
- An operator investigating a failed or high-risk run who needs to record the identity, task, tool call, approval, result, and verification evidence before changing it.
- A team creating recurring work from cron-based task templates and reviewing agent, task, and system events in one activity stream.
What are this agent's strengths and limitations?
- Combines a web UI, CLI, MCP, REST/OpenAPI, WebSocket, and SSE in one local control plane for both human operators and scripts.
- The Aegis quality gate requires an approval record, and completion receipts help distinguish logged execution from verified completion.
- SQLite runs in WAL mode for local state, with `MISSION_CONTROL_DATA_DIR` available for an absolute persistent data location.
- It brings tasks, registration, heartbeats, sessions, schedules, activity, logs, token usage, and costs into the same operating surface.
- The project is explicitly alpha software, so APIs, schemas, and configuration may change between releases.
- Runtime adapter depth varies, so teams must validate the specific integration they need for OpenClaw, Claude Code, Codex, or another runtime.
- Live session messaging requires a connected runtime gateway, even though the gateway is optional for task and other operations work.
- A network-accessible deployment needs TLS termination, `MC_ALLOWED_HOSTS`, and hardening; the project warns against exposing it without those controls.
How do you install or deploy this agent?
A source install requires Node.js 22 or newer and pnpm: run git clone https://github.com/builderz-labs/mission-control.git, cd mission-control, and bash install.sh --local. The manual route is nvm use 22, pnpm install, and pnpm dev; on Windows, run ./install.ps1 -Mode local in PowerShell. For containers, run docker compose up, or pull ghcr.io/builderz-labs/mission-control:latest and run docker run --rm -p 3000:3000 ghcr.io/builderz-labs/mission-control:latest. Then open http://localhost:3000/setup, create the first admin account, and copy the API key from Settings for scripts or agents.
How do you use this agent?
Set MC_URL=http://localhost:3000 and MC_API_KEY=replace-with-your-api-key. Register an agent with POST $MC_URL/api/agents/register using a body such as {"name":"scout","role":"researcher"}, then create work through POST $MC_URL/api/tasks, for example {"title":"Review open incidents","assigned_to":"scout","priority":"medium"}; authenticate requests with Authorization: Bearer $MC_API_KEY. The agent claims work through GET $MC_URL/api/tasks/queue?agent=scout, or use pnpm mc tasks queue --agent scout --json. For MCP, run 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.
How does this agent compare with similar options?
Mission Control does not replace OpenClaw, Claude Code, or Codex, and it is not an agent framework that defines planning or tool use. It operates above those runtimes to centralize dispatch, observation, review, and governance.