Threadlens – Open-Source-Tool zum Suchen, Analysieren, Sichern und Aufräumen lokaler AI-Sitzungen

Hallo. Ich entwickle ein Open-Source-Tool namens ThreadLens, um einige Unannehmlichkeiten zu lösen, die entstanden sind, weil ich mehrere AI-Tools parallel nutze.

Der Ausgangspunkt war zunächst das Aufräumen von Codex-Threads. In der UI konnte man sie nur archivieren, und wenn man sie wirklich löschen wollte, musste man die lokalen Dateien direkt selbst finden. Später habe ich gesehen, dass es auch in openai/codex eine ähnliche Anfrage gab – nämlich dass man nicht nur archive, sondern auch delete braucht. Da dachte ich mir, dass dieses Problem wohl nicht nur mich betrifft.

Danach, als ich verschiedene AIs wie Codex und Claude abwechselnd nutzte, tauchte ein weiteres Problem auf. Ich musste oft überlegen: „Wo ist noch mal das Gespräch, das ich damals mit der AI geführt habe?“ Dann habe ich in den versteckten Ordnern der einzelnen Tools gesucht oder mit rg nach Transkripten gesucht. Außerdem sammelten sich die lokalen Sitzungslogs immer weiter an, sodass es mühsam wurde, Speicherplatz aufzuräumen und externe Backups jedes Mal manuell zu verwalten.

Diesen gesamten Ablauf möchte ich an einer Stelle bündeln.

• Lokale Sitzungen von Codex, Claude, Gemini, Copilot zentral durchsuchen
• Pro Sitzung Transkript, Arbeitsverzeichnis, Dateigröße und Änderungszeit auf einem Bildschirm anzeigen
• Über gebündelte Backups und Auswirkungsanalyse aufräumen (die Auswirkungsanalyse ist derzeit noch vor allem auf Codex ausgerichtet)
• Per Routing/Parser nachvollziehen, wo und wie die Sitzungsstruktur je Provider gelesen wird

Local-First: Es gibt keine Konten und keine Cloud-Uploads. Die Anwendung liest Sitzungsdateien, die bereits auf meinem Computer vorhanden sind, und zeigt sie über eine lokale API, eine Web-UI, eine Desktop-App und ein TUI an.

Während der Entwicklung hatte ich das Gefühl, dass ein einfacher „Löschen“-Button allein nicht besonders sinnvoll ist. Gerade bei Codex-Threads wollte ich vor dem Löschen zuerst sehen: „Ist es wirklich in Ordnung, das hier zu löschen?“ Deshalb nutzt die Auswirkungsanalyse Signale, die sich aus den Dokumentationen von OpenAI/Claude und aus tatsächlichen Issues ableiten lassen, und setzt die Gewichtung der Scores im Produkt bewusst konservativ an.

Sie betrachtet nicht nur langen Kontext, tool-lastige Historien, das Vorhandensein von cwd und alte Sitzungen, sondern auch, ob andere Sitzungen diesen Thread direkt als Eltern-/Kind-/Fork-Beziehung referenzieren oder in Logs erwähnen. So kann man vor dem Löschen zuerst prüfen, ob es sich um einen potenziellen verwaisten Kandidaten handelt, ob Verbindungen zu anderen Sitzungen bestehen und ob ein Löschen unproblematisch erscheint.

Aktuell stehen macOS DMG, Windows exe und Linux AppImage bereit, und das Tool lässt sich auch direkt aus dem Quellcode ausführen.
Die Desktop-Builds sind derzeit noch unsigned, daher können Betriebssystemwarnungen erscheinen. Die provider-spezifische Erkennungslogik und die gesamte UX werden weiterhin laufend verbessert.

Feedback, Beiträge und jede Form der Unterstützung sind sehr willkommen!! Wenn ihr andere lokale AI-Sitzungsformate verwendet, sagt mir das bitte ebenfalls. Das würde helfen, Prioritäten festzulegen :)

GitHub: https://github.com/hanityx/threadlens

[minhoryang]

Großartig! Genau das habe ich gerade gebraucht!!

[hanityx]

Sogar bis zu den Kommentaren … Ich bin Ihnen noch dankbarer! In der UI ist auch Koreanisch verfügbar; es ist mehrsprachig auf i18n-Basis. Ich werde es künftig noch fleißiger weiter verfeinern!

[minhoryang]

@hanityx Könnten Sie vielleicht eine Anleitung erstellen, wie man weitere Provider hinzufügen kann? (Ich würde gern opencode oder noch etwas anderes ergänzen.) Sind die Informationen in docs/PROVIDER_SUPPORT.md von Ihnen selbst zusammengetragen worden? Muss man sie auch direkt in apps/api-ts/src/domains/providers/matrix.ts hinzufügen? Wenn man die Schnittstelle trennen würde, wäre es vielleicht etwas komfortabler.

[hanityx]

Es ist nicht so, dass sich einfach durch das Hinzufügen von matrix.ts ein neuer Provider anbinden lässt; man muss auch die Provider-Liste, die Pfadsicherheit, das Auffinden von Sessions, die Verarbeitung von transcript/search, Actions, Health, Tests und die Dokumentationsgenerierung gemeinsam darauf abstimmen.

docs/PROVIDER_SUPPORT.md ist kein Dokument, das man direkt bearbeitet, sondern wird automatisch auf Basis der Provider-Registry der Shared Contracts und des Skripts zur Dokumentationsgenerierung erzeugt. Ziel ist es, zu vermeiden, dass der Unterstützungsumfang pro Provider von der tatsächlichen Logik abweicht.

Die search/transcript-Logik auf API-Seite ist ohnehin schon recht umfangreich geworden, daher hatte ich mir bereits die Aufteilung und Bereinigung angesehen. Diesmal werde ich auch die internen Adapter und die Anleitung so aufbereiten, dass sich Provider leichter hinzufügen lassen, und bei OpenCode zunächst sicheren Read-only-Support prüfen. Wenn Sie den Pfad zu den lokalen Sessions sowie Beispiele und relevante Informationen als Issue hinterlassen, schaue ich es mir anschließend weiter an!

[minhoryang]

Wenn Sie es nur aufteilen, werde ich versuchen, opencode gemäß CONTRIBUTING.md und der Anleitung hochzuladen.