goose: lokaler KI-Agent mit Shell-Zugriff statt Codevorschlägen
ein erweiterbarer Open-Source-KI-Agent, der über Codevorschläge hinausgeht – installieren, ausführen, bearbeiten und testen mit jedem LLM.
Auf einen Blick
- Was ist das?
- Was der Rust-Agent der Agentic AI Foundation zwischen Desktop-App, CLI und API leistet, wie Provider und MCP-Erweiterungen angebunden werden und wo die README Angaben schuldig bleibt.
- Für wen ist es gedacht?
- goose passt zu Anwendern, die einen Agenten mit Shell-Zugriff auf dem eigenen Rechner wollen und zwischen Desktop-App, CLI und API wechseln können. Weniger passend ist es für Umgebungen, die keine fremden Agenten mit Schreibrechten zulassen, und für reine Vervollständigungsaufgaben im Editor.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
goose zwischen Desktop-App, CLI und API: drei Einstiege in denselben Agenten
goose wird in der README als universeller KI-Agent beschrieben, der auf dem eigenen Rechner läuft. Der Anspruch reicht über Codevorschläge hinaus: Das Projekt nennt Recherche, Schreiben, Automatisierung und Datenanalyse als Einsatzfelder, und die Kurzbeschreibung im Repositorium fasst die Kette als installieren, ausführen, bearbeiten und testen mit einem beliebigen LLM zusammen.
Drei Einstiege führen zum selben Kern. Eine native Desktop-App für macOS, Linux und Windows. Eine vollständige CLI für Terminal-Workflows. Eine API, um den Agenten an anderer Stelle einzubetten. Geschrieben ist das Ganze in Rust, was die README mit Leistung und Portabilität begründet.
An den Zahlen des Repositoriums lässt sich die Reichweite ablesen: gut 53.600 Sterne und rund 6.100 Forks. Gleichzeitig stehen 223 offene Issues offen, was auf ein lebhaftes Projekt hindeutet, aber auch darauf, dass nicht jede Baustelle geschlossen ist. Letzter Push auf main war der 27. August 2026.
Installation über download_cli.sh und was das Skript offen lässt
Für die CLI genügt ein Einzeiler: curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash. Das Skript kommt direkt aus den Releases, und zwar aus dem Pfad mit dem Tag stable. Wer lieber graphisch arbeitet, nimmt die Desktop-App, deren Download-Link auf die Installationsseite von goose-docs.ai zeigt.
Was die README an dieser Stelle nicht mitliefert, ist eine Prüfsumme oder eine Signatur für das Installationsskript. Wer die Pipe-Variante wählt, führt fremden Code mit den Rechten des eigenen Kontos aus. Ein Blick in den Skriptinhalt vor der Ausführung ist deshalb keine Formalität, auch wenn die README dazu schweigt. Andere Installationswege als die zwei genannten werden nicht beschrieben.
Praktisch heißt das: Die Bequemlichkeit des Einzeilers wird mit einem Vertrauensvorschuss bezahlt. In Umgebungen mit strengen Softwarefreigaben ist die Desktop-App der leichtere Weg, weil sich dort ein Installationspaket prüfen und separat verteilen lässt.
15+ Provider, ACP-Abonnements und 70+ MCP-Erweiterungen in goose
Bei der Modellwahl ist goose breit aufgestellt. Die README nennt mehr als 15 Provider, darunter Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure und Bedrock. Zwei Wege führen hinein: eigene API-Schlüssel oder bestehende Abonnements von Claude, ChatGPT und Gemini über ACP. Wie ACP im Detail funktioniert, erklärt die README nicht, sie verlinkt lediglich in die Dokumentation.
Für die Werkzeuganbindung setzt goose auf das Model Context Protocol, nach Angabe der README ein offener Standard, und nennt über 70 erreichbare Erweiterungen. Diese Zahl sagt über den Zustand des Ökosystems wenig: Welche Erweiterungen gepflegt werden, wie die Qualität streut und ob Versionen zueinander passen, lässt sich der README nicht entnehmen.
Wer Lokales bevorzugt, findet in Ollama einen Weg ohne externen Anbieter. Das unterscheidet goose von Werkzeugen, die einen Cloud-Endpunkt voraussetzen, auch wenn die README keine Aussage darüber trifft, welche Fähigkeiten mit einem lokal gehosteten Modell erhalten bleiben.
Shell-Zugriff als eigentlicher Unterschied zu einem Vervollständigungs-Plugin
Der Kernunterschied zu einem Editor-Plugin, das Text vorschlägt, liegt auf der Ausführungsebene. goose installiert, führt aus, bearbeitet und testet, und das auf dem lokalen System. Damit verschiebt sich die Risikobetrachtung: Ein Agent mit Shell-Zugriff kann Dateien verändern und Befehle starten, er erzeugt nicht nur Vorschläge, die ein Mensch abnickt.
Die README beschreibt keine Sandbox, keine Rechteabstufung und kein Bestätigungsverfahren für kritische Schritte. Für den ersten Lauf mit Schreibrechten heißt das: ein eigenes Verzeichnis, ein Konto mit begrenzten Rechten und ein Repository, dessen Verlust nichts kostet. In dieser Hinsicht ist ein reines Vervollständigungs-Plugin das kleinere Risiko, und genau dort endet der Vorteil von goose auch wieder.
Wer bereits editornahe Agenten nutzt, sollte den Vergleich an der Frage festmachen, ob Schreibzugriff gewünscht ist. Wenn nicht, bleibt von goose vor allem die Automatisierungsebene übrig, also wiederkehrende Abläufe statt individueller Codevorschläge.
Governance unter der Agentic AI Foundation und CUSTOM_DISTROS.md
Organisatorisch gehört goose zur Agentic AI Foundation (AAIF) unter dem Dach der Linux Foundation. Das ist mehr als ein Etikett: Die README verlinkt eine GOVERNANCE.md, in der die Entscheidungswege des Projekts festgehalten sind, und das Repositorium trägt einen Verweis auf die Projektseite bei insights.linuxfoundation.org. Für den Überblick über gepackte Versionen wird auf repology.org verwiesen.
Für eigene Ausgaben existiert CUSTOM_DISTROS.md. Damit lässt sich eine goose-Distribution mit vorkonfigurierten Providern, Erweiterungen und eigenem Branding bauen. Für Teams, die Agenten mit festen Vorgaben ausrollen wollen, statt jeden Arbeitsplatz einzeln einzurichten, ist das der interessantere Pfad als die CLI-Installation auf jedem Rechner.
Eine eigene Distribution verlagert allerdings die Pflege. Abhängigkeiten, Sicherheitsupdates und Kompatibilität mit neuen Provider-Versionen liegen dann beim Verteiler, nicht beim Upstream. Die README beziffert diesen Aufwand nicht.
Releasetakt von v1.46.0 bis v1.48.0 und die Lücken der README
Der Versionsstand lässt sich an den Releases ablesen: v1.48.0 vom 27. August 2026, v1.47.0 vom 21. August 2026 und v1.46.0 vom 12. August 2026. Das entspricht einem Minor-Release etwa alle ein bis zwei Wochen. Ein so hohes Tempo ist gut für Fehlerkorrekturen und anstrengend für jede Umgebung, die Versionen einfrieren muss.
Die README selbst nennt keine Versionsnummern, keine Mindestanforderungen an das System und keine Aussage zur Produktionsreife. Benchmarks und Sicherheitszusagen fehlen, und über die Erwähnung von Rust hinaus wird die interne Architektur nicht erläutert. Für Fehlerbehebung verweist das Projekt auf die Diagnose- und Known-Issues-Seiten unter goose-docs.ai, statt die Probleme im Repositorium selbst zu dokumentieren.
Lizenziert ist goose unter Apache-2.0. Für den Eigengebrauch bedeutet das keine Copyleft-Verpflichtung beim Weitergeben eigener Konfigurationen; Garantie- oder Supportzusagen enthält der im Repositorium wiedergegebene Lizenzauszug jedoch nicht.
Redaktionelles Fazit
goose passt zu Anwendern, die einen Agenten mit Shell-Zugriff auf dem eigenen Rechner wollen und zwischen Desktop-App, CLI und API wechseln können. Weniger passend ist es für Umgebungen, die keine fremden Agenten mit Schreibrechten zulassen, und für reine Vervollständigungsaufgaben im Editor. Vor dem Einstieg sollte die Installation über download_cli.sh gegen die Releaseseite geprüft werden; danach lohnt ein erster Lauf in einem Wegwerfverzeichnis mit einem einzigen lokalen Modell, bevor API-Schlüssel oder MCP-Erweiterungen dazukommen.
Community-Notizen