telepty — eine Control Plane für AI-Agent-Sitzungen über mehrere Maschinen hinweg

telepty ist eine schlanke Control Plane für Agent-Sitzungen, mit der sich Terminal-AI-CLI-Sitzungen (claude, codex, gemini usw.), die auf mehreren Maschinen laufen, remote anweisen und auslesen lassen — Inferenz und Ausführung bleiben unverändert bei jedem Agenten (Data Plane), und telepty übernimmt nur die Schicht, die diese Sitzungen per Adresse anspricht und die Zustellung sicherstellt (PTY-basierter Hintergrund-Daemon + Session-Bridge). Jede Sitzung erhält eine namensbasierte Adresse, es wird sogar bestätigt, ob eine Anweisung tatsächlich angenommen wurde, und macOS, Linux und Windows werden unterstützt. Für die maschinenübergreifende Übertragung wurde nichts Eigenes gebaut, sondern auf das bereits bewährte Tailscale (WireGuard) aufgesetzt — statt Schlüsselaustausch, NAT-Traversal und Verschlüsselung neu zu implementieren und damit die Angriffsfläche zu vergrößern, wurde diese Aufgabe an eine seit Jahren in der Praxis bewährte Schicht delegiert. Open Source unter MIT-Lizenz.

npm i -g @dmsdc-ai/aigentry-telepty && telepty daemon start  
  
# Die bereits genutzte CLI wird einfach umhüllt und zu einer benannten Sitzung gemacht (pro Maschine einmal)  
telepty allow --id orchestrator claude    # claude-Sitzung auf dieser Maschine → "orchestrator"  
  
telepty inject "backend@100.x.y.z" "Bitte beginne mit dem Refactoring der Authentifizierungs-Middleware"   # Anweisung an die Remote-Sitzung  
telepty read-screen "backend@100.x.y.z"                               # Fortschritt prüfen  
telepty broadcast "Bitte schließt die Arbeit ab und meldet euren Status"                      # Ankündigung an alle Sitzungen

Hintergrund

Es wird immer üblicher, mehrere AI-CLI-Sitzungen über mehrere Maschinen hinweg zu betreiben. Die Ausführung skaliert parallel mit der Anzahl der Sitzungen, aber die Übergabe zwischen den Sitzungen — Anweisungen verteilen, Fortschritt prüfen, Ergebnisse einsammeln — wird weiterhin von Menschen erledigt, die zwischen Terminals hin- und herwechseln. Genau dort lag auch der Ausgangspunkt dieses Tools: Als drei AI-CLI-Sitzungen gleichzeitig auf drei Maschinen liefen, wurde nicht die Ausführung zum Flaschenhals, sondern zuerst die Phase der „Zustellung“, also das Transportieren von Anweisungen und Ergebnissen durch den Menschen.

Bisher: zwischen 3 Terminals wechseln → Fokus umschalten → Anweisungen kopieren und einfügen → Fortschritt pro Sitzung wiederholt prüfen
telepty: Anweisungen von einem Terminal aus über die Adresse name@host einspeisen und den Bildschirminhalt abrufen

Bestehende Tools füllen diese Schicht nicht aus. tmux/SSH sind Werkzeuge zum „Andocken“ an Sitzungen, daher bleibt das Senden und Prüfen weiterhin manuell, und Agent-Frameworks verlangen, dass bestehende Sitzungen und Workflows in ihre eigene Arbeitsweise umgeschrieben werden. telepty zielt auf die dünne Schicht dazwischen — laufende Sitzungen unangetastet lassen und nur die Zustellung in die Infrastruktur verlagern.

Design

