Die lästigen und beunruhigenden Probleme von OpenCode

 (wren.wtf)
5 Punkte von GN⁺ 16 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Test des Open-Source-KI-Coding-Agenten OpenCode, der 161.000 GitHub-Stars hat, mit lokalem Qwen3.6-27B ergab, dass sowohl Tool-Qualität als auch Sicherheitsdesign auf einem Niveau waren, bei dem man die Nutzung einstellen sollte
  • Das erneute Laden von AGENTS.md, kontextuelles Pruning mit fester Distanz, das Einfügen des aktuellen Datums und Moduswechsel invalidieren wiederholt den Prompt-Cache, sodass es selbst auf einem M4 Max bis zu 10 Minuten dauern kann, bis die Antwortgenerierung beginnt
  • Session-Compaction, System-Prompts, Berechtigungsprüfungen, Steuerung von Sub-Agenten und TUI greifen nicht sauber ineinander, wodurch Kontext und Nachrichten verloren gehen können und Code geschrieben wird, obwohl wichtige Spezifikationen vergessen wurden
  • Der auf Bash-AST und String-Mustern basierende Berechtigungsfilter kann indirekte Ausführung, absolute Pfade, Variablen, Python, Redirects usw. nicht verhindern; auch Einschränkungen für externe Dateizugriffe und dauerhafte Berechtigungen lassen sich leicht umgehen
  • Angesichts der standardmäßigen Verbindung zu Remote-Modellen, unbegrenztem Internetzugriff und früheren RCE-Schwachstellen im HTTP-Server reicht Docker allein nicht aus; nötig sind das Blockieren ausführbarer Dateien, schreibgeschützte Pfade und Isolation auf Betriebssystemebene

Bewertungsumfang und Annahmen

  • OpenCode ist ein Projekt, das der Hersteller als KI-Coding-Agent beschreibt; zum Zeitpunkt der Prüfung hatte es 161.000 GitHub-Stars
  • Getestet wurde auf Basis des lokalen LLM Qwen3.6-27B und der OpenCode-Git-Version baef5cd4
  • Es handelt sich weniger um eine separate Sicherheitsveröffentlichung, sondern um eine Betrachtung, wie die Pipeline-Schicht in einer Architektur versagt, die LLM-Ausgaben an Bash weiterreicht
  • Die Nutzung von LLMs an sich und die Frage, ob die Maschine des Nutzers leicht kompromittiert oder gelöscht werden kann, werden als getrennte Themen behandelt

Eine Struktur, die den Prompt-Cache wiederholt zerstört

  • APIs der OpenAI-/v1/chat/completions-Familie senden die gesamte bisherige Konversation als JSON und antworten mit einem SSE-Delta-Stream, der JSON-Metadaten enthält
    • Je länger die Session wird, desto stärker steigen die Upload-Kosten quadratisch
    • Tool-Aufrufe verwenden eine doppelte Kodierung, bei der mehrere JSON-Deltas wieder zu JSON zusammengesetzt werden
  • Der Server ist zustandslos aufgebaut, cached aber Bewertungsergebnisse aus Performance-Gründen
    • Er sucht das längste Cache-Präfix, das zur Anfrage passt
    • Ab dem Ende des Präfixes bis zur letzten Nachricht wird ein Prefill durchgeführt
    • Danach werden neue Tokens bis zum End-Token generiert
  • Auf einem M4 Max mit rund 0,5 TB/s Speicherbandbreite war die Token-Generierung von Qwen3.6-27B brauchbar, doch der Prefill langer Kontexte war rechnerisch sehr teuer
    • Wenn kein passender Prefix-Cache gefunden wird, kann es passieren, dass die GPU voll ausgelastet ist und man etwa 10 Minuten wartet, bevor die Antwortgenerierung überhaupt beginnt
  • OpenCode globbt bei jedem SSE-Turn das Dateisystem und liest AGENTS.md, das in den ersten System-Prompt eingefügt wird, erneut
    • Selbst wenn man AGENTS.md für die nächste Session ändert, wird die gesamte aktuelle Session neu evaluiert
  • Beim Wechsel vom Agenten zum Nutzer wird der Kontext von Tool-Aufrufen gepruned, wodurch große Cache-Bereiche invalidiert werden
    • Tool-Ergebnisse, die älter als PRUNE_PROTECT = 40_000 sind, werden verworfen; selbst im besten Fall entsteht dadurch ein Cache-Miss von 40.000 Tokens
    • Auch ein Abbruch wird als Nutzerwechsel behandelt; wenn man einen falschen Verlauf korrigiert, wird der Cache verworfen und man muss erneut warten
  • Da der erste System-Prompt das aktuelle Datum enthält und bei jedem SSE-Turn neu evaluiert wird, führt ein Datumswechsel um Mitternacht zu einem vollständigen Cache-Miss

