claude-devtools: die Sitzungsprotokolle von Claude Code aus ~/.claude auslesen

Das Problem: Claude Code fasst zusammen, was es getan hat

Das README benennt den Auslöser selbst: Seit Claude Code v2.1.20 ersetzt die Oberfläche detaillierte Ausgaben durch undurchsichtige Zusammenfassungen. Statt Dateipfaden und Zeilennummern steht dort nur noch "Read 3 files", statt des Suchmusters "Searched for 1 pattern". Die Argumentation des Projekts geht über die gekürzten Pfade hinaus und listet vier weitere Lücken auf: Denkschritte bleiben im Terminal unsichtbar, Tool-Aufrufe erscheinen als einzeilige Zusammenfassung ohne Ein- und Ausgabe, Subagenten liefern nur ihr Endergebnis, und das Kontextfenster zeigt einen dreisegmentigen Balken ohne Aufschlüsselung. Als einzigen Ausweg nennt das README den Schalter --verbose, der rohes JSON, interne System-Prompts und tausende Zeilen Rauschen ausgibt. Diese Beschreibung ist die Problemdefinition des Projekts, nicht ein von mir nachgeprüftes Verhalten. Wer die genannten Symptome im eigenen Terminal wiedererkennt, ist die Zielgruppe: Entwickler, die eine einzelne Sitzung debuggen, und nicht Teams, die Agents in der Produktion überwachen wollen.

Was die Anwendung aus den lokalen Logs rekonstruiert

claude-devtools startet keine eigene Instrumentierung. Es liest die Protokolle und Sitzungstranskripte, die Claude Code ohnehin unter ~/.claude/ ablegt, und baut daraus eine Ansicht. Das README beschreibt die Gegenüberstellung in Tabellenform: Aus "Read 3 files" werden exakte Pfade mit Syntaxhervorhebung und Zeilennummern, aus "Searched for 1 pattern" das reguläre Suchmuster samt Trefferdateien und Trefferzeilen, aus "Edited 2 files" Inline-Diffs mit markierten Hinzufügungen und Streichungen. Für die Kontextanalyse nennt das README eine Aufteilung der Tokens pro Turn auf sieben Kategorien: CLAUDE.md (global, projektbezogen, verzeichnisbezogen), Skills, per @ erwähnte Dateien, Tool-Ein- und -Ausgabe, Denkschritte, Team-Overhead und Nutzertext. Zusätzlich verspricht die Feature-Liste eine Kompaktierungsvisualisierung, vollständige Ausführungsbäume pro Subagent mit Tool-Spuren, Dauer und Kosten sowie die Darstellung von MEMORY.md als klickbarer Index, der die einzelnen Ebenen im Editor öffnet. Ob die sieben Kategorien in jeder Sitzung vollständig belegt sind, lässt sich aus dem Material nicht ableiten.

Installation: Homebrew, Installer oder Docker

Für macOS nennt das README den Cask: brew install --cask claude-devtools. Wer nicht über Homebrew installiert, lädt das .dmg für arm64 oder x64 von der Release-Seite, zieht es nach Programme und öffnet die Anwendung beim ersten Start per Rechtsklick und Öffnen, weil macOS sie sonst blockiert. Für Linux stehen .AppImage, .deb, .rpm und .pacman bereit, für Windows ein .exe-Installer, bei dem SmartScreen anschlägt und über "More info" und "Run anyway" umgangen werden muss. Der Docker-Weg ist der einzige, der eine andere Zugriffsform mitbringt: docker compose up, danach ist die Oberfläche unter http://localhost:3456 erreichbar. Das README verweist dafür auf einen eigenen Abschnitt zur Standalone-Bereitstellung, ohne an dieser Stelle Details zu nennen. Auffällig ist der Satz "Zero configuration. No API keys. No wrappers." Er ist plausibel, weil die Anwendung lokale Dateien liest und keinen Anthropic-Endpunkt anspricht; bestätigen lässt sich das aus dem vorliegenden Material nicht.

Für Docker-Betrieb ist das Log-Verzeichnis die kritische Einstellung

Der Docker-Pfad ist der einzige Installationsweg, bei dem die Anwendung und die Logs nicht im selben Dateisystem leben. Das README zeigt den Befehl docker compose up und den Port 3456, nennt aber im zitierten Ausschnitt weder das Volume für ~/.claude/ noch eine Umgebungsvariable für einen abweichenden Pfad. Wer diesen Weg wählt, muss also selbst klären, wie das Host-Verzeichnis in den Container gemountet wird und ob der Container die Dateien nur lesen oder auch schreiben darf. Das ist keine Nebensache: Die gesamte Funktionsweise hängt daran, dass die Logs erreichbar sind. Für die Desktop-Varianten entfällt das Problem, weil sie auf demselben Rechner laufen wie Claude Code. Wer den Docker-Betrieb auf einem Server plant, sollte vorher im Repository oder in der Dokumentation unter claude-dev.tools nachsehen, welche Compose-Datei ausgeliefert wird und welcher Pfad darin erwartet wird. Aus dem hier vorliegenden README geht das nicht hervor.

