botmux: KI-Coding-CLIs aus Feishu und Lark fernsteuern

Eine Brücke zwischen Chat und CLI statt eines neuen Agenten

botmux beschreibt sich als Werkzeug, um KI-Coding-CLIs aus Feishu oder Lark heraus zu bedienen. Ein Daemon beobachtet die Nachrichten, und für jede neue Unterhaltung entsteht automatisch ein eigener Sitzungsprozess. Die Ausgabe des CLI oder Agenten wird als Live-Karte in den Chat zurückgestreamt, während ein interaktives Webterminal zusätzlich direkte Eingaben erlaubt. Das Projekt betont, dass es keine Agentenfähigkeiten neu erfindet, sondern die Werkzeuge verbindet, die ohnehin schon im Einsatz sind.

Das Repository deepcoldy/botmux ist in TypeScript geschrieben, steht unter der MIT-Lizenz und zeigt laut GitHub-Metadaten 1258 Sterne, 249 Forks und 86 offene Issues. Der Standardzweig ist master. Die Versionsschritte laufen schnell: v3.18.4, v3.18.5 und v3.18.6 erschienen alle am 29. August 2026, innerhalb weniger Stunden. Diese Kadenz passt zu einem Werkzeug, das unmittelbar am täglichen Arbeitsfluss von Entwicklergruppen sitzt.

Drei Alltagssorgen, die das README adressiert

Das README ordnet die Motivation in drei Problemen. Erstens: Der Agent läuft auf der Entwicklungsmaschine, die Person sitzt am Telefon, und ohne Benachrichtigungen bleibt der Lauf unsichtbar. botmux schiebt jede Runde der Ausgabe als Feishu-Karte ans Gerät, erlaubt Nachfragen und Unterbrechungen und stellt ein schreibbares Webterminal bereit.

Zweitens kennen die CLIs den Chatkontext nicht. Zieht man den Bot in eine Themen- oder Oncall-Gruppe und erwähnt ihn, startet der Lauf direkt im lokalen Codeverzeichnis, und mit /relay lässt sich eine komplette Sitzung mit Prozess und Gedächtnis in eine andere Gruppe umziehen. Drittens reicht ein einzelner Agent oft nicht aus. In einer Gruppe können mehrere Bots hinter verschiedenen CLIs arbeiten, und bei einer Codeprüfung können Claude Code und Codex denselben Merge-Request unabhängig bewerten, bis ihre Einschätzungen auseinanderlaufen.

Einrichtung in fünf Minuten mit botmux setup

Der Einstieg beginnt mit npm install -g botmux und verlangt Node 22 oder höher für die Paketinstallation selbst. Danach richtet botmux setup nach einem einzigen Feishu-QR-Scan die Anwendung ein, konfiguriert Berechtigungen und veröffentlicht die Version. Wer die Automatisierung überspringen will, nutzt das Kennzeichen --no-open-platform-auto und schließt Rechte und Freigabe von Hand ab; das Eintragen eigener Zugangsdaten ist laut README eine eigene Option im Einrichtungsablauf.

Anschließend startet botmux start den Daemon, und botmux autostart enable richtet den automatischen Start beim Hochfahren ein. Für den ersten Kontakt genügt eine private Nachricht an den Bot, alternativ legt botmux dashboard eine Gruppe an. Die vollständige Anleitung mit Lark-Internationalausgabe und Fehlersuche liegt unter deepcoldy.github.io/botmux/quickstart.

Ein selbstständiges Programm statt vieler Node-Versionen

Ein eigener Abschnitt des README widmet sich der Installationsform. Das npm-Paket bringt eine plattformbezogene, in sich geschlossene Binärdatei mit, die je nach Betriebssystem und Architektur ausgewählt wird, und verweist ~/.botmux/bin/botmux darauf. Dadurch existiere nur eine einzige botmux-Installation, und der Konflikt mehrerer globaler Node-Fassungen mit jeweils eigener Kopie entfalle. Der Pfad ~/.botmux/bin muss in die Umgebungsvariable PATH aufgenommen werden.

Beim Installieren werde kein natives Modul übersetzt, so das README; Python, node-gyp und ein Compiler seien nicht nötig, da das benötigte PTY bereits in der Binärdatei steckt. Unterstützt werden Linux und macOS auf x64 und arm64, für Windows gibt es laut Dokumentation nur den Weg über WSL2, da der Daemon auf PTY, tmux und Unix-Signale angewiesen ist. Wer Node ganz meiden will, lädt dieselbe Datei über install.sh von GitHub, wobei ein SHA-256-Vergleich die Integrität prüft. Nicht unterstützte Plattformen brechen die Installation mit einer klaren Fehlermeldung ab.

Sitzungen übernehmen, weiterleiten und in Echtzeit lesen

Die Kartendarstellung zeigt pro Gesprächsrunde eine live aktualisierte Karte, die den Terminalzustand als Bild überträgt, mit Bedienelementen zum Ein- und Ausblenden der Ausgabe, zum Blättern, Neustarten, Schließen und Übernehmen der Sitzung. Im Webterminal lassen sich Browser oder Telefon direkt in den CLI-Prozess tippen, auf Mobilgeräten erscheint eine schwebende Leiste mit Esc, Strg+C und den Richtungstasten.

