ripwire: Call-Graph-Kontext für Coding-Agents ohne Indexserver

Welches Problem ripwire adressiert und für wen es gebaut ist

Ein Coding-Agent, der eine Änderung vorbereiten soll, greift in der Regel zu grep und liest anschließend ganze Dateien. Das kostet Kontext und liefert trotzdem keine Antwort auf die eigentliche Frage: Wer ruft diese Funktion auf, und welche Tests müssten nach einer Änderung laufen. ripwire setzt genau dort an. Das Projekt bezeichnet sich selbst als "the ripgrep of AI context" und liefert laut README einen gerankten, deterministischen Call-Graph, also eine geordnete Liste dessen, was berührt wird und was davon abhängt.

Die Zielgruppe sind Teams, die Agents wie Claude Code, Codex, Cursor, Windsurf, Gemini, opencode oder aider einsetzen und deren Kontextbudget pro Sitzung begrenzt ist. Das README nennt als Ziel "Terminality": eine Frage, eine vollständige Antwort, ohne drei nachgelagerte greps. Ob dieses Ziel in der Praxis erreicht wird, hängt stark davon ab, wie gut die Auflösung im jeweiligen Repository funktioniert, und dazu macht das Material nur begrenzte Aussagen.

Bemerkenswert ist die Haltung gegenüber Unsicherheit. Das README erklärt, ein Zähler, der kein Total sein kann, werde als Untergrenze gekennzeichnet, eine Null bedeute "nichts gefunden" und niemals "existiert nicht", und jede Kürzung werde offengelegt. Das ist eine Designentscheidung, die sich in der Ausgabe wiederfinden muss, damit sie etwas wert ist. Wer schon einmal erlebt hat, wie ein Agent eine unvollständige Suche als vollständiges Bild interpretiert, versteht, warum das der interessanteste Teil des Projekts ist.

Ein Prozess, kein Daemon: die Mechanik hinter dem Index

ripwire läuft nach Angaben des README als einzelnes Binary, offline, ohne API-Key, ohne Embeddings und ohne Indexserver. Das ist der zentrale architektonische Unterschied zu Graphdatenbank-Ansätzen, bei denen ein Server läuft und ein persistenter Index gepflegt wird. Der Preis dafür ist, dass die Indexierung bei jedem Aufruf neu anfällt. Die Dokumentation nennt für dieses Repository 0,25 s und 6,6 MB, für django und webpack 0,25 bis 0,45 s und 6,6 bis 16,5 MB. Diese Werte stammen aus dem Projekt selbst und sind nicht unabhängig nachgeprüft.

Für die Analyse setzt ripwire auf tree-sitter. Die Liste der unterstützten Sprachen im README umfasst Rust, C++, Objective-C/C++, C, Metal, CUDA, Python, Go, Swift, TypeScript, JavaScript, Java, Ruby, PHP, Lua, Elixir, Bash, C#, JSON, TOML, YAML und Markdown. Das ist breit, aber es ist eine Parser-Grundlage, keine semantische Auflösung. Ein tree-sitter-basierter Call-Graph kann Aufrufe erkennen, die syntaktisch sichtbar sind. Er kann nicht wissen, welche konkrete Implementierung hinter einer virtuellen Methode oder einem dynamischen Dispatch steht. Genau das ist die Grenze, an der ein Agent bei objektorientiertem Code mit vielen Indirektionen falsche Schlüsse ziehen kann.

Das README nennt außerdem eine Signatur-Kompression: Signaturen belegten 74,7 Prozent weniger Bytes als Körper. Das ist eine nachvollziehbare Idee. Ein Agent, der nur wissen muss, welche Funktion existiert und was sie erwartet, braucht den Rumpf nicht. Ob die komprimierte Darstellung in der Praxis ausreicht, um die nächste Frage ohne zusätzlichen grep zu beantworten, lässt sich aus dem Material nicht ableiten.

Installation und der erste Aufruf

Der Installationsweg ist ein Einzeiler aus dem README. Er lädt ein Skript und führt es aus:

RIPWIRE_REPO=redhat-et/ripwire bash -c "$(curl -fsSL https://raw.githubusercontent.com/redhat-et/ripwire/main/scripts/install.sh)" export PATH="$HOME/.local/bin:$PATH" cd your-repo ripwire . --for="<the change you are about to make, in words>"

