tale-daemon

tale-daemon führt Tale-Board-Aufgaben auf einer Maschine aus, die du kontrollierst — mit den Coding-Agent-CLIs, die du bereits hast: Claude Code (claude) und Codex (codex). Binde einen Agenten in seiner Konfiguration an eine Runtime, und seine zugewiesenen Aufgaben werden an den Daemon geschickt statt an Tales interne Modell-Schleife; das Ergebnis landet als Kommentar (mit Diff-Statistik) auf der Aufgabe, die wie jede andere Agenten-Arbeit bei In Review parkt. Für chatgesteuerte Läufe derselben CLIs in einer verwalteten Sandbox siehe Externe Agenten.

Setup

tale daemon setup    # Basis-URL, API-Schlüssel, Workspace, Berechtigungs-Obergrenze
tale daemon start    # Registrierung + Claim-Schleife (Strg-C lässt den Lauf ausklingen)
tale daemon status   # Konfiguration, erkannte CLIs, Server-Erreichbarkeit

setup erzeugt eine stabile Daemon-Identität und speichert die Konfiguration unter ~/.tale-daemon/config.json (Modus 600). Nutze einen normalen Tale-API-Schlüssel (Einstellungen → API → REST); setze TALE_DAEMON_API_KEY, um den Schlüssel aus der Datei herauszuhalten. Verbundene Daemons erscheinen unter Einstellungen → API → Runtimes mit Live-Status.

Am schnellsten geht es über den Button Schlüssel erzeugen & Befehl kopieren unter Einstellungen → API → Runtimes: Er erzeugt einen neuen API-Schlüssel und kopiert einen fertigen Befehl, in dem die URL dieses Workspaces und der Schlüssel bereits eingetragen sind. Jede Antwort, nach der setup fragt, lässt sich auch als Flag übergeben, sodass der Befehl unbeaufsichtigt läuft:

tale daemon setup --yes --url https://your-org.tale.dev --key <api-key>
tale daemon start

Der Schlüssel steht in der Befehlszeile — behandle den Ausschnitt als Geheimnis und widerrufe den Schlüssel unter Einstellungen → API → REST, falls er nach außen gelangt.

Datenschutz & Berechtigungen

• Lokale Workspace-Pfade verlassen die Maschine nie — nur die von dir gewählten Workspace-Schlüssel werden dem Server gemeldet.
• Die effektive Berechtigung eines Laufs ist min(Server-Konfiguration, Daemon-Obergrenze). full_auto (Berechtigungen überspringen / voller Sandbox-Zugriff) erfordert daher Opt-in auf beiden Seiten. Standard ist safe.

Wie Läufe ausgeführt werden

• Taktung: der Daemon fragt Arbeit mit server-gesteuertem Backoff ab (3 s nach Arbeit, 15 s im Leerlauf, gedeckelt bei 60 s nach zehn Leerlauf-Minuten — ein untätiger Daemon kostet etwa eine Anfrage pro Minute). Ein 15-s-Heartbeat während eines Laufs erneuert die Server-Lease und nimmt Abbrüche entgegen (SIGTERM).
• Isolation: jeder Lauf läuft in einem eigenen Git-Worktree auf einem tale/run-…-Branch. Es wird nichts gepusht; die Diff-Statistik reist mit dem Bericht.
• Sessions: Revisions-Läufe (Review-Feedback) setzen die vorherige CLI-Session fort, wo der Adapter es unterstützt.

Fehlerbehandlung

Alle externen Läufe teilen den internen Laufdatensatz — Budgets, Parallelitäts-Limits und Metriken gelten identisch.