Mission Control: selbst gehostete Kontrollebene für OpenClaw, Claude Code und Codex
Projektüberblick: Selbstgehostete Steuerungsebene für KI-Agenten: Verteilen Sie Aufgaben, überprüfen Sie Ausführungen, verfolgen Sie Ausgaben und betreiben Sie OpenClaw, Claude Code, Codex und andere Laufzeiten.
Auf einen Blick
- Was ist das?
- Ein TypeScript-Dashboard von Builderz Labs, das Agentenaufgaben verteilt, Läufe prüft, Ausgaben verfolgt und über SQLite läuft. Analyse von Installation, Aegis-Qualitätsgate, REST-Anbindung und Alpha-Risiken.
- Für wen ist es gedacht?
- Mission Control passt für Betreiber, die mehrere Agenten oder Laufzeiten gleichzeitig fahren und eine Antwort auf die Fragen brauchen, wem eine Aufgabe gehört, was ausgeführt wurde und wo Kosten und Fehler anfallen. Ungeeignet ist es, wenn ein einzelner Agent auf einer Maschine über seine native CLI übersichtlich bleibt oder die Bereitstellung keine Alpha-Schema-Änderungen verträgt.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 17. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Mission Control als Kontrollebene über OpenClaw, Claude Code und Codex
Mission Control löst das Koordinationsproblem, das entsteht, sobald mehrere AI-Agenten gleichzeitig arbeiten: Wer besitzt welche Aufgabe, was ist tatsächlich ausgeführt worden, welches Ergebnis hat die Prüfung passiert, und wo haben sich Ausgaben und Fehlschläge angesammelt. Die Kontrollebene von Builderz Labs sitzt dazu über den Agenten-Laufzeiten. Sie ersetzt laut README weder das Reasoning noch die Werkzeugschleifen der Laufzeiten, sondern bündelt die Arbeit um diese Schleifen in einem Dashboard.
Adapters und Beobachtungsflächen decken OpenClaw, Claude Code, Codex, CrewAI, LangGraph, AutoGen und Claude-SDK-Workflows ab. Wichtig ist die Einschränkung: Die Adaptertiefe variiert je nach Laufzeit, und das README rät ausdrücklich, docs/agent-setup.md und den CLI-Integrationsleitfaden zu lesen, bevor man Feature-Parität annimmt. Das Projekt betont auch, zu keiner der Laufzeiten zu gehören.
Der Zustand liegt lokal in SQLite, das Rendering läuft als selbst gehostete Anwendung. Das Repository zeigt 6.123 Sterne, 61 Forks und 18 offene Issues, gepusht wurde zuletzt am 25. Juli 2026, dem Release-Tag von v2.3.0.
Von install.sh --local bis zum Image ghcr.io/builderz-labs/mission-control
Für eine Quellinstallation braucht es Node.js 22 oder neuer und pnpm. Der dokumentierte Weg ist git clone des Repositorys builderz-labs/mission-control, dann bash install.sh --local. Anschließend öffnet man http://localhost:3000/setup, legt das erste Admin-Konto an und kopiert bei Bedarf den API-Schlüssel aus den Settings, etwa für Headless-Zugriff durch einen Agenten.
Wer Node und pnpm ohnehin selbst verwaltet, umgeht das Skript mit nvm use 22, pnpm install und pnpm dev. Unter Windows gibt es ./install.ps1 -Mode local für PowerShell. Der Docker-Weg ist noch kürzer: docker compose up oder das Multi-Architektur-Image per docker pull ghcr.io/builderz-labs/mission-control:latest und docker run mit Portmapping 3000.
Für netzwerkzugängliche Deployments existiert ein gehärtetes Overlay, das über docker compose -f docker-compose.yml -f docker-compose.hardened.yml up -d gestartet wird. docs/deployment.md behandelt persistente Daten, TLS-Terminierung, Gateway-Anbindung und Standalone-Builds. Für persistente Standalone-Instanzen legt die Umgebungsvariable MISSION_CONTROL_DATA_DIR einen absoluten Pfad fest, standardmäßig schreibt die Anwendung nach .data/.
Aegis-Qualitätsgate und Abschlussbelege im Task-Board
Das Herz der Governance ist der Aufgabenfluss. Das Task-Board führt eine Arbeit durch Posteingang, Zuweisung, Ausführung, Review und Qualitätsprüfung bis zur Fertigstellung. Das Besondere: Das Aegis-Qualitätsgate verlangt einen Genehmigungsdatensatz, bevor eine Aufgabe als done durchgeht. Ohne Review-Record endet nichts stillschweigend als erledigt.
Dazu gehören Abschlussbelege, sogenannte completion receipts. Die Operator-Feldnotizen im README bringen den Unterschied auf den Punkt: Logs zeigen, was lief, ein Abschlussbeleg oder ein inspiziertes Artefakt zeigt, was tatsächlich fertig wurde. Dashboards komprimieren eine Abfolge in einen Zustand, deshalb sollen Betreiber bei Review-Pflicht zuerst Identität, Aufgabe, Tool-Call, Genehmigung, Ergebnis und Verifikationsnachweis festhalten, bevor sie etwas ändern.
Die restliche Oberfläche gliedert sich in Agentenansichten mit Registration, Heartbeats und Sessions, einen Knowledge-Bereich mit Memory-Browser und Beziehungsgraph sowie einen Skills Hub, der lokale Skill-Wurzeln entdeckt und Registry-Inhalte vor der Installation scannt. Wiederkehrende Task-Vorlagen erzeugen datierte Arbeiten auf einem Cron-Zeitplan.
REST-Schleife mit MC_URL und MC_API_KEY: Agenten anbinden
Die kürzeste Anbindung läuft ohne Gateway über die REST-API. Nach dem Export von MC_URL und MC_API_KEY aus den Settings registriert man einen Agenten mit einem POST auf /api/agents/register und legt Arbeit an mit einem POST auf /api/tasks, etwa mit dem Body title, assigned_to und priority. Der Agent holt sich seine Warteschlange über GET auf /api/tasks/queue?agent=scout.
Headless-Steuerung gibt es zusätzlich über die CLI mit Befehlen wie pnpm mc agents list --json und pnpm mc tasks queue --agent scout --json sowie pnpm mc events watch --types agent,task für den Ereignisstrom. Als dritte Schnittstelle dient ein MCP-Server, der mit claude mcp add mission-control und dem Skript scripts/mc-mcp-server.cjs eingebunden wird.
Der REST-Vertrag liegt in openapi.json, eine laufende Instanz serviert die interaktive Referenz unter /docs und das OpenAPI-JSON unter /api/docs. Ein Gateway ist für Aufgaben-, Projekt-, Scheduler-, Webhook-, Alert- und Kostenarbeit optional, nur Live-Sitzungsnachrichten verlangen ein verbundenes Laufzeit-Gateway.
Workspace-Isolation, MC_ALLOWED_HOSTS und die Sicherheitsgrenze
Die Sicherheitsdokumentation des README ist konkreter als bei vielen Selbst-Hostern. Missionskontrolle gehört in ein vertrauenswürdiges Netzwerk, solange kein TLS-Reverse-Proxy und keine MC_ALLOWED_HOSTS-Konfiguration steht. Generierte Zugangsdaten sollen ersetzt oder sicher abgelegt werden, bevor breiterer Zugriff gewährt wird. Für Container-Deployments in Produktionsnähe gilt das hardened Compose-Overlay als Pflicht, nicht als Option.
Ein zweiter Baustein ist die Workspace-Logik. Die Laufzeit ist workspace-bewusst, und strikte Workspaces blockieren Bereitstellungs-Integrationen, bis die zugrundeliegenden Ressourcen Workspace-Eigentum tragen. Die v2.2.0 mit dem Titel Security Hardening and Workspace Isolation vom 17. Juli 2026 zeigt, dass dieser Bereich aktiv nachgeschärft wurde, v2.3.0 folgte am 25. Juli mit Abhängigkeits-Patches.
Dazu kommt eine bewusste Haltung zur Eingabevertrauenswürdigkeit: Agentennachrichten, Skill-Pakete, Webhooks und MCP-Inhalte sind als nicht vertrauenswürdige Eingaben zu behandeln. Schwachstellenmeldungen laufen über SECURITY.md statt über ein öffentliches Issue.
Alpha-Status, schema-Drift und wann Mission Control falsch ist
Das README trägt eine explizite Alpha-Warnung: APIs, Schemas und Konfiguration können sich zwischen Releases ändern. Wer v2.1.0 vom 4. Juli 2026 mit v2.3.0 vergleicht, sieht einen schnellen Zweig, bei dem Integrationen zwischen zwei Versionen brechen können. Für Produktionsverantwortliche heißt das, Updates im Lockfile zu pinnen und vor jedem Sprung die Release-Notizen zu lesen.
Das Projekt selbst benennt die Fälle, in denen es das falsche Werkzeug ist: wenn ein einzelner Agent auf einer Maschine über seine native CLI verständlich bleibt, wenn ein verwaltetes Multi-Tenant-SaaS gesucht wird statt einer selbst gehosteten Kontrollebene, wenn ein Agenten-Framework für Planung und Werkzeugnutzung gewünscht ist oder wenn die Bereitstellung keine Alpha-Änderungen toleriert. Diese Selbstauskunft ist selten und erleichtert die Abwägung enorm.
Als konkrete Alternative für kleine Setups dient genau dieser erste Fall: Ein einzelner Agent mit seiner nativen CLI, plus Cron für wiederkehrende Läufe, deckt denselben Bedarf ab, solange nur eine Laufzeit und ein Maschinenkontext existieren. Der Unterschied zur Kontrollebene liegt in der Prüfpflicht: Ohne Aegis und Belege endet Arbeit als done, wenn der Agent es behauptet, mit Mission Control erst, wenn ein Genehmigungsdatensatz existiert.
Redaktionelles Fazit
Mission Control passt für Betreiber, die mehrere Agenten oder Laufzeiten gleichzeitig fahren und eine Antwort auf die Fragen brauchen, wem eine Aufgabe gehört, was ausgeführt wurde und wo Kosten und Fehler anfallen. Ungeeignet ist es, wenn ein einzelner Agent auf einer Maschine über seine native CLI übersichtlich bleibt oder die Bereitstellung keine Alpha-Schema-Änderungen verträgt. Vor dem produktiven Einsatz sollte man die Alpha-Warnung ernst nehmen, das hardened Compose-Overlay von docker-compose.hardened.yml nutzen und prüfen, ob der Adapter für die eigene Laufzeit laut docs/agent-setup.md wirklich die gewünschte Tiefe bietet.
Community-Notizen