Zum Inhalt springen
K Krynex Labs
Alle Artikel
#Open Source#Claude Code#Developer Tools#Security

OpenWolf Enhanced: Wie wir ein verwaistes Claude-Code-Tool gehärtet haben

Ein beliebtes Open-Source-Tool für Claude Code wurde nicht mehr gepflegt — mit wachsenden Speicher-, Security- und Datenverlust-Problemen. Wir haben es geforkt, repariert und pflegen es offen weiter.

Annett Krusch
OpenWolf Enhanced: Wie wir ein verwaistes Claude-Code-Tool gehärtet haben

Wir bauen bei Krynex Labs jeden Tag Software mit Claude Code. Irgendwann fiel uns auf, dass eine Sitzung mehr Tokens verbrauchte, als sie sollte — und dass ein unscheinbares Zustandsfile in einem unserer Projekte auf 44 Megabyte angewachsen war. Der Verursacher: ein beliebtes, aber seit Monaten nicht mehr gepflegtes Open-Source-Tool namens OpenWolf. Statt es rauszuwerfen, haben wir es repariert. Das Ergebnis ist OpenWolf Enhanced.

Was OpenWolf überhaupt macht

Claude Code arbeitet „blind”: Es liest dieselben Dateien mehrfach, kennt die Struktur eines Projekts nicht und merkt sich Korrekturen nicht über Sitzungen hinweg. OpenWolf gibt dem Assistenten über sechs schlanke Lifecycle-Hooks ein zweites Gehirn: einen Datei-Index (was steckt in einer Datei, bevor man sie öffnet), ein lernendes Gedächtnis und ein Token-Ledger. Eine gute Idee — die niemand mehr wartete.

Was kaputt war

Ein kurzes Audit förderte drei Klassen von Problemen zutage:

  • Unbegrenztes Wachstum. Das Token-Ledger, der Bug-Log und die Backups wurden nie beschnitten. Bei jedem Sitzungsende wurde die komplette Datei neu geschrieben — quadratischer Aufwand, der irgendwann den Hook selbst in den Timeout trieb. Daher die 44 MB.
  • Security-Lücken. Das Dashboard band an 0.0.0.0 (also ans ganze Netz), ohne jede Authentifizierung — inklusive eines Endpunkts, der beliebige Hintergrund-Tasks auslösen konnte. Dazu Shell-Kommandos per String-Interpolation (Command-Injection-Fläche) und ungeprüfte Dateipfade (Path Traversal).
  • Stiller Datenverlust. Unter Windows mit git autocrlf verwarf der Parser bei CRLF-Zeilenenden jeden Eintrag und schrieb die Projektkarte leer. Und: außer .env wurde keine Secret-Datei ausgeschlossen — private Keys, Zertifikate und Keystores landeten anteilig im Projekt-Gehirn.

Was wir gemacht haben

Kein Pflaster, sondern ein Fork am eigentlichen Quellcode:

  • Speicher gedeckelt — Ledger, Bug-Log, Backups und Cron-Queues haben feste Obergrenzen, konfigurierbar über eine neue retention-Sektion.
  • Ein Befehl für die Wartungopenwolf doctor meldet den Footprint und kompaktiert alles in einem Rutsch, ganz ohne laufenden Daemon.
  • Security gehärtet — Dashboard nur noch auf 127.0.0.1 mit Token-Auth, Shell-Kommandos als Argument-Arrays, Path-Traversal-Guards.
  • Datenverlust behoben — CRLF-tolerant, und Secret-Dateien (.pem, .key, .p8, Keystores …) werden überall ausgeschlossen.
  • Respektiert .gitignore — Build-Output und generierte Dateien bleiben aus dem Index.

Dazu haben wir mehrere gute, nie gemergte Pull Requests aus dem toten Upstream-Repo übernommen und an unseren Code angepasst — mit Nennung der ursprünglichen Autoren, wie es sich unter AGPL gehört.

Ein schöner Moment am Rande: Einer der von uns reparierten Reminder feuerte später im Live-Betrieb zum ersten Mal korrekt in den Kontext des Assistenten — der Beweis, dass der Fix wirkt, kam vom Tool selbst.

Warum wir das öffentlich machen

Zwei Gründe. Erstens verlangt die AGPL-3.0 die Offenlegung — und das ist gut so. Zweitens ist es ehrlicher als jedes Slide-Deck: Wer sehen will, wie wir arbeiten — Bugs finden, Security ernst nehmen, sauber attribuieren — kann in den Quellcode und den Changelog schauen. Wir bauen Dinge, die in Produktion laufen. Das hier ist eins davon, zum Anfassen.

OpenWolf Enhanced ist ein Community-Fork von OpenWolf der Cytostack Pvt Ltd, lizenziert unter AGPL-3.0. Voller Dank an die ursprünglichen Autoren.

Zur Projektseite · Auf GitHub ansehen

Passend dazu