CompozyOS: Der Go-Daemon, der Agentenarbeit über das Terminal hinaus am Laufen hält

Warum CompozyOS die Agentenarbeit dem Daemon statt dem Terminal gibt

Das README von compozy/compozy beginnt mit einer Einschätzung, die den Projektumfang gut umreißt: Jeder kann einen Agenten anstoßen, aber Agenten dauerhaft arbeiten zu lassen ist ein Ingenieursthema mit Loops, Triggern, Cron, Speicher, Berechtigungen, Freigaben und Beobachtbarkeit. CompozyOS fasst genau diesen Stapel in ein Produkt. Der Kern ist ein lokaler Daemon, dem Sitzungen, Aufgaben, Loop-Läufe, Speicher, Automatisierung und Werkzeuge gehören. Dadurch überlebt die Arbeit das Terminal: Wird ein Client geschlossen, bleibt der Zustand beim Daemon erhalten. Gesteuert wird über das Web, die CLI, HTTP/SSE, UDS, MCP und native Werkzeuge, und alle diese Oberflächen lesen denselben vom Daemon gehaltenen Zustand, statt ein paralleles Modell zu pflegen. Laut Metadaten-Stand Ende August 2026 hat das Repository rund 2.694 Sterne und 170 Forks bei 24 offenen Issues, die Sprache ist Go, die Lizenz MIT.

Beta-Warnung zur v0.3-Linie und das Schicksal von v0.2.15

Das README markiert die v0.3-Linie ausdrücklich als Beta. Der frühere Produktstand v0.2.15 gilt als veraltet und wird nur noch für kritische Korrekturen im Zweig legacy/v0.2 gepflegt. Wer eine bestehende v0.2-Installation ersetzen will, soll zuerst den Migrationsleitfaden MIGRATION_GUIDE.md lesen; dort stehen die exakten Schema- und Befehlsänderungen. Ein konkretes Beispiel für den Bruch: Die v0.3-Laufzeit importiert Task-Dateien mit typisiertem Frontmatter in dauerhafte Aufgaben und führt sie über Loops aus, die alte Pipeline mit tasks run aus v0.2 wird nicht wiederbelebt. Die Release-Historie zeigt ein hohes Beta-Tempo, zuletzt v0.3.0-beta.21 vom 27. August 2026, davor Betas am 24. und 21. August. Für Produktionseinsätze bedeutet das: Updates kommen wöchentlich, und die Versionsnummer der eingesetzten Beta sollte man im Blick behalten.

Vier Installationswege: verifizierter Installer, npm, Go-Tag und Quellcode

Die v0.3-Beta verteilt sich über vier Kanäle. Der verifizierte Installer prüft die Sigstore-Provenienz, bevor die Binärdatei auf macOS oder Linux landet: curl -fsSL https://compozy.com/install.sh | sh. Über npm heißt das Paket @compozy/cli@beta und wird mit npm install -g @compozy/cli@beta installiert. Bei Go löst @latest während der Beta weiterhin die stabile v0.2-Linie auf, deshalb ist ein explizites Tag nötig: go install github.com/compozy/compozy@<release-tag> mit dem Tag der jeweils neuesten Release. Aus dem Quellcode geht es mit git clone https://github.com/compozy/compozy.git, cd compozy und go build -o ./bin/compozy . Bemerkenswert ist, dass Homebrew während des Beta-Fensters bewusst weggelassen wird, weil die compozy-Formel weiter die veraltete v0.2-Linie ausliefert; die Formel soll mit v0.3.0 stable zurückkehren.

Das Daemon-Laufzeitmodell: compozy daemon start, status und stop

Menschen und Agenten senden Befehle über öffentliche Steuerungsoberflächen, der home-bezogene Daemon löst den Arbeitsbereich auf, wendet Berechtigungen und Laufzeitrichtlinien an, koordiniert ACP-Agenten und persistiert Ereignisse und Ressourcenzustände. Verwaltet wird der Daemon mit compozy daemon start, compozy status und compozy daemon stop. Als ACP-kompatible CLIs nennt das README Claude Code, OpenClaw und Hermes, die alle denselben daemon-eigenen Zustand betreiben. Der Speicher ist lokaler Natur: Eine einzelne Go-Binärdatei und SQLite-gestützte Speicher halten den Laufzeitzustand auf dem Rechner des Betreibers, es sei denn, ein konfigurierter Anbieter oder eine Erweiterung besitzt eine externe Grenze. Fernzugriff bleibt explizit: Der Gateway-Dienst koppelt Geräte und legt nur die privaten oder öffentlichen Oberflächen offen, die der Betreiber freigibt.

Drei Konfigurationsebenen von Flags über .compozy/config.toml bis zum globalen Pfad

