Goose: der quelloffene Agent, den man auf dem eigenen Rechner ausführt

Goose ist ein quelloffener Coding-Agent, der auf dem Rechner der Entwickelnden läuft und nicht in der Cloud eines Anbieters. Er erscheint als Desktop-App für macOS, Linux und Windows, als vollständige CLI und als einbettbare API, und er ist in Rust geschrieben. Block hat ihn im Januar 2025 öffentlich herausgebracht und im Dezember 2025 an die Agentic AI Foundation der Linux Foundation gespendet, gemeinsam mit dem Model Context Protocol von Anthropic und der AGENTS.md von OpenAI. Das Projekt wird also von einer Stiftung geführt und nicht mehr von dem Unternehmen, das es begonnen hat.

Nicht_commodity ist hier das Erweiterungsmodell. Goose erreicht die Außenwelt über Model-Context-Protocol-Server, und die Werkzeuge einer Session sind die dafür aktivierten Erweiterungen. Die Fähigkeitsfläche eines Agenten ist damit eine Konfigurationsentscheidung und keine Eigenschaft der Binärdatei, was eine deutlich andere Form ist als ein Agent mit fest eingebautem Werkzeugsatz.

Die Position nach der Lektüre der Dokumentation: Das ist ein ernstzunehmender, gut dokumentierter Agent, der den kommerziellen Spitzenreitern an Politur und an Aufgabenqualität nachsteht und gewinnt, weil sich jedes Teil von ihm einsehen, forken und weiterverbreiten lässt, auch das Format, in dem seine Arbeitsabläufe geschrieben sind. Am überzeugendsten ist er als Plattform, um Agentenverhalten über eine Flotte hinweg zu vereinheitlichen, am wenigsten als tägliche Einzelbegleitung, wenn ohnehin ein kommerzielles Werkzeug mit besserer Autovervollständigung lizenziert ist.

Was goose ist

Zwei Oberflächen auf einem Kern. Die Desktop-App ist die zugängliche Hälfte, die CLI die skriptfähige; beide steuern dieselbe Sitzungslogik, dieselbe Konfigurationsdatei und dieselbe Erweiterungsliste. Das Repository steht unter Apache-2.0 und zeigt rund 55.000 Sterne und 6.400 Forks.

• Unter Apache-2.0 und in Rust geschrieben, veröffentlicht als signierte Release-Artefakte und als Einzeiler-Installationsskript für die CLI.
• Mehr als 15 LLM-Anbieter, darunter Anthropic, OpenAI, Google, Azure, Bedrock, OpenRouter und Ollama, per API-Schlüssel oder bestehendem Abo über ACP.
• Mehr als 70 Erweiterungen über MCP, in vier Typen: stdio, builtin, platform und streamable HTTP.
• Vier Berechtigungsmodi, vom vollständig autonomen bis zum reinen Chat, pro Sitzung wählbar und mit granularen Werkzeugrechten obendrauf.
• Rezepte: versionierte YAML-Dateien, die Anweisungen, Erweiterungen, Parameter, Einstellungen, Retries und ein JSON-Antwortschema zu einer prüfbaren Einheit bündeln.
• Automatische Kompaktierung bei 80 Prozent des Kontextfensters, Zusammenfassung von Werkzeugausgaben und eine harte Rundengrenze mit Standardwert 1000.
• Ein Scheduler, ein ACP-Server für Editoren wie Zed, ein eingebauter Review-Befehl und dokumentierte Unterstützung für ein eigenes gebrandetes Build.

Wie es funktioniert

Die Schleife ist die übliche: Kontext senden, Nachricht empfangen, und wenn sie einen Werkzeugaufruf enthält, das Werkzeug ausführen und das Ergebnis in den nächsten Zug geben. Was goose um diese Schleife herum ergänzt, ist Buchführung. Tokenzählung, Kompaktierung, Rundengrenze, Kostenschätzung und ein Berechtigungstor liegen alle zwischen Modell und Dateisystem, und jedes davon ist eine Einstellung und kein im Binary versteckter Heuristikwert.

Sitzungen sind eine durchgehende Unterhaltung. Eine Tokenanzeige zeigt den belegten Anteil am verfügbaren Fenster, und sobald die Kompaktierungsschwelle erreicht ist, wird der ältere Teil zusammengefasst, während die vorherigen Nachrichten sichtbar bleiben. Das ist ein vernünftiges Design, und es bedeutet, dass eine lange Sitzung an Genauigkeit verliert, lange bevor sie ausfällt.

# CLI installieren (macOS, Linux), dann einen Anbieter wählen
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash
goose configure

# Sitzung in einem Repository starten, mit Rundengrenze
cd ~/code/my-service
goose session --max-turns 25 --with-builtin developer

# unbeaufsichtigt: ein Rezept ausführen, nur die Antwort ausgeben
goose run --recipe release-check.yaml --params env=staging --quiet

