Die BuildCaptain-CLI installieren
Installiere das optionale Kommandozeilen-Tool über Homebrew, damit KI-Coding-Agenten wie Claude Code und Codex deine erlaubten Jenkins-Builds starten können.
Geschrieben von Loris Siegenthaler · Macher von BuildCaptainDie BuildCaptain-CLI ist ein optionaler Begleiter zur App. Sie lässt KI-Coding-Agenten — Claude Code, Codex oder jeden MCP-Client — die Jenkins-Builds auflisten und starten, die du in der App ausdrücklich erlaubt hast. Die CLI spricht nie direkt mit Jenkins: Jede Anfrage läuft über die BuildCaptain-App auf demselben Mac, die deine Regeln pro Repository durchsetzt und vor jedem Start deine Freigabe verlangen kann.
Installation mit Homebrew
Öffne das Terminal und führe aus:
brew install inuali/tap/buildcaptain
Noch kein Homebrew? Du bekommst es auf brew.sh. Alternativ kannst du das Binary von GitHub Releases herunterladen und selbst in deinen PATH legen.
Deinen KI-Agenten verbinden
Registriere die CLI als MCP-Server bei dem Agenten, den du verwendest:
claude mcp add buildcaptain -- buildcaptain mcp
codex mcp add buildcaptain -- buildcaptain mcp
Der Agent erhält vier Tools: list_run_configurations, trigger_run, get_run_status und get_run_logs. Konfigurationen, die auf ein Git-Repository beschränkt sind, sind nur sichtbar, wenn der Agent in einem passenden Checkout arbeitet — er sieht also immer nur die Builds, die du für dieses Projekt erlaubt hast. Konfigurationen, die in der App als "Any repository" markiert sind, stehen überall zur Verfügung.
trigger_run wartet, bis der Build fertig ist, und meldet das Ergebnis — meist genügt dem Agenten also ein einziger Aufruf. Läuft der Build beim Ende der Wartezeit noch, liefert das Tool eine run_id für get_run_status zurück.
Sobald Jenkins den Build gestartet hat, listet das Ergebnis auch seine Stages mit ihrem jeweiligen Status — ein fehlgeschlagener Build zeigt also, welche Stage gebrochen ist. get_run_logs (auf der Kommandozeile buildcaptain logs) gibt dann die Konsolenausgabe dieser Stage aus, oder die des ganzen Builds, wenn keine Stage genannt wird. Dafür ist BuildCaptain 26.9 oder neuer nötig.
Bevor es funktioniert
- Die BuildCaptain-App muss installiert sein. Läuft sie nicht, startet die CLI sie automatisch im Hintergrund.
- Aktiviere das Gateway in der App: AI Agents → Enable local agent gateway.
- Lege im selben Einstellungsbereich mindestens eine Run-Konfiguration für dein Repository an.
Probier es im Terminal aus
Führe das an beliebiger Stelle aus:
buildcaptain configs
Der Befehl gibt die im aktuellen Ordner verfügbaren Run-Konfigurationen aus: In einem Git-Checkout bekommst du die Konfigurationen dieses Repositorys plus die repository-unabhängigen; überall sonst nur die repository-unabhängigen. buildcaptain run <configuration> startet eine und wartet auf das Ergebnis; jeder Statuswechsel wird dabei ausgegeben. Mit --no-wait bist du sofort wieder am Prompt. buildcaptain wait <run-id> nimmt einen Build wieder auf und blockiert, bis er fertig ist; buildcaptain status <run-id> prüft ihn einmal. Ohne ID beziehen sich beide auf den letzten Lauf.
Problembehebung
- "BuildCaptain is not running or Agent Access is disabled." — Öffne die App und schalte Enable local agent gateway ein.
- Repository-beschränkte Builds fehlen — die CLI erkennt dein Projekt am
origin-Remote. Stelle also sicher, dass du im richtigen Checkout arbeitest und das Git-Remote der Konfiguration übereinstimmt. Du arbeitest in einem Fork, dessenoriginvom konfigurierten Repository abweicht? SetzeBUILDCAPTAIN_REPO=github.com/acme/widgets(das konfigurierte Repository) in deiner Shell oder MCP-Konfiguration. - Gar keine Konfigurationen gelistet — prüfe, ob die Konfigurationen in der App aktiviert sind.
Die CLI ist Open Source (MIT): github.com/inuali/buildcaptain-cli.
BuildCaptain