Der PATH-Export ist nötig, weil das Binary laut README nach $HOME/.local/bin installiert wird. Der Aufruf ripwire . erwartet ein Repository-Verzeichnis und mit --for eine Beschreibung der geplanten Änderung in natürlicher Sprache. Das ist der Kern der Schnittstelle: Der Agent oder der Mensch beschreibt die Absicht, und ripwire rankt den Graphen danach.

Dasselbe Installationsskript aktiviert laut README die zugehörigen Skills für jeden Agent, den es auf der Maschine findet. Das ist praktisch, aber es bedeutet auch, dass ein Installationsskript Dateien außerhalb des eigentlichen Binaries anlegt. Wer das nicht will, sollte vorher prüfen, welche Agent-Konfigurationen auf dem System liegen.

Der MCP-Server ist ausdrücklich als zweite, optionale Schnittstelle beschrieben. Das README argumentiert, die CLI sei der günstigere Weg, weil die Verb-Schemas des MCP-Servers in jeder Sitzung im Kontext des Agents liegen, unabhängig davon, ob er sie aufruft. Das ist ein Kostenargument, das sich direkt aus der Funktionsweise von MCP ergibt und nicht ripwire-spezifisch ist. Wer den Server trotzdem will, findet die Einrichtung im Abschnitt "Set it up in your coding agent" des README.

Wo ripwire an seine Grenzen stößt

Die wichtigste Einschränkung steckt in der Natur der Analyse. Ein Call-Graph, der aus Syntaxbäumen gewonnen wird, kennt keine Laufzeitauflösung. Bei dynamisch typisierten Sprachen, bei Reflexion, bei Dependency Injection oder bei Makros, die Code erzeugen, kann er Aufrufe übersehen oder falsch zuordnen. Das README adressiert das teilweise, indem es Unsicherheiten kennzeichnet und Zähler als Untergrenze ausweist. Eine gekennzeichnete Untergrenze ist aber immer noch eine Untergrenze. Ein Agent, der sie als vollständige Liste behandelt, trifft Entscheidungen auf unvollständiger Basis.

Der zweite Punkt ist die fehlende Persistenz. Ohne Indexserver gibt es keinen warmen Zustand über Prozessgrenzen hinweg. Die gemessenen 197 ms für warme Abfragen beziehen sich auf einen Prozess, der bereits indexiert hat. In einem Agent-Workflow, der ripwire mehrfach hintereinander aufruft, fällt die Indexierung möglicherweise mehrfach an. Ob das in der Praxis ins Gewicht fällt, hängt von der Größe des Repositories und der Zahl der Aufrufe ab, und dazu macht das Material keine Angabe.

Der dritte Punkt betrifft die Qualitätsaussagen. Das README spricht von "blast radius, tests-to-run, quality deltas" und nennt McCabe, Halstead und Spärck Jones als Grundlage. Das sind etablierte Metriken. Ob die daraus abgeleiteten Deltas für ein konkretes Repository aussagekräftig sind, lässt sich nicht aus dem README ableiten. Wer ripwire wegen der Qualitätsmetriken einsetzen will, sollte diesen Teil zuerst an einem bekannten Repository prüfen, bevor er Entscheidungen darauf stützt.

Der Vergleich mit dem Graphdatenbank-Ansatz

Das README vergleicht ripwire direkt mit einem "leading graph-database code-context MCP server", ohne ihn im zitierten Ausschnitt namentlich zu nennen. Der Ansatzunterschied ist klar: Dort läuft ein Server, der einen persistenten Graphen in einer Datenbank hält und über MCP abfragt. Hier läuft ein einzelnes Binary, das bei jedem Aufruf neu indexiert und die Antwort auf stdout schreibt.

Die Konsequenzen sind unterschiedlich. Ein persistenter Graph kann Beziehungen speichern, die sich nicht aus einem einzelnen Parse-Lauf ergeben, etwa aufgelöste Typen oder historische Änderungsdaten. Er kann auch über mehrere Abfragen hinweg konsistent bleiben. Dafür fallen Betriebskosten an: Der Server muss laufen, der Index muss aktuell gehalten werden, und der Speicherbedarf ist deutlich höher. Das README nennt 391 bis 623 MB für den Vergleichsserver gegen 6,6 bis 16,5 MB für ripwire.

Für einen Agent, der einmal pro Aufgabe eine Frage stellt, ist der Unterschied zwischen 0,25 s und 46,8 s Indexierungszeit selten der limitierende Faktor. Der limitierende Faktor ist der Kontext, den die Antwort belegt. Hier argumentiert ripwire mit der Signatur-Kompression und dem Token-Budget. Wer bereits einen Graphdatenbank-Server betreibt und mit dessen Antwortqualität zufrieden ist, hat wenig Grund zu wechseln. Wer keinen Server betreiben will, hat einen Grund, ripwire zumindest auszuprobieren.