Pruning und Session-Compaction

  • Pruning wird auf alle Tool-Ergebnisse außer skill gleich angewendet und schützt früh gelesene wichtige Materialien nicht gesondert
    • In einer neuen Session wird zuerst die Spezifikation gelesen
    • Beim Lesen weiteren relevanten Codes wird die Schwelle von 40.000 Tokens überschritten
    • Das Modell verliert sich in unnötigem Reasoning oder in der falschen Richtung, und der Nutzer bricht ab
    • Durch den Abbruch wird die Spezifikation aus dem Kontext gelöscht
    • Das Modell implementiert, ohne auf die ursprüngliche Spezifikation zugreifen zu können
  • Session-Compaction hängt einen neuen Prompt an den Anfang der bestehenden Session, führt für alles erneut einen Prefill aus und fasst dann in einigen Bulletpoints zusammen
    • Würde man den Zusammenfassungs-Prompt ans Ende der Session setzen, ließe sich der vollständige Prefill vermeiden
    • Besser funktionierte der Ansatz, das Modell selbst eine Übergabenotiz in eine Datei schreiben zu lassen; das Ergebnis konnte zudem bearbeitet oder in mehreren Sessions wiederverwendet werden
  • Compaction ist eine undichte Abstraktion, die ein endliches Kontextfenster unendlich wirken lässt; zusammen mit Pruning werden die Probleme größer
  • Besser wäre es, Kontextfenster und Prompt-Cache als grundlegende Einschränkungen anzuerkennen und Verwaltungsmechanismen bereitzustellen; Pis Session-Tree nutzt den Prompt-Cache gezielt

System-Prompt und Plan-Modus

  • Der Standard-System-Prompt ist sehr lang, und ein erheblicher Teil wird darauf verwendet, das Modell zu knappen Antworten anzuweisen
  • Er enthält auch starke Coding-Präferenzen, etwa indem Sub-Agenten angewiesen werden sollen, ABSOLUTELY NO COMMENTS zu verwenden
  • Der Übergang von Plan zu Build ist nicht reibungslos; wenn man den Plan ausreichend konkretisiert, kann man nahe ans Ende des Kontextfensters geraten
    • Bevorzugt wird, die Diskussionsergebnisse in eine Datei zu schreiben, sie zu bearbeiten und anschließend in eine neue Session zu übergeben
  • Der Hinweis im Plan-Modus sagt, man könne in kein Verzeichnis schreiben, tatsächlich kann aber nach .opencode/plans geschrieben werden
    • Es traten beide Fehlerarten auf: Es wurde ohne Anweisung in dieses Verzeichnis geschrieben, oder trotz expliziter Aufforderung wurde das Schreiben verweigert
  • Der Standard-System-Prompt lässt sich nicht global ändern und muss daher pro Projekt kopiert werden
  • Wenn nur der Prompt des Build-Modus neu definiert wird, führt der Wechsel in den Plan-Modus zu einem vollständigen Prompt-Cache-Miss
  • Modellspezifische Prompts unterscheiden sich stark in Inhalt und Qualität
    • Beast Mode für GPT-4, o1 und o3 weist an, dass eine Google-Verifikation zwingend notwendig sei, um Third-Party-Packages und Abhängigkeiten zu verstehen

Entscheidungserschöpfung durch Berechtigungsprüfungen

  • Wenn Zugriffe auf Dateien außerhalb des Projekts per provisorischer String-Analyse erkannt werden, erscheint ein Berechtigungsdialog mit Yes, No, Always, und die Ausführung pausiert bis zur Antwort
    • Eine Option Never, um dieselbe Aktion künftig immer abzulehnen, gibt es nicht
  • Wenn ein Sub-Agent die Ausgabe eines Skripts in /tmp lesen will und man No auswählt, endet der Agent und auch der Aufgabenkontext verschwindet
    • Um den Fortschritt zu bewahren, kann eine Situation entstehen, in der man selbst unerwünschten externen Zugriff mit Yes erlauben muss
  • Wenn Erlaubnisanfragen wiederholt auftauchen und Yes die einzige produktivitätserhaltende Wahl ist, können Nutzer auch riskante Anfragen genehmigen
  • Ein grundlegender Schutz gegen Schreibzugriffe außerhalb des Verzeichnisses darf nicht von dauerhafter menschlicher Aufmerksamkeit abhängen