Für Sitzungshandhabung kennt das Projekt zwei Befehle. /adopt übernimmt einen laufenden Lauf aus lokalem tmux aufs Telefon, /relay verschiebt die ganze Sitzung mit ursprünglichem Prozess und Gedächtnis in eine Teamgruppe. Vor dem Start eines Sitzungsprozesses wählt /cli gefolgt von einer Kennung wie codex das CLI der aktuellen Unterhaltung, wobei diese Wahl eingefroren wird, sobald die Sitzung läuft, und keine wrapperbezogene Konfiguration aus dem Bot-Eintrag übernimmt. Periodische Aufgaben lassen sich in natürlicher Sprache anlegen, für Programmsteuerung von außen gibt es Webhooks und eine API zur Auslösung von Aufgaben.

Mehr als 20 Adapter und die maßgebliche registry.ts

Die Adapterzahl übersteigt laut README zwanzig, aufgeteilt in lokale CLIs mit Prozessisolierung, die sich über tmux attach direkt erreichen lassen, und API- oder Cloud-Agenten wie Mira und riff. Die genannte Auswahl reicht von claude-code, codex, gemini, cursor, opencode, antigravity, copilot, grok und kimi über kiro-cli, aiden, coco für TRAE, hermes und ebsd bis zu mojo, das API-getrieben standardmäßig auf dem Wirt ausführt und mit cloud true in eine Cloudumgebung wechseln kann.

Als maßgebliche Quelle für die aktuellen Kennungen verweist das README auf die Datei src/adapters/cli/registry.ts im master-Zweig, nicht auf die eigene Aufzählung. Das ist eine praktische Angabe, weil sich die Adapterliste schnell bewegt. Für den geschützten Adapter ebsd verlangt die Dokumentation gesonderte Pflege: Einen Diag-Gateway-Zugang und Dienstkonto-Zugänge stellt man über Dateien mit eingeschränkten Rechten bereit, die drei Geheimdateien müssen dem laufenden Konto als gewöhnliche Dateien mit 0600 gehören und dürfen keine Verweise sein, während workingDir ein eigener leerer Ordner bleiben soll. Unter Linux ist bubblewrap nötig, damit die Sandbox die Aufnahme verweigert, falls die Isolation nicht zustande kommt.

Rückmeldungen zu Endantworten und ihre Datenspur

Ein fein konfigurierbarer Baustein ist die Endantwort-Rückmeldung. Im zugehörigen Bot-Eintrag von bots.json schaltet feedback.enabled die Sammlung einer dreistufigen Bewertung frei, deren Bedeutungen positive, progress und negative lauten und deren Schaltflächen Standardtexte wie brauchbares Ergebnis, wirksamer Fortschritt und fehlerhafte Schlussfolgerung tragen. Texte, Reihenfolge, Sichtbarkeit, Gründe für Ablehnung, Kommentarfeld und Wechselbarkeit sind einstellbar.

Nur die Person, die die Anfrage stellte, kann bewerten; die Karte aktualisiert sich am Ort, und freier Text fließt nicht in die Gruppenkarte zurück. Die Daten landen laut README ausschließlich in der örtlichen Datei botmux-feedback.sqlite, ein optionaler Webhook liefert die Ereignisse turn.completed und feedback.revised über eine beständige Warteschlange aus. Richtlinien sind in Stufen von Team über Bot bis zu einem bestimmten Chat geschichtet, wobei der Chat vor dem Bot und der Bot vor dem Team gilt; das Dashboard zeigt die wirksame Richtlinie vorab an und Änderungen treffen nur künftige Karten.

Fazit: Feishu als Steuerpult für lokale Agentenläufe

botmux verkauft keinen weiteren Agenten, sondern einen Bedienstandort. Wer seine Coding-CLIs ohnehin auf einer Linux- oder macOS-Maschine laufen lässt, bekommt mit Feishu-Karten, Webterminal, /adopt und /relay eine Verbindung zwischen Chat und Terminal, die Sitzungen mobil sichtbar, fragbar und übertragbar macht. Die Rückmeldekomponente und die mehrstufigen Richtlinien zeigen, dass das Projekt auch Gruppenarbeit im Blick hat, nicht nur Einzelarbeitsplätze.

Grenzen liegen in der Plattformbindung an Feishu und Lark sowie in der Windows-Frage, die nur über WSL2 beantwortet wird. Da die drei Veröffentlichungen v3.18.4 bis v3.18.6 einen einzigen Tag füllen, lohnt es sich, Updates aktiv mitzuziehen und die eigene Version gelegentlich gegen registry.ts zu halten. Wer es prüfen will, durchläuft am besten den eingeschlagenen Pfad: npm install -g botmux, botmux setup mit einem Feishu-Konto, botmux start und danach ein Probe-Gespräch, in dem ein harmloser CLI-Lauf über eine Karte aufs Telefon gestreamt wird.

Redaktionelles Fazit

botmux eignet sich für Teams, die Claude Code, Codex oder vergleichbare CLI-Agenten auf einer Entwicklungsmaschine laufen lassen und vom Handy aus verfolgen, nachfragen und eingreifen wollen. Die Plattformangabe ist eng: Der Daemon hängt an PTY, tmux und Unix-Signalen, daher gilt Windows nur über WSL2 als unterstützt. Vor dem Ernstfall sollte man botmux setup mit einem eigenen Feishu-Konto durchlaufen, eine Testgruppe einrichten und die Inhaber-Dateirechte 0600 für Geheimdateien prüfen, wenn ein geschützter Adapter wie ebsd zum Einsatz kommt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes