Mission Control
A self-hosted operations console for dispatching, reviewing, and tracking multi-runtime AI work.
Per-dimension scores and reasoning
Evidence shows role checks (requireRole admin), API key auth, security hardening docs and audit scripts, but user confirmation mechanisms (e.g., approvals) are only mentioned in docs, not verified in code. Data flow transparency has architecture diagrams and docs, but internal data flows not detailed. Sensitive data handling has security guides and key management advice, but actual implementation not verified. Dependency security has CodeQL workflow and lock files, but no vulnerability scan results. External effects have webhooks and gateway integrations, but no explicit restrictions. Rollback only mentioned in docs, no concrete mechanism. Source attribution has clear author and maintainer info.
Self-consistency is good, README aligns with code structure, but tests not run to verify. Dependency availability has package.json and pnpm-lock, but installation not verified. Failure messages have error handling code, but not fully assessed.
Target audience clear (multi-agent ops), scenarios covered broadly, capability boundaries stated (does not replace agent reasoning), trigger precision has API and CLI examples, environment fit has Docker and local install guides.
Information architecture clear, with docs directory and architecture diagram. Install notes detailed, with local and Docker methods. Naming stability reduced due to alpha status. Examples and FAQ have quickstart and troubleshooting. Known limitations explicitly stated (alpha, adapter depth varies). License is MIT, version and changelog exist. Maintenance responsibility has clear maintainer.
Output usability has CLI, API, MCP interfaces, marginal value high (solves multi-agent management pain), cost-benefit reasonable (self-hosted, open source).
Claims traceable, supported by docs and code, but cross-source verification limited (single repo only), fact-inference separation good, but tests not executed.
- Alpha status: APIs, schemas, and config may change, use with caution in production.
- User confirmation mechanisms (e.g., approvals) are only mentioned in docs, not verified in code, actual behavior may differ.
- Dependency security only has CodeQL workflow, no vulnerability scan results, recommend running security audit.
- Rollback mechanism not explicit, only mentioned in docs, need to confirm actual support.
- Cross-source verification limited, based on single repo only, recommend consulting other sources.
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_DIRavailable 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.
FAQ
Is this a managed SaaS service?
.data/, and standalone deployments can set MISSION_CONTROL_DATA_DIR to an absolute persistent path.Do I need a gateway before I can use it?
How do scripts authenticate?
/setup, copy the API key from Settings, and send it as Authorization: Bearer $MC_API_KEY on REST requests.What are the documented deployment risks?
MC_ALLOWED_HOSTS, replace or securely store generated credentials, and use the hardened Compose overlay. Agent messages, skill packages, webhooks, and MCP content should be treated as untrusted input.