Nachrichten und Interaktion mit Sub-Agenten

  • Während des SSE-Streamings gesendete Nachrichten landen in einer Warteschlange, aber der tatsächliche Sendezeitpunkt ist unklar
    • Der Code scheint sie am Ende eines Tool-Call-Turns zu senden, es wurde aber auch erlebt, dass vom Tool in den Denkprozess gewechselt wurde, ohne die wartende Nachricht zu senden
    • Bricht der Nutzer ab, fällt die Nachricht aus dem Wartezustand heraus, bleibt nur im Log und kann nicht mehr gesendet werden; es braucht dann eine zweite Nachricht, um einen neuen Stream zu starten
  • In manchen Fällen entfernt Undo für Nachrichten die betreffende Nachricht nicht aus dem Log
  • Mit Sub-Agenten kann man nicht direkt sprechen oder ihren Fortschritt stoppen
    • Wenn sie in die falsche Richtung laufen, muss man sie beenden und Kontext verlieren oder den Token-Verbrauch beobachten
    • Früher scheint es diese Funktion gegeben zu haben, inzwischen ist sie verschwunden
    • Sub-Agenten per @mention im normalen Chat anzusprechen funktioniert nicht sinnvoll, und auch ein Abbruch ist nicht möglich
  • Wenn ein Tool-Aufruf eines Sub-Agenten fehlschlägt, etwa weil Qwen Tool-Aufrufe in den Denkprozess setzt, tritt ein fataler Fehler auf, und der bis dahin aufgebaute Kontext verschwindet
  • Die Wiederverwendung von Sub-Agenten kollidiert mit dem Ziel, Aufgaben in kleine Kontexte aufzuteilen
    • Bestehende Sub-Agenten können für nicht zusammenhängende Aufgaben wiederverwendet werden
    • Zwischen Haupt-Agent mit großem Kontext und Sub-Agenten wird hin- und hergewechselt, was Cache-Misses verursacht
    • Die Interaktion für Menschen darf reichhaltig sein, aber die dem Modell angebotenen Optionen sollten reduziert werden
  • Es gibt auch ein GitHub-Issue zum Verhalten von Sub-Agenten

Design der Agenten-Tools

  • edit führt standardmäßig eine exakte Suche und Ersetzung des eindeutig passenden Texts durch
    • Das passt gut, weil Modelle sich Dateiinhalte genau merken können, nach mehreren Bearbeitungen aber geänderte Zeilennummern übersehen
    • Die Option für globale Ersetzung führte zu mehreren Nachbesserungen; entfernt man sie, entspricht das Pis edit-Design
  • Das Multiple-Choice-Tool question im Plan-Modus ist unbequemer, als das Modell im System-Prompt zu Fragen in natürlicher Sprache anzuweisen
  • grep und glob lassen sich durch bash ersetzen, und tatsächlich führt das Modell auch grep oder rg in Bash aus
    • Möglicherweise soll damit verhindert werden, dass Read-only-Agenten wie Explore Bash verwenden
    • Das hängt mit dem Problem zusammen, dass Nebenwirkungen schwer zu bestimmen sind, ohne Bash-Befehle auszuführen
  • todo ist im Allgemeinen nützlich, aber das Modell vergisst selbst, TODOs zu prüfen

TUI und Dokumentationsqualität

  • Die OpenCode-TUI verwendet etwa 1 GB RAM für das Text-Rendering
  • In der Nachrichteneingabe funktionierte der Zeilenumbruch mit Shift+Enter nicht; ein bestehendes Issue wurde nach der Antwort „funktioniert auf meinem Rechner“ geschlossen
  • Wenn lange Nachrichten automatisch umbrechen, bewegen sich Eingabefeld und Cursor, aber Zeichen in der neuen Zeile können unsichtbar bleiben
  • Wenn man während des Streamings Text auswählt, hebt das automatische Scrollen die Auswahl wieder auf
  • Ctrl-C schließt die Session sofort, statt den laufenden Befehl abzubrechen
    • Nach Konvention interaktiver Shells sollte Ctrl-C den Befehl abbrechen, und Ctrl-D sollte die Session beenden, wenn kein Befehl läuft
  • Gängige Shortcuts zur wortweisen Bewegung, etwa Option+Pfeil links/rechts auf dem Mac, werden nicht unterstützt
  • Wenn Nachrichten oder Denkprozesse lang werden, dauert Markdown-Neurendering usw. mehrere Sekunden; es gibt Performance-Probleme, die nach quadratischer Zeitkomplexität aussehen
  • Wegen der Eingabeprobleme mussten Nachrichten in einem externen Editor verfasst und hineinkopiert werden
  • Die Dokumentation ist inkonsistent und wirkt eher so, als sei sie fürs Lesen durch Modelle statt durch Menschen geschrieben