Grenzen: lokale Dateien, keine Live-Beobachtung

Die wichtigste Einschränkung steckt im Ansatz selbst. Die Anwendung liest, was Claude Code bereits geschrieben hat. Sie hängt sich nicht in den laufenden Prozess und liefert keine Echtzeitströme. Für die Fehlersuche im Nachhinein ist das ausreichend, für die Beobachtung eines laufenden Schwarmes von Agents nicht. Zweitens ist das Projekt an das Logformat von Claude Code gebunden. Das README datiert den Umbau der Ausgabe auf v2.1.20. Ändert Anthropic das Format erneut, muss claude-devtools nachziehen; eine Zusicherung zur Formatkompatibilität oder eine Versionsmatrix finde ich im Material nicht. Drittens: Die Oberfläche zeigt, was das Modell getan hat, und nicht, ob es richtig war. Wer aus den rekonstruierten Tool-Aufrufen eine Freigabeentscheidung ableiten will, überschätzt das Werkzeug. Viertens bleibt die Genauigkeit der Token-Attribution eine Zusage des README. Ob die sieben Kategorien exakt aufsummieren, ist ohne eigene Messung offen, und ich habe nicht gemessen.

Alternative: das Log selbst parsen statt eine Oberfläche zu installieren

Die naheliegende Alternative ist der direkte Blick in die Dateien unter ~/.claude/. Das ist kein Konkurrenzprodukt, sondern der Zustand vor der Installation, und die Unterschiede sind konkret. Ein JSON-Parser oder jq liefert die Rohdaten vollständig und ohne Annahmen des Werkzeugs, aber ohne Syntaxhervorhebung, ohne Diff-Darstellung, ohne Ausführungsbäume und ohne Token-Aufschlüsselung. Der zweite Weg ist Claude Code mit --verbose zu starten. Auch das ist keine andere Software, sondern ein anderer Modus desselben Programms, und das README beschreibt ihn als Ausgabe von rohem JSON, internen System-Prompts und tausenden Zeilen Rauschen. Man bezahlt also mit Lesbarkeit. Eine dritte Option wäre, sich die Auswertung selbst zu schreiben, weil das Logformat offenbar textbasiert und lokal vorliegt. Das lohnt sich, wenn nur eine einzige Kennzahl gebraucht wird, etwa die Summe der Tool-Aufrufe pro Sitzung. Sobald mehrere Sichten auf dieselben Daten nötig sind, verschiebt sich der Aufwand zuungunsten des Eigenbaus.

Pflege, Lizenz und Aktualisierungsaufwand

Das Repository steht unter der MIT-Lizenz. Das ist die permissivste übliche Variante: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Urheberrechtshinweis und der Lizenztext erhalten bleiben. Für den internen Einsatz in einem Unternehmen entstehen daraus in der Regel keine Pflichten zur Offenlegung eigener Änderungen. Das ist eine Einordnung, keine Rechtsberatung; wer die Anwendung weiterverbreitet oder in ein Produkt einbettet, sollte den Lizenztext selbst lesen. Zum Pflegeaufwand lässt sich aus den Releasenummern etwas ableiten: Auf v0.4.15 vom 30. April 2026 folgte v0.4.16 am 6. Mai, auf v0.5.0 am 13. Mai. Der Sprung von 0.4 auf 0.5 deutet auf eine Änderung mit möglichen Brüchen hin, die Patch-Releases dazwischen auf laufende Korrekturen. Solche Intervalle bedeuten für Anwender: regelmäßig aktualisieren, besonders wenn Claude Code selbst aktualisiert wurde. Weil die Anwendung an ein fremdes Logformat gebunden ist, ist ihr Nutzen nicht statisch. Ein Werkzeug, das ein Format liest, das jemand anderes kontrolliert, altert mit diesem Format.

Redaktionelles Fazit

Sinnvoll ist claude-devtools für alle, die ihre eigenen Claude-Code-Sitzungen nachvollziehen wollen: welches Modell welche Datei gelesen hat, wie sich die Kontextfenster über einen Turn hinweg zusammensetzen, was ein Subagent tatsächlich getan hat. Wer eine Team-übergreifende Observability-Plattform mit Server-Backend, Aufbewahrungsrichtlinien und Audit-Trail sucht, ist hier falsch, denn das Projekt liest lokale Dateien und bietet laut Material keine solche Infrastruktur. Vor dem Einsatz ist zu prüfen, ob die eigene Claude-Code-Version die von v2.1.20 eingeführte Formatierung der Logs verwendet, unter welchem Pfad die Sitzungen tatsächlich liegen und ob die installierte Release-Version zu diesem Format passt; das README gibt dazu keine Kompatibilitätsmatrix an.

Offizielle Quellen

1. License: MIT
2. matt1398/claude-devtools on GitHub
3. Project website
4. README
5. Releases