Wartung, Releases und Lizenz

Die letzten Releases liegen dicht beieinander: v0.3.8 am 13. August 2026, v0.4.0 am 7. September 2026, v0.5.0 am 8. September 2026. Der letzte Push auf main datiert vom 10. September 2026. Das Muster deutet auf aktive Entwicklung mit kurzen Abständen zwischen kleineren und größeren Versionssprüngen hin. Für Anwender bedeutet das, dass sich CLI-Flags und Ausgabeformate zwischen Versionen ändern können. Wer ripwire in eine Agent-Pipeline einbaut, sollte die Version pinnen und die Ausgabe nicht ungeprüft als stabil behandeln.

Ein Teil der Wartungslast liegt beim Projekt selbst. Das README erwähnt test/readmedriftcheck.sh, ein Skript, das die im README genannten Zahlen gegen die Tabellen in docs/LINEAGE.md prüft und fehlschlägt, wenn beide auseinanderlaufen. Das ist ein ungewöhnlicher Schritt und ein Hinweis darauf, dass die Zahlen im README als überprüfbare Aussagen gemeint sind und nicht als Marketing. Ob das Skript in der CI tatsächlich läuft, lässt sich aus dem Material nicht bestätigen, aber die Existenz eines solchen Checks ist ein positives Signal für die Pflege der Dokumentation.

Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber die Beibehaltung von Copyright-Hinweisen und Lizenztext und enthält eine ausdrückliche Patentgewährung. Wer ripwire in ein Produkt einbettet, sollte die NOTICE-Anforderungen prüfen. Das README verlinkt THIRD_PARTY.md und weist damit auf Abhängigkeiten Dritter hin, auch wenn das Projekt selbst keine Runtime-Abhängigkeiten hat. Eine rechtliche Bewertung ersetzt das nicht.

Was vor dem Einsatz zu klären ist

Die entscheidende Frage ist nicht, ob ripwire schnell indexiert. Die entscheidende Frage ist, ob die Antworten für das eigene Repository vollständig genug sind, dass ein Agent keinen nachgelagerten grep braucht. Das README selbst räumt ein, dass eine vollständige Antwort in einem Aufruf "not always trivial to reach" ist und dass die Ausgabe dann sagt, dass sie nicht erreicht wurde. Diese Ehrlichkeit ist wertvoll, aber sie verschiebt die Arbeit: Der Agent muss mit einer als unvollständig markierten Antwort umgehen können.

Wer ripwire evaluiert, sollte mit einem Repository beginnen, dessen Aufrufstruktur bekannt ist. Dann lässt sich prüfen, ob die als Untergrenze markierten Zähler tatsächlich Untergrenzen sind und ob die gerankte Liste die erwarteten Einträge enthält. Die Zahlen in docs/EVALS.md sind der Ausgangspunkt, nicht der Beweis. Sie stammen aus Messungen des Projekts an django, webpack und ripwire selbst. Ein Repository mit schwerer Makro-Nutzung, intensiver Reflexion oder einer Sprachmischung, die tree-sitter nicht abdeckt, kann ein anderes Bild ergeben.

Für Teams, die bereits einen Graphdatenbank-Server betreiben und dessen Latenz akzeptieren, ist der Wechsel kein offensichtlicher Gewinn. Für Teams, die keinen Server betreiben wollen und deren Agents heute mit grep und ganzen Dateien arbeiten, ist ripwire ein konkreter Kandidat. Die Prüfung beginnt mit einem Aufruf von ripwire . --for="..." auf einem Repository, dessen Struktur man kennt, und dem Vergleich der Ausgabe mit dem, was man selbst erwartet hätte.

Redaktionelles Fazit

Wer einen Coding-Agent auf großen, unbekannten Repositories betreibt und die Kontextkosten pro Sitzung senken will, findet in ripwire einen Ansatz, der ohne Server, ohne Embeddings und ohne API-Key auskommt. Wer stattdessen typgenaue Auflösung über Sprachgrenzen hinweg oder eine dauerhaft gepflegte Graphdatenbank braucht, ist hier falsch. Vor dem Einsatz sollte man den Inhalt von docs/EVALS.md und docs/LINEAGE.md selbst lesen und mit dem eigenen Repository nachvollziehen, denn die Zahlen des Projekts stammen aus seinen eigenen Messungen.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. README
4. redhat-et/ripwire on GitHub
5. Releases