Remote-first-Verbindung und Datenexposition

  • OpenCode verbindet sich standardmäßig mit Remote-Modellen
  • In der Dokumentation gibt es kein einfaches Beispiel für die Konfiguration eines lokalen Modells; bei falscher Konfiguration wird eine Verbindung zu einem Remote-Modell hergestellt
  • Selbst wenn ein lokales Modell korrekt angegeben ist, muss es nach Programmstart interaktiv ausgewählt werden; währenddessen sind Remote-Modell und lokale Shell bereits verbunden
  • Die Standard-Modell-URL ist nicht in der Distribution fixiert, sondern wird von dem mit OpenCode verbundenen models.dev heruntergeladen
    • Der entsprechende Code befindet sich in opencode/src/provider/provider.ts, Zeile 1684
  • Nach einer frischen Installation kann allein das Ausführen von opencode, die Eingabe eines einzigen Zeichens und Enter dazu führen, dass ohne Nutzereinstellung ein Remote-Modell mit der lokalen Shell verbunden wird
  • Wenn die erste Nachricht leer oder mehrdeutig ist, globbt das Agentenmodell häufig das aktuelle Verzeichnis und liest Dateien; die gelesenen Daten sind dann im nächsten POST-Request enthalten

Internetzugriff und System-Prompt

  • OpenCode bietet das Tool WebFetch und weist im System-Prompt ausdrücklich an, es zu verwenden
  • Der Standard-Prompt erlaubt es, URLs aus vom Nutzer bereitgestellten Nachrichten oder lokalen Dateien zu verwenden, und lässt vage zu, URLs zu erzeugen oder zu erraten, wenn man sicher ist, dass es sich um URLs zur Programmierunterstützung handelt
  • Da Bash keine Netzwerk-Sandbox hat, ist das größere Problem gegenüber WebFetch eine Struktur, die darauf vertraut, dass das Modell keine Befehle wie curl | bash ausführt

Wege, den Bash-Berechtigungsfilter zu umgehen

  • "bash": {"git *": "deny"} in opencode.json blockiert git status oder echo hello && git push --force
  • Die Implementierung parst Befehle mit den Bash- und PowerShell-Grammatiken von tree-sitter als AST und durchläuft Befehls-Nodes, um sie mit regulären Ausdrücken aus der Konfiguration zu vergleichen
  • Textbasierte Prüfungen erlauben jedoch vielfältige indirekte Ausführung
    • echo 'git clean -fdx .' | bash
    • env git status
    • git per Alias mit einem anderen Befehlsnamen verknüpfen
    • /usr/bin/git status, $(which git) status
    • GIT=git && $GIT status
    • Base64-kodiertes git reset --hard dekodieren und an Bash weiterreichen
    • git push --force in einem heredoc
    • git checkout . per Python subprocess.run ausführen
  • Selbst wenn das Modell normalerweise nicht bösartig ist, wurde es darauf trainiert, Fehler hartnäckig zu umgehen, und kann sich daher natürlich wie adversarial Input verhalten
  • String-basierte Befehlsfilter sind keine Schutzmaßnahme, sondern vermitteln ein falsches Sicherheitsgefühl

Dauerhafte Berechtigungen und CWD-Ausnahmen

  • Wenn man bei python3 -c 'print("hello")' Always auswählt, wird das gesamte Präfix python3 dauerhaft erlaubt
    • Danach können auch Befehle, die per Python private SSH-Schlüssel lesen, als bereits genehmigt behandelt werden
    • Berechtigungen werden auf der Festplatte gespeichert und bleiben für spätere Sessions bestehen
  • cd, chdir, popd, pushd, push-location, set-location stehen auf einer CWD-Ausnahmeliste, die davon ausgeht, dass sie keine Nebenwirkungen haben
  • Diese Befehle umgehen Berechtigungsprüfungen ausdrücklich, selbst wenn konfiguriert ist, alle Bash-Befehle abzulehnen

Schwachstellen der Dateizugriffsprüfung

  • Die Standardeinstellung versucht, Dateizugriffe außerhalb des Verzeichnisses, in dem OpenCode gestartet wurde, und außerhalb des jeweils kürzeren Pfads des Git-Repositorys zu verhindern
  • Im Bash-Tool wird der tree-sitter-AST durchlaufen, um Werte zu interpretieren und zu prüfen, die wie Pfade aussehen
    • cat /tmp/logfile verlangt eine Berechtigung
    • python3 -c 'import shutil; shutil.rmtree("/")' kann nicht geprüft werden
  • cargo kann in globalem ~/.cargo frei lesen, schreiben und ausführen; wenn das Modell jedoch direkt Paketquellen in ~/.cargo/registry/src lesen will, wird eine Berechtigung verlangt
  • Befehle, von denen angenommen wird, dass sie auf Dateien zugreifen können, sind auf eine feste FILES-Liste beschränkt
    • Enthalten sind rm, cp, mv, mkdir, touch, chmod, chown, cat sowie einige PowerShell-Befehle
    • Befehle, die nicht auf der Liste stehen, gelten als nicht dateizugreifend, daher werden übergebene Pfade ebenfalls nicht geprüft