Sitzungen per Namen adressieren — alle Sitzungen werden als <Sitzungsname>@<Host> angesprochen. Es ist nicht nötig, sich darum zu kümmern, auf welcher Maschine oder welchem OS das Ziel läuft.
Zwischen „gesendet“ und „empfangen“ unterscheiden — ist die empfangende Sitzung beschäftigt, wird die Nachricht in einer Queue (Mailbox) abgelegt, und der tatsächliche Annahmezeitpunkt wird anhand des Render-Zustands des Terminals festgestellt und bestätigt. Nach dem Senden muss niemand manuell nachprüfen.
Sitzungen bleiben auch nach einem Daemon-Neustart erhalten — der Prozess, der die Sitzung hält (Bridge), und der Routing-Daemon sind getrennt, sodass ein Daemon-Upgrade laufende Arbeit nicht unterbricht.
Transport an eine bewährte Schicht delegieren — es wurde kein eigenes P2P-Protokoll entwickelt. Wenn Tailscale vorhanden ist, erkennt der Daemon automatisch die Tailnet-IP und verbindet sich direkt darüber: 0 offene Ports, 0 Zertifikatsverwaltung, 0 Firewall-Regeln. In Umgebungen ohne Tailnet erfolgt die Verbindung per SSH-Tunnel (telepty connect user@host) — in beiden Fällen übernehmen bereits bewährte Tools Verschlüsselung und Identität, und telepty kümmert sich darüber nur um Sitzungsadressierung und Zustellung.

Die Befehle beschränken sich auf sechs: inject / read-screen / attach / send-key / broadcast / list; die CLI ist zugleich die API und lässt sich direkt in Shell-Skripten kombinieren. Und das Tool ist nicht nur für Menschen gedacht — das Paket enthält 9 Skills für Claude Code, Codex und Gemini CLI (installierbar über den integrierten Installer), sodass die Agenten telepty selbst als Werkzeug nutzen: Sitzungen abfragen, anderen Agenten auf anderen Maschinen Anweisungen senden und Bildschirminhalte abrufen. Genau das zeigt das Relay in der Demo unten — nicht ein Mensch, sondern jedes LLM führt telepty inject direkt selbst aus.

Erste Referenzwerte (gemessen mit Build 0.6.11 — aktuelle Release 0.7.1 · inklusive Netzwerk-Roundtrip- und PTY-Initialisierungs-Overhead)

Queueing → bestätigte Annahme bei gated inject für eine busy Sitzung: Linux ca. 487 ms · Windows ca. 1,2 s — weitere Messungen laufen; wichtiger als die Zahl ist, dass nicht HTTP-Akzeptanz, sondern das Eintreffen des ACK auf Empfängerseite als Kriterium für die Annahme gilt.
Maschinenübergreifende Zustellung zwischen macOS, Linux und Windows wurde mit demselben Maßstab verifiziert.

Sicherheit

Der Daemon bindet nur an localhost (127.0.0.1) und dedizierte Tailnet-IPs — es gibt keine 0.0.0.0-Exponierung, daher ist der Port außerhalb des Tailnets selbst per Port-Scan nicht erreichbar. Vertraut wird nur Tailnet-Peers, und Schreibrechte auf das PTY gehen nicht über den Benutzerkontext hinaus, dem die Sitzung gehört. Seit 0.7.1 werden Anfragen aus dem Browser ausdrücklich abgelehnt — damit wird verhindert, dass eine vom Benutzer besuchte Webseite über die localhost-Control-API oder WebSocket auf Sitzungen zugreift (standardmäßig keine erlaubten Origins).

Einschränkungen

Beta. Es gibt noch Rendering-Edge-Cases je nach CLI, und Windows trägt noch das Beta-Label. Da keine Terminal-Emulation erfolgt, liefert read-screen nicht das Cell-Grid, sondern den Endbereich des Output-Streams zurück — bei TUIs mit häufigem Repaint kann derselbe Frame daher mehrfach erscheinen. Bekannte Punkte sind im README im Abschnitt Limitations zusammengefasst.

Links

GitHub: https://github.com/dmsdc-ai/aigentry-telepty
README-Demo: 3 LLMs (Grok, Codex, Claude) auf 3 Maschinen (macOS, Linux, Windows) führen telepty inject direkt selbst aus und relayn einander Nachrichten — jeder Bildschirm ist ein per attach live erfasster Mitschnitt der ursprünglichen CLI-TUI. Dieselben Befehle funktionieren unverändert auch zwischen Sitzungen auf derselben Maschine (inklusive Demo für Relay auf derselben Maschine).
npm: @dmsdc-ai/aigentry-telepty (MIT, 0.7.1)

Mich interessiert, wie andere die Zustellungsschicht beim Betrieb mehrerer AI-CLI-Sitzungen lösen. Feedback nehme ich gern auf.