# welcher Anbieter, welches Modell, welche Erweiterungen
goose info --verbose

Die Anbietereinstellungen liegen in einer YAML-Konfigurationsdatei, Geheimnisse standardmäßig im System-Schlüsselbund. GOOSE_DISABLE_KEYRING erzwingt Dateispeicherung, wie die Dokumentation es für Container und kopfloses Linux ohne Schlüsselbund vorschreibt. Seit Version 1.10.0 liegen Sitzungen in einer SQLite-Datenbank statt in einer Sammlung von JSONL-Dateien, Sicherung und Migration sind also ein Datenbankproblem.

Kontext, Runden und Kosten

Drei Einstellungen entscheiden, wie lange eine Sitzung läuft und was sie kostet, und alle drei sind einfache Konfigurationsschlüssel statt versteckten Verhaltens. Die Dokumentation schlägt sogar Werte je Art von Arbeit vor, was ungewöhnlich und nützlich ist.

• Schwelle der automatischen Kompaktierung, Standard 0.8, also der Anteil des Kontextfensters, ab dem alte Züge zusammengefasst werden; 0.0 schaltet sie ab.
• Maximale Runden ohne menschliche Eingabe, Standard 1000. Am Limit hält der Agent an und fragt. Die Dokumentation nennt 5 bis 10 für Erkundungsarbeit und 100 oder mehr für eine Migration.
• Lebensdauer des Prompt-Caches bei Anthropic, Standard 5 Minuten oder 1 Stunde, um den gecachten Präfix über Pausen hinweg mit höherer Cache-Schreibrate am Leben zu halten.
• Eine Kostenschätzung je Sitzung, kalkuliert aus dem OpenRouter-Katalog und lokal zwischengespeichert. Die Dokumentation stellt klar, dass das eine Schätzung nach öffentlichen Preisen ist und keine Rechnung.

Kontextlimits werden aus einer expliziten Vorgabe, dann aus deklarativer Anbieterkonfiguration, dann aus Laufzeitermittlung, dann aus Modellmetadaten und zuletzt aus einem Standard von 128.000 Tokens aufgelöst. Jener letzte Fallback ist wichtig, wenn goose auf ein Gateway mit eigenem Modellnamen zeigt: Die Anzeige nennt die falsche Zahl, bis das Limit ausdrücklich gesetzt wird, eine kleine Falle für alle, die es hinter einem Proxy betreiben.

Erweiterungen und Rezepte

Eine Erweiterung ist ein MCP-Server mit einem Namen, einem Befehl, einem Timeout und einer optionalen Liste der Werkzeuge, die er anbieten darf. Diese Liste ist die praktisch wichtigste Einstellung: Jedes sichtbare Werkzeug ist eine Entscheidung, die das Modell in jedem Zug richtig treffen muss, und die Liste zu verengen ist billiger als ein besserer Prompt.

version: "1.0.0"
title: "Release-Risiko-Prüfung"
description: "Branch gegen eine Basis vergleichen und Risiko berichten"
parameters:
  - key: base
    input_type: string
    requirement: required
    description: "Branch, gegen den verglichen wird"
prompt: |
  Vergleiche diesen Branch mit {{ base }} und fasse das
  Verhaltensrisiko nach Auslieferungsreihenfolge zusammen.

extensions:
  - type: builtin
    name: developer
    timeout: 300
  - type: stdio
    name: github
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env_keys: [GITHUB_PERSONAL_ACCESS_TOKEN]
    available_tools: [get_file_contents, search_code]

settings:
  goose_provider: anthropic
  temperature: 0.2
  max_turns: 40

retry:
  max_retries: 2
  timeout_seconds: 30
  checks:
    - type: shell
      command: "test -f RISK.md"

Das ist die Form, die sich lohnt zu kopieren. Ein Rezept ist prüfbares YAML mit einer Validierungs-Erfolgskontrolle, ein geplanter Job kann also so lange wiederholt werden, bis er etwas Prüfbares erzeugt, statt blind neu zu starten, und die Validierung lehnt eine Template-Variable ohne passende Parameterdefinition ab. Unterrezepte setzen sich genauso zusammen, wobei das Elternrezept seine Werte auf die Kinder abbildet, allerdings bezeichnet die Dokumentation dieses Feature noch als experimentell und weist darauf hin, dass Unterrezepte in isolierten Sitzungen ohne gemeinsamen Speicher laufen.

Berechtigungen und Autonomie

Berechtigung ist die gesamte Sicherheitsgeschichte, und der Standard ist die weitgehendste vorhandene Einstellung. Es gibt vier Modi, und jede Sitzung wählt ihren eigenen.