Kombination aus Redirects und erlaubten Befehlen

  • Wenn man bei echo "hello world!" Always auswählt, sind danach auch Datei- und Geräteschreibvorgänge per echo erlaubt
    • Auch Befehle, die auf GPIO-bezogene Pfade unter /sys/class/gpio redirecten, können ausgeführt werden
  • Im AST von echo foo > bar.txt ist redirection kein Kind von command, sondern ein Geschwister-Node
    • Die Pfadprüfung betrachtet nur Kinder von command, daher wird das Redirect-Ziel nicht geprüft
    • Auch echo selbst steht nicht in der FILES-Liste, sodass die Pfadvalidierung gar nicht beginnt

Self-Upgrade und Fälle von Remote Code Execution

  • OpenCode hat mehrere Self-Upgrade-Pfade; wenn bei der curl-basierten Installation opencode upgrade ausgeführt wird, lädt es die Antwort von https://opencode.ai/install herunter und führt sie über Bash-Standardeingabe aus
  • Das unterscheidet sich im Risiko nicht wesentlich vom Zeitpunkt, an dem man den curl-Installer verwendet, ist aber ein Beispiel dafür, dass ein Remote-Skript in Produktion direkt ausgeführt wird
  • Zum Zeitpunkt von CVE-2026-22812 stellte OpenCode im standardmäßigen HTTP-Server folgende Funktionen bereit
    • Vollständig permissive CORS-Header
    • Eine POST-API zum Ausführen beliebiger Shell-Befehle
    • Eine GET-API zum Lesen beliebiger Dateien
  • Eine vom Nutzer besuchte Website konnte Anfragen an den bekannten Standard-Port senden und so Systemzugriff auf Ebene der Nutzerrechte erhalten
  • Das Entwicklungsteam deaktivierte den Server standardmäßig, antwortete, dass eine CORS-Ausnahme nötig sei, damit opencode.ai auf der Maschine Remote-Code ausführen könne, verfolgte die Sache anschließend nicht weiter, und das Issue wurde vom stale bot geschlossen
  • Ein separates Issue berichtete, dass ein Authentifizierungsbefehl Inhalte von einer vom Nutzer übergebenen beliebigen URL abruft und ausführt; auch dieses wurde vom stale bot geschlossen

Warum Docker allein das Problem nicht löst

  • Es ist nicht wünschenswert, Entwicklungsabhängigkeiten so komplex zu machen, dass sie auf einer neuen Maschine schwer zu installieren sind, und sich dann auf Docker zu verlassen
  • Docker selbst kann Sicherheitsprobleme schaffen
    • Es erzeugt einen mächtigen Dienst, der als root läuft
    • Es öffnet absichtlich einen Durchgang durch die ufw-Firewall
  • Wenn alle zu schützenden Daten im Container liegen und die lokale Shell darin mit dem Internet verbunden ist, ist der Schutzumfang unklar
  • Wenn das Ziel darin besteht, rekursives Löschen des Root-Dateisystems zu verhindern, können direktere Betriebssystemmechanismen wie Landlock, Seatbelt, Restricted Tokens verwendet werden
  • Sicherheit von Coding-Agenten sollte keine Aufgabe sein, die an einen separaten Container delegiert wird, sondern höchste Priorität des Harness sein
    • Git-Blockierung sollte nicht den Befehls-String, sondern die ausführbare Datei git selbst blockieren
    • Das Verzeichnis .git sollte schreibgeschützt gemacht werden
    • Statt Bash-Befehle textuell zu bereinigen, sollte native Betriebssystem-Isolation genutzt werden

