opencode im Terminal: Zwei Agenten, ein Installationsskript und ein Beta-Desktop
OpenCode ist ein Terminal-Coding-Agent, der Repositorys überprüfen, Dateien bearbeiten, Befehle ausführen und eine Verbindung zu mehreren Modellanbietern herstellen kann.
Auf einen Blick
- Was ist das?
- opencode ist ein in TypeScript geschriebener KI-Codieragent für das Terminal, lizenziert unter MIT und mit über 200.000 Sternen eines der größten Projekte seiner Art. Das README dokumentiert zwei eingebaute Agenten hinter der Tab-Taste, eine stattliche Liste an Installationswegen und eine Desktopanwendung, die ausdrücklich als Beta gekennzeichnet ist.
- Für wen ist es gedacht?
- Geeignet ist opencode für Entwickler, die einen Agenten im Terminal wollen, der Repositories einlesen, Dateien ändern und Befehle ausführen kann, und die zwischen einem vollen Zugriff und einer rein lesenden Arbeitsweise wechseln möchten. Weniger geeignet ist es für Umgebungen, in denen eine Beta-Oberfläche oder ein Agent mit Schreibrechten grundsätzlich ausscheidet, und für alle, die einen geregelten Veröffentlichungsrhythmus brauchen.
- Darf ich es kommerziell nutzen?
- Ja. MIT 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 TypeScript, 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
Was der opencode-Agent im Terminal übernimmt
Die Selbstbeschreibung im README ist kurz: der quelloffene KI-Codieragent. Die Projektbeschreibung formuliert es konkreter und nennt vier Fähigkeiten, die den Rahmen abstecken: Repositories untersuchen, Dateien bearbeiten, Befehle ausführen und mehrere Modellanbieter anbinden. Damit ist auch gesagt, was opencode nicht ist, nämlich kein Editor und keine Entwicklungsumgebung, sondern ein Programm, das in einer bestehenden Shell arbeitet.
Die Kennzahlen des Repositorys fallen für ein Werkzeug dieser Art groß aus. Rund 202.000 Sterne und gut 26.000 Forks stehen 5.684 offenen Issues gegenüber. Als Hauptsprache ist TypeScript angegeben, die Lizenz ist MIT, als Standardzweig dient dev. Die Projektseite liegt unter opencode.ai. Das README ist in mehr als zwanzig Sprachen verfügbar, darunter eine deutsche Fassung unter README.de.md. Für wen das gedacht ist, verrät ein Hinweis im Abschnitt zu den Agenten: Der lesende Modus wird ausdrücklich für das Erkunden fremder Codebestände und das Planen von Änderungen empfohlen.
build und plan: Zwei Agenten hinter der Tab-Taste
Das README beschreibt zwei eingebaute Agenten, zwischen denen die Tab-Taste umschaltet. Der Agent build ist die Voreinstellung und besitzt vollen Zugriff für Entwicklungsarbeit. Der Agent plan arbeitet lesend und lehnt Dateiänderungen in der Grundeinstellung ab. Bevor er Shell-Befehle ausführt, fragt er um Erlaubnis. Das README empfiehlt ihn, wenn ein fremder Codebestand erkundet oder eine Änderung vorbereitet werden soll.
Dazu kommt ein Unteragent namens general für umfangreiche Suchen und mehrstufige Aufgaben. Er wird intern verwendet und lässt sich in Nachrichten mit @general aufrufen. Die Dokumentation dazu liegt unter opencode.ai/docs/agents.
Diese Aufteilung ist der eigentliche Kern des Werkzeugs, weil sie die Frage nach Rechten in einen Modus verschiebt, den man jederzeit wechseln kann. Wer einen unbekannten Bestand erst verstehen will, bleibt bei plan; wer danach umsetzt, wechselt auf build. Damit ersetzt die Umschalttaste eine Konfigurationsdatei, was den Einstieg deutlich verkürzt.
Der Installationsweg über opencode.ai/install und OPENCODE_INSTALL_DIR
Für die Installation nennt das README eine ganze Reihe von Wegen. Der direkteste führt über ein Skript, das im README mit dem Vermerk YOLO steht:
curl -fsSL https://opencode.ai/install | bash
Wer lieber einen Paketmanager nutzt, findet npm i -g opencode-ai@latest, ergänzt um den Hinweis, dass sich derselbe Weg mit bun, pnpm oder yarn beschreiten lässt. Unter Windows werden scoop install opencode und choco install opencode genannt, unter Arch Linux sudo pacman -S opencode für die stabile Variante und paru -S opencode-bin für den aktuellen Stand aus dem AUR. Dazu kommen mise use -g opencode für beliebige Systeme und nix run nixpkgs#opencode.
Einen Hinweis gibt das README vorab: Versionen älter als 0.1.x sollen vor der Installation entfernt werden.
Interessant ist die Regel für das Zielverzeichnis. Das Skript arbeitet eine Rangfolge ab: Zuerst OPENCODE_INSTALL_DIR, dann XDG_BIN_DIR nach der XDG-Spezifikation, dann $HOME/bin, sofern es existiert oder sich anlegen lässt, und zuletzt als Rückfall $HOME/.opencode/bin. Das README zeigt zwei Beispiele, in denen die Variable dem Aufruf vorangestellt wird, etwa OPENCODE_INSTALL_DIR=/usr/local/bin oder XDG_BIN_DIR=$HOME/.local/bin.
brew tap von anomalyco gegen die offizielle Formula
Bei macOS und Linux stellt das README zwei Homebrew-Wege nebeneinander, und der Unterschied steckt im Kleingedruckten. Der Aufruf brew install anomalyco/tap/opencode bezieht das Paket aus dem eigenen Tap des Projekts und wird im README als empfohlen bezeichnet, weil er immer aktuell sei. Daneben steht brew install opencode für die offizielle Formula, die laut README seltener aktualisiert wird.
Wer also Wert auf den neuesten Stand legt, nimmt das Tap; wer Abhängigkeiten lieber aus dem kuratierten Hauptbestand bezieht, nimmt die Formula und lebt mit Verzögerungen. Diese Wahl ist bei Werkzeugen mit hoher Änderungsfrequenz keine Nebensache, weil sich zwischen zwei Formula-Aktualisierungen etliche Veröffentlichungen ansammeln können.
Eine ähnliche Zweiteilung findet sich bei Arch Linux. Dort steht die stabile Variante aus den Paketquellen neben dem AUR-Paket opencode-bin, das den jeweils letzten Stand liefert. Das README kommentiert diese Unterschiede nicht weiter, die Bezeichnungen Stable und Latest aus dem AUR sprechen aber für sich.
opencode-desktop als Beta: dmg, exe, AppImage und brew install --cask
Neben dem Terminalprogramm gibt es eine Desktopanwendung, die das README ausdrücklich als Beta ausweist. Bezogen werden kann sie über die Releaseseite oder über opencode.ai/download. Die Plattformtabelle im README nennt für macOS zwei Varianten, opencode-desktop-mac-arm64.dmg für Apple Silicon und opencode-desktop-mac-x64.dmg für Intel-Prozessoren. Für Windows heißt die Datei opencode-desktop-windows-x64.exe, für Linux werden deb, rpm und AppImage angeboten.
Auch hier führt der Weg über Paketmanager: brew install --cask opencode-desktop auf der Mac-Seite, und auf Windows die Folge aus scoop bucket add extras und scoop install extras/opencode-desktop. Dass die Oberfläche im Betastadium ist, sollte man bei der Auswahl mitdenken; das README bewirbt sie nicht als gleichwertigen Ersatz für die Kommandozeile, sondern stellt sie daneben.
Für wen sich die Oberfläche lohnt, hängt weniger von den Dateinamen ab als vom Arbeitsplatz. Wer ohnehin in einer Shell arbeitet, braucht sie nicht. Wer den Agenten mehreren Kollegen zugänglich machen will, bekommt mit einem Installationspaket einen Weg, der ohne Kenntnis der Paketmanager auskommt.
@general, die README-Pflicht für Namensvetter und die Community-Kanäle
Ein Abschnitt des README richtet sich nicht an Nutzer, sondern an andere Projekte. Wer ein Vorhaben betreibt, das opencode im Namen trägt, etwa opencode-dashboard oder opencode-mobile, soll in der eigenen README deutlich machen, dass es nicht vom opencode-Team stammt und in keiner Verbindung dazu steht. Solche Hinweise entstehen meist dann, wenn ein Name bekannt genug ist, um Verwechslungen zu erzeugen; bei über 200.000 Sternen ist das plausibel.
Für Beiträge verweist das Projekt auf eine eigene Datei CONTRIBUTING.md, die vor einem Pull Request gelesen werden soll. Die Konfiguration selbst wird im README nicht im Detail beschrieben, sondern an die Dokumentation unter opencode.ai/docs weitergereicht. Als Anlaufstellen für Fragen nennt das README einen Discord-Server unter discord.gg/opencode sowie ein Konto auf X.com. Eine Aussage zu Supportzusagen oder Reaktionszeiten findet sich dort nicht, was bei einem Projekt dieser Größe zusammen mit 5.684 offenen Issues nüchtern eingeordnet werden sollte.
v1.18.23 bis v1.18.25 in drei Tagen: Was der Release-Takt bedeutet
Die jüngsten Veröffentlichungen liegen dicht beieinander. v1.18.23 erschien am 25. August 2026, v1.18.24 am 28. August um kurz nach vier Uhr, v1.18.25 am selben Tag knapp zwei Stunden später. Der letzte Push auf das Repository fällt auf den Zeitpunkt der Ausgabe v1.18.25. Zwischen der ersten und der zweiten dieser Veröffentlichungen liegen drei Tage, zwischen der zweiten und dritten nicht einmal zwei Stunden.
Für den Einsatz folgt daraus eine klare Konsequenz. Wer einen festen Stand braucht, sollte eine Versionsnummer festhalten und nicht blind die jeweils letzte Ausgabe nehmen, weil sich Verhalten in so kurzen Abständen ändern kann. Genau an dieser Stelle gewinnt auch die Wahl des Installationswegs an Gewicht: Das Tap von anomalyco liefert den neuesten Stand unmittelbar, während die offizielle Formula laut README seltener aktualisiert wird und damit unbeabsichtigt als Bremse wirkt.
Eine Grenze bleibt unabhängig davon bestehen: Der Agent build besitzt vollen Zugriff für Entwicklungsarbeit. Wer in einem Bestand mit sensiblen Daten arbeitet, sollte den lesenden Modus plan als Voreinstellung betrachten und die Umschaltung bewusst einsetzen. Das README beschreibt die Rechte beider Modi, enthält aber keine Aussage über Protokollierung oder Nachvollziehbarkeit ausgeführter Befehle über die Shell hinaus.
Redaktionelles Fazit
Geeignet ist opencode für Entwickler, die einen Agenten im Terminal wollen, der Repositories einlesen, Dateien ändern und Befehle ausführen kann, und die zwischen einem vollen Zugriff und einer rein lesenden Arbeitsweise wechseln möchten. Weniger geeignet ist es für Umgebungen, in denen eine Beta-Oberfläche oder ein Agent mit Schreibrechten grundsätzlich ausscheidet, und für alle, die einen geregelten Veröffentlichungsrhythmus brauchen. Vor der Nutzung sollte geprüft werden, ob alte Versionen unterhalb 0.1.x restlos entfernt sind, in welchem Verzeichnis das Installationsskript landet, also OPENCODE_INSTALL_DIR, XDG_BIN_DIR, $HOME/bin oder $HOME/.opencode/bin, und ob der Wechsel zwischen build und plan mit der Tab-Taste auf der eigenen Tastaturbelegung funktioniert.
Community-Notizen