Globale Standardwerte liegen in ~/.compozy/config.toml, ein Arbeitsbereich kann unterstützte Felder über .compozy/config.toml überschreiben. Die Priorität ist eindeutig geregelt: Explizite Befehlsflags schlagen die Arbeitsbereichskonfiguration, diese schlägt die globale Konfiguration, diese schlägt eingebaute Standardwerte. Drei Befehle helfen beim Umgang: compozy config path zeigt den Pfad, compozy config validate prüft die Dateien und compozy config show -o json gibt die effektive Konfiguration als JSON aus. Das README warnt davor, Konfiguration, Anmeldeinformationen und Provider-Home-Richtlinien in einen Topf zu werfen, und rät, dem Konfigurationsleitfaden unter compozy.com/docs/configuration/config-toml zu folgen, statt v0.2-Zustand in ein v0.3-Heim zu kopieren. Für Automatisierung ist die strukturierte Ausgabe mit -o json relevant, damit andere Programme denselben Zustand verwalten können.

Agentendefinitionen unter ~/.compozy/agents mit AGENT.md und lokaler mcp.json

Agenten sind Objekte, die man einmal erstellt und wiederverwendet. Die Definitionen liegen unter ~/.compozy/agents/<name>/ oder arbeitsbereichsbezogen unter .compozy/agents/<name>/, jede enthält eine AGENT.md und kann eine agentenlokale mcp.json mitbringen. Arbeitsbereichsdefinitionen überschreiben globale Definitionen als Ganzes. Drei Befehle aus der README zeigen den Umgang: compozy agent list -o json listet die Agenten auf, compozy agent info general -o json zeigt Details zu einem Agenten namens general, und compozy session new --agent general legt eine dauerhafte Sitzung an. Sessions, Loops und Capabilities sind damit Objekte mit expliziten Besitzern und Arbeitsbereichsgrenzen, nicht weggeworfene Skripte pro Durchlauf.

Erweiterungen in drei Befehlen: init, dev und tool invoke

Erweiterungen fügen versionierte Ressourcen und Laufzeitverhalten über deklarierte Bereitstellungsoberflächen hinzu. Der Daemon besitzt Entdeckung, Aktivierung, Vertrauensentscheidungen, Lebenszyklus und Hooks, sodass Erweiterungen öffentliche Laufzeitverträge nicht umgehen. Das README führt mit drei Befehlen durch ein Minimalbeispiel: compozy extension init hello --template tool-provider-go erzeugt ein Projekt, compozy extension dev hello startet die Entwicklungsschleife und compozy tool invoke ext__hello__search --workspace . --input '{"query":"compozy"}' ruft das Werkzeug auf. Code-lastige Erweiterungen deklarieren ein Werkzeug einmal im Code, compozy extension build generiert das Manifest; reine Ressourcen-Erweiterungen schreiben extension.toml von Hand. Zwei SDKs sind veröffentlicht und versionsabgestimmt zum Daemon: @compozy/extension-sdk auf npm und github.com/compozy/compozy/sdk/go. Die Erweiterungs-CLI bietet unter anderem compozy extension provenance <name> -o json für Herkunftsangaben und compozy extension logs <name> --follow für laufende Protokolle.

Fazit: lokaler Speicher, Compozy Network und für wen der Daemon passt

CompozyOS denkt Agentenbetrieb als System: Sessions, Loops, Freigaben und Speicher sind Kernobjekte, keine Plugins, erreichbar über Web, CLI, HTTP/SSE, UDS, MCP und native Werkzeuge. Mit dem Protokoll compozy-network/v0 können Sitzungen zudem Peers entdecken, typisierte Nachrichten austauschen, Arbeit delegieren und den Abschluss mit Belegnachweisen quittieren. Die Zielgruppe sind Entwickler und technische Operatoren, die Agentenarbeit ohne offenes Terminal automatisieren wollen. Wer dagegen nur gelegentlich eine einzelne Agentensitzung führt, braucht die Daemon-Infrastruktur nicht. Vor einem ernsthaften Einsatz spricht der Beta-Status der v0.3-Linie gegen kritische Workloads; sinnvoll ist es, mit compozy config validate zu starten, die Berechtigungs- und Freigabeflüsse in einer Testumgebung zu durchlaufen und das Update-Tempo der Beta-Releases in die Planung einzukalkulieren.

Redaktionelles Fazit

CompozyOS eignet sich für Entwickler und technische Operatoren, die Agenten dauerhaft laufen lassen wollen, statt Skripte pro Durchlauf neu zu schreiben. Die v0.3-Linie ist Beta, v0.2.15 ist veraltet; wer migriert, sollte zuerst MIGRATION_GUIDE.md lesen. Wer nur eine einzelne Agentensitzung gelegentlich braucht, kann mit dem CLI seines Agenten allein auskommen und braucht den Daemon nicht.

Offizielle Quellen

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