Nutzungserfahrung mit lokalen LLMs

  • Auch lokale Modelle wie Qwen3.6-27B können wie Frontier-Modelle die Stabilität und konzeptuelle Konsistenz einer Codebasis beschädigen, doch es gibt drei Unterschiede
    • Das Uncanny Valley, in dem sie intelligent wirken und dann dumm handeln, ist weniger ausgeprägt; die Grenzen sind klarer, sodass sich die Interaktion leichter anpassen lässt
    • Die Zahl der Gewichte ist zu klein, um Trainingsdaten direkt zu reproduzieren, was die Bewertung möglicher Output-Kontamination verändert
    • Man muss keinen Cloud-Anbieter unterstützen oder von ihm abhängen
  • Nützliche Ergebnisse gab es bei inputzentrierten Suchaufgaben, bei denen Code, Symptome und vermutete Ursachen angegeben, relevanter Code gelesen und dann Aufrufpfade und Codezitate verlangt wurden
    • Wenn man die Aufgabe als Suchproblem eingrenzt, lässt sich die Tendenz des Modells reduzieren, Fakten zu erfinden
  • Bei Codegenerierung wurde die Architekturplanung wiederholt untergraben
    • Es nahm Abkürzungen, etwa indem es mitten im Design mutable State so verschob, dass mehrere Komponenten ihn teilen
    • Das Problem geht darüber hinaus, den Code nicht selbst geschrieben zu haben; es schadet der Fähigkeit, den Code zu verstehen
  • Antworten direkt aus dem Wissen der Modellgewichte abzurufen, führt selbst bei Modellen mit Billionen Parametern zu Halluzinationen
  • Damit LLMs zu normalen Werkzeugen werden, muss auf die umgebende Software echte System-Engineering-Arbeit angewendet werden, um Sicherheitslücken zu schließen; diese Arbeit müssen Menschen erledigen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 16 시간 전