• Autonom: ändert Dateien, nutzt Erweiterungen und löscht Dateien ohne Freigabe. Das ist der Standard.
• Manuelle Freigabe: fragt vor jedem Werkzeug und beachtet die granulare Liste der Werkzeugrechte.
• Smarte Freigabe: gibt automatisch frei, was als geringes Risiko eingeschätzt wird, und fragt beim Rest. Die Einstufung nimmt der Modellanbieter vor, ist also ein Vorschlag und keine Kontrolle.
• Nur Chat: verbietet Erweiterungen und Dateiänderungen, für Analyse, Schreiben und Argumentieren.

Wo es knirscht

Die Lücken sind praktisch, nicht architektonisch. Die meisten externen Erweiterungen starten über npx oder uvx, der Agent hängt also stillschweigend an Node.js oder einer Python-Werkzeugkette. Er startet Entwicklungserver, um die niemand gebeten hat, und die beenden sich nie, sodass die Sitzung bis zum Tool-Timeout hängt. Erweiterungen laden ihre Laufzeiten über eine mitgelieferte Kopie von Hermit, was in einem abgeschotteten Netzwerk scheitert, sofern die Shims nicht umbenannt werden. Unter Windows erwartet die Installation Node.js an einem festen Pfad, und das dokumentierte Mittel ist eine symbolische Verknüpfung. Und die Seite zu bekannten Problemen rät, die Sitzung zu beenden und eine neue zu starten, wenn der Agent nicht mehr reagiert, was ehrlich, aber keine Lösung ist.

Der Tausch gegen die kommerziellen Werkzeuge ist eindeutig. Claude Code ist der bessere tägliche Begleiter: Es startet schneller, die Modellqualität ist der Grund, warum Leute bleiben, und sein Berechtigungsmodell kommt vom Anbieter, statt vom Modell erschlossen zu werden. OpenHands gewinnt genau dort, wo goose am schwächsten ist, indem es Agentenarbeit in einer Sandbox laufen lässt, in der das Ergebnis inspected werden kann, um den Preis einer schwereren Laufzeit. Goose gewinnt die beiden Dinge, die für ein Plattformteam zählen: eine Lizenz, die Forking erlaubt, und ein deklaratives Format mit einer Allowlist je Rezept, das über eine ganze Flotte durchsetzbar ist.

Die zweite strukturelle Lücke ist Sicherheitstiefe. Es gibt eine Prompt-Injection-Erkennung mit einstellbarer Schwelle und einen Adversary-Modus, der einen getrennten Prüfagenten über die Werkzeugaufrufe laufen lässt, eine interessante Idee und für sich allein keine Kontrolle. Lesewerkzeuge laufen standardmäßig ohne Freigabe, und Erweiterungen laufen mit den Rechten und Anmeldedaten der Entwickelnden.

Fazit

Goose ist eine glaubwürdige Voreinstellung für ein Team, das seinen Agenten-Stack selbst besitzen will, und ein schlechter Ersatz für einen gut konfigurierten kommerziellen Agenten auf einem Laptop. Der eigentliche Beitrag ist nicht die Coding-Schleife, die Ware, sondern die Kombination aus einer stiftungeigenen Lizenz, einer deklarativen Erweiterungs-Allowlist und einem Rezeptformat mit maschinell prüfbaren Erfolgskriterien. Das ist die Ebene, die Organisationen immer wieder schlecht auf jemand anders Agent nachbauen.

1. Nimm es, wenn Agenten auf Rechnern laufen müssen, die du nicht kontrollierst, oder dort, wo Code das Netzwerk nicht verlassen darf. Binärdatei und Dokumentation lassen sich beide für den abgeschotteten Betrieb paketieren.
2. Nimm es, um Verhalten über eine Flotte zu vereinheitlichen. Erweiterungs-Allowlist je Rezept und Berechtigungsmodus sind der Mechanismus, die Rezeptdatei ist das versionierte Artefakt.
3. Nimm es als zweite Meinung. Dieselbe Aufgabe mit zwei Agenten und verschiedenen Werkzeugen zu prüfen und die Diffs zu vergleichen ist billig, wenn beide kostenlos laufen.
4. Nimm es nicht als ersten Agenten für eine Entwicklerin. Die Installation ist ein Skript und die erste Sitzung braucht einen Anbieterschlüssel, die Einrichtung landet also bei dem, der am wenigsten Zeit dafür hat.
5. Stelle ein funktionierendes kommerzielles Werkzeug nicht darauf um. Bei der Aufgabenqualität liegen die Führenden weiter vorn und das Ökosystem darum ist tiefer.

Quellen

1. goose-Dokumentation: Schnellstart
2. goose-Dokumentation: Konfigurationsdateien
3. goose-Dokumentation: Berechtigungsmodi
4. goose-Dokumentation: intelligente Kontextverwaltung
5. goose-Dokumentation: Rezeptreferenz
6. goose-Dokumentation: CLI-Befehle
7. goose-Dokumentation: bekannte Probleme
8. goose hat ein neues Zuhause: die Agentic AI Foundation (7. April 2026)
9. goose-Repository auf GitHub