Hacker-News-Meinungen

  • Ein besserer Titel für diesen Beitrag wäre wohl eher „Kleine Unannehmlichkeiten, deren Behebung OpenCode verbessern würde“
    Dass AGENTS.md jedes Mal neu gelesen wird oder durch Datumsänderungen Prompt-Cache-Misses entstehen, ist hinnehmbar.
    Probleme damit, dass Komprimierung und Pruning nicht richtig funktionieren, habe ich auch bei Codex und Claude gesehen, und der standardmäßige System-Prompt dient der Konsistenz; wenn er einem nicht gefällt, kann man ihn ändern.

    • Inzwischen ist die Codebase durch Features, die per Vibe Coding hinzugefügt wurden, stark aufgebläht und zeigt genau dieselben Probleme wie Claude Code.
      Auch Stabilität, Performance und Speicherverbrauch haben sich allesamt verschlechtert. Früher mochte ich OpenCode, aber als gut geschriebene Software kann man es schwerlich bezeichnen.
      Ich habe es inzwischen vollständig durch Pi ersetzt, und es gibt mittlerweile einige neue Optionen, die aus OpenCode gelernt haben und dort, wo es nötig ist, ein zurückhaltenderes Design einsetzen.
    • Ich arbeite an OpenCode.
      Wir machen inzwischen kein Pruning von Tool-Aufrufen mehr, aber wenn man innerhalb eines begrenzten Kontextfensters länger an derselben Aufgabe weiterarbeiten will, muss der aktuelle Stand zusammengefasst werden; Komprimierung bleibt daher vorerst ein notwendiges Übel.
      In der derzeitigen Beta von V2 gibt es einen neuen Ansatz, der sich ändernde Systemanweisungen wie AGENTS.md und verfügbare Technologien aktuell hält und zugleich Cache-Misses so weit wie möglich vermeidet.
      https://x.com/kitlangton/status/2075749116760457346/video/1
    • Diese Punkte sind als „Annoying Things“ eingeordnet, also sollte man auch „Alarming Things“ lesen.
    • Das, was hier behandelt wurde, sind Punkte aus dem Abschnitt „Annoying Things“ des Beitrags.
      In einem separaten Abschnitt „Alarming Things“ gibt es auch einen Unterabschnitt namens „It’s Fucking Full of RCEs“, und zusätzlich zu den Problemen, die sich aus dem vorherigen Abschnitt ergeben, existieren mehrere Schwachstellen für Remote Code Execution.
    • Deshalb hat OpenCode also zufällig Kommentare aus meinem Code gelöscht.

  • Die Risiken agentischer CLIs sind gut zusammengefasst, aber der Titel mit Fokus nur auf OpenCode wirkt aus zwei Gründen seltsam.
    Erstens wird keine klare Alternative vorgeschlagen. Viele Probleme sind grundlegend, sodass man womöglich fast von Anfang an neu entwerfen und neu schreiben müsste; einfach nur Änderungsvorschläge für OpenCode zu machen, wäre daher auch nicht ausreichend. Aber weil es keinerlei konstruktive Vorschläge gibt, liest es sich praktisch wie ein Text mit der Aussage „Hört auf, LLMs zu benutzen“.
    Zweitens sind die Hauptprobleme unter „Alarming Things“ nicht spezifisch für OpenCode, sondern gelten auch für die Claude CLI und vermutlich für Agenten anderer Anbieter modernster Modelle.
    Trotzdem ist der Beitrag als Dokument, das dazu auffordert, bessere Tools von Grund auf zu bauen, sehr wertvoll; ich werde ihn bookmarken und breit teilen. Gerade weil der Text inhaltlich so stark ist, wirken Titel und Fokus umso verfehlter.

    • Mich würde interessieren, wie man glaubt, Shell-Zugriff erlauben und gleichzeitig beliebige Befehlsausführung sicher verhindern zu können.
      Besonders die Beschwerde, dass echo git | bash weiterhin ausgeführt wird, wirkt absurd.

  • Der Satz „Wenn du OpenCode nicht kennst, stell dir einen Stiefel vor, der für immer auf ein menschliches Gesicht tritt. Der Stiefel ist aus TypeScript gemacht, und das Gesicht ist alles, was wir seit der Erfindung elektronischer Computer in den 1940ern über Sicherheit und Systemsoftware gelernt haben“ ist ein Kandidat für den Bulwer-Lytton-Preis in der Kategorie erzwungene Metaphern.

    • Diese Metapher stammt aus George Orwells 1984: „Wenn du ein Bild von der Zukunft willst, stell dir einen Stiefel vor, der für immer auf ein menschliches Gesicht tritt.“

  • Der Stil des Beitrags ist übermäßig wütend und hart.
    Den meisten Punkten stimme ich grundsätzlich zu, aber ab der Stelle, an der OpenCode als „Clown-Car-Turbo-Müll mit einer Security Posture auf dem Niveau von ‚Papa, ich beuge mich für dich runter‘“ bezeichnet wird und alle aufgefordert werden, es nicht mehr zu benutzen, vergeht mir die Lust am Weiterlesen.
    Auch diese Software wurde von ganz normalen Menschen gebaut. Ich weiß nicht, seit wann es selbstverständlich geworden ist, Open Source auf diese Weise anzugreifen, und ich frage mich, wie es sich anfühlen würde, wenn meine Software so bewertet würde.

    • Diesem Gefühl stimme ich zu, aber diese Kultur gibt es mindestens seit den 1990er-Jahren.
      Schon früher auf comp.lang.lisp gab es Leute, die Freude daran hatten, andere herabzusetzen, deren Code nicht den Elfenbeinturm-Maßstäben entsprach; manche gingen, andere hielten es irrtümlich für die nötige Zurechtweisung zur Verbesserung ihrer Fähigkeiten und trugen es wie eine Auszeichnung.
      Eine alte HN-Diskussion dazu: https://news.ycombinator.com/item?id=587045
    • Heutzutage wird etwas als „vibe-coded“ zu bezeichnen wie eine Erlaubnis benutzt, Übertreibungen und Beleidigungen loszulassen, in der Annahme, dass niemand persönlich angegriffen werde.
      Offenbar versteht man nicht, wie schädlich diese Rhetorik für Entwickler ist, die als Kollateralschaden getroffen werden, und auch für die Personen selbst, die ein solches Verhalten normalisieren.
    • Die Stelle „Jemand, der die Interna von OpenCode gut kennt — ich gehe davon aus, dass das OpenCode-Entwicklungsteam nicht dazugehört — könnte gegen das obige python3-Beispiel Einwände erhoben haben“ fand ich lustig.
    • Selbst wenn man zu OpenCode beigetragen hat, hätte man mit etwas Sinn für Humor darüber gelacht; man muss also nicht alles so ernst nehmen.
    • Es ist auch heute keine normale Ausdrucksweise, aber neu ist sie nicht; solche Sprache gibt es schon lange.

  • Wegen des Tech-Stacks eines Kunden nutze ich Claude Code und für private Arbeiten eine bestimmte Version von OpenCode; OpenCode war deutlich besser, deshalb macht mich dieser Beitrag traurig.
    Die merkwürdigen Phänomene, die ich bisher gesehen und ignoriert hatte, passen alle zu dem Beitrag, und sogar die Ursachen werden erklärt. Abgesehen von den übertriebenen Formulierungen und den Teilen, denen ich emotional nicht zustimme, ist das im Großen und Ganzen zutreffend, also sollte ich mich wohl nach einem anderen Ausführungstool umsehen.
    Ich hätte gern Empfehlungen, ob Pis Architektur tatsächlich besser ist oder ob es noch bessere Alternativen gibt.

  • Unabhängig von den Mängeln war ich unter den verschiedenen Tools, die ich ausprobiert habe, mit OpenCode am produktivsten.
    Das meiste im Beitrag sind kleine Unannehmlichkeiten oder Meinungsunterschiede, und insbesondere der Zweck des Command-Filterings wird grundlegend missverstanden. Das ist kein Sicherheitsmechanismus, sondern ein Mittel, um das Verhalten des Modells zu lenken.
    Der Autor scheint mit OpenCode nie wirklich etwas gebaut zu haben; hätte er es genutzt, hätte er die wichtigste Frage, nämlich die Qualität der Ergebnisse, überhaupt nicht ausgelassen.

    • Ich finde ebenfalls, dass OpenCode eine gute Balance hat: Es steht nicht im Weg und macht trotzdem den Computer nicht kaputt.
      Besonders der Planungsmodus lässt sich leicht nutzen, um Aufgaben schnell zu erledigen.

  • Nach dem Wechsel in OpenCode zu Pi ist die Performance von Tool-Aufrufen deutlich besser geworden, und es fühlt sich auch weniger fehlerhaft an
    OpenCode scheint auch von https://openrouter.ai/apps/category/coding verschwunden zu sein

    • OpenCode hat darum gebeten, aus dem OpenRouter-Ranking entfernt zu werden: https://github.com/anomalyco/opencode/issues/11926#issuecomm...
    • Das liegt weniger daran, dass OpenCode schlecht ist, sondern daran, dass Pi gut ist. Dasselbe könnte man auch beim Vergleich von Claude und Pi sagen
    • Einer der Vorteile von OpenCode ist die LSP-Integration; ich frage mich, wie Pi damit umgeht
    • Ich habe kürzlich OpenCode und Pi ausprobiert, und aus Sicht eines Umsteigers von Claude Code war ich überrascht, dass beide standardmäßig Bearbeitungen ohne Bestätigungsdialog zu erlauben scheinen
      Soweit ich mich erinnere, kann man bei einem die Bestätigung in den Einstellungen aktivieren, beim anderen braucht man ein Plugin
    • Nachdem ich gesehen hatte, dass OpenCode im Hintergrund npm-Pakete herunterlädt, ohne den Nutzer zu fragen, habe ich es komplett gelöscht
      Dieses Verhalten erhöht das Risiko von Supply-Chain-Angriffen weiter

  • Dass eine TUI-Desktop-App, die lediglich Text anzeigt, schwergewichtiger ist als native Apps und sogar als die meisten browserbasierten Desktop-Apps, ist absurd und verschwendet RAM, CPU, Energie und Akku
    Ich entwickle gerade mit C++ Qt6 ein eigenes AI-Ausführungstool samt Chat-App; es hat Sub-Agents, Code-Diffs, Terminal-Emulator, einfachen Editor, Markdown-Vorschau, halbtransparenten Hintergrund, Nutzer-Themes, Berechtigungen, MCP, Git-Integration, Docking-System und Projekt-Tabs und ist trotzdem leichter als andere Tools
    Ich habe es noch nicht veröffentlicht, weil ich noch ein paar Bugs beseitige, die UI vereinfache und es poliere: https://zeteo.krysoph.com/preview.html

  • Mir ist erst jetzt klar geworden, dass OpenCode Kommentare wegen der Vorgabe „Use ABSOLUTELY NO COMMENTS“ im Standard-System-Prompt gelöscht hat, und das ist extrem ärgerlich
    Allerdings ist das Sicherheitsrisiko, nicht nur eine kleine Unannehmlichkeit, auch bei anderen Ausführungstools gegeben. Diese Tools haben Zugriff auf riesige Datenmengen, werden fast täglich aktualisiert, und wegen ihres vibe-coded Charakters ist es sehr wahrscheinlich, dass niemand die zahlreichen npm-Abhängigkeiten, die sie mitbringen, ordentlich auditiert
    Schon ein einziger Vorfall wie bei left-pad könnte für die gesamte Supply Chain katastrophal werden

  • Das Datum in den System-Prompt aufzunehmen, sodass der Cache um Mitternacht ungültig wird, ist eine vernünftige Entscheidung, und die meisten anderen Ausführungstools machen es genauso
    Würden vollständiges Datum und Uhrzeit eingefügt, wäre das unverantwortlich, aber OpenCode tut das nicht

    • Als ich es um Mitternacht nutzte und 10 Minuten warten musste, bis der KV-Cache der lokalen GPU wieder gefüllt war, fühlte sich das nicht vernünftig an
      Das ließe sich einfach lösen, indem das Datum einmal pro Sitzung ausgewertet wird oder nur einmal bei jedem Start des opencode-Binaries, um zu verhindern, dass lange laufende Sitzungen auf einem alten Datum hängen bleiben