Funes-Speicher für Coding-Agenten: Claude Code + Codex einrichten

Eine Stunde lang erklärt man, warum ein Parser geändert wurde – und sobald die nächste Aufgabe in einem anderen Agenten startet, ist die ganze Begründung verschwunden. Funes indexiert Agent-Sitzungen lokal, liefert die ursprünglichen Belege samt Herkunft zurück und kann Claude Code, Codex, pi und Hermes auf denselben Speicher zugreifen lassen. Die wichtige Einschränkung: Funes holt frühere Informationen hervor. Ob eine alte Entscheidung noch zur aktuellen Situation passt, muss weiterhin der Agent beurteilen.

Dieser Leitfaden zeigt einen praxistauglichen Claude-Code-zu-Codex-Workflow, lokale Speicherung, optionales Synchronisieren über Hugging Face, die Anbindung beliebiger MCP-Clients sowie die Prüfungen, die aus abgerufenem Verlauf eine verlässliche Gedächtnishilfe machen.

Vor der Installation die Speichergrenze festlegen

Beginne mit lokalem Speicher, wenn du Funes zunächst testen oder mit sensiblen Repositories arbeiten möchtest. Einen Hugging-Face-Datensatz bindest du erst dann ein, wenn derselbe Verlauf auf einem anderen Rechner oder von mehreren Personen benötigt wird.

Laut der Funes-Sicherheitsrichtlinie laufen Parsing, Chunking, Embedding und Reranking standardmäßig lokal. Daten verlassen den Rechner über funes push oder eine Shared-Memory-Integration, die sie an einer Sitzungsgrenze veröffentlicht. Ein Hub-gebundener Speicher ist ein Dataset-Repository – prüfe deshalb vor dem ersten Push dessen Sichtbarkeit.

Für einen ersten Test ist local die richtige Wahl. Die Bindung kannst du später mit funes add <agent> <memory> ändern.

Funes installieren und den ersten Index anlegen

Das offizielle Funes-Repository stellt ein Shell-Installationsskript bereit. Es erkennt die Plattform, lädt ein Binary mit Tag herunter, prüft die Prüfsumme des Releases und legt die ausführbare Datei standardmäßig unter ~/.local/bin in deinem PATH ab:

curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh

Wenn funes nicht sofort gefunden wird, öffne eine neue Shell und prüfe anschließend die Installation:

funes status

Im Repository sind getaggte Binaries für Linux x86_64, Linux aarch64 und macOS Apple Silicon aufgeführt. Ist deine Plattform nicht dabei, folge den Anweisungen zum Bauen aus dem Quellcode, statt davon auszugehen, dass der vorgefertigte Installer sie abdeckt.

Der Fünf-Minuten-Start

Führe den folgenden Befehl dort aus, wo die Sitzungen des Agenten liegen, die künftig durchsuchbar sein sollen:

funes add claude

Bei Claude Code kann dieser Befehl den ersten Index erstellen, die Lesewerkzeuge registrieren, die Integrationsautomatisierung installieren und abgeschlossene Turns fortlaufend indexieren. Der erste Durchlauf ist textorientiert und soll nach der Bestätigung etwa eine Minute dauern. Zuerst werden Fließtext und Begründungen verarbeitet, bevor umfangreiche Tool-Ausgaben an die Reihe kommen. (Funes-Einrichtungsdokumentation)

Den aktuellen Zustand prüfst du anschließend mit:

funes status

Wenn Claude-Sitzungen manuell initial indexiert oder aktualisiert werden sollen, verwende:

funes index --harness claude

Ohne Pfadangabe durchsucht funes index die üblichen Sitzungsordner für Claude, Codex, pi und Hermes, darunter ~/.claude/projects und ~/.codex/sessions. Mit --harness claude beschränkst du den Scan auf Claude Code. Der Indexierungsleitfaden beschreibt für Aktualisierungen ohne Pfadangabe ebenfalls ein Zeitbudget von ungefähr 60 Sekunden mit Textpriorität. Ältere Sitzungen und große Tool-Ergebnisse können deshalb erst in späteren Durchläufen hinzukommen.

Die Indexierung von Funes ist inkrementell. Bereits geschriebene Chunks werden bei einer erneuten Ausführung nicht noch einmal eingebettet. Explizit angegebene Transcript-Pfade und Hub-Trace-Repositories werden dagegen vollständig indexiert und unterliegen nicht dem Zeitbudget für die Suche ohne Pfadangabe. (Details zur Indexierung)

Funes an Claude Code anbinden

Für einen lokalen Claude-Code-Speicher genügt:

funes add claude local
funes status

local kannst du weglassen, da es der Standard ist. Wenn im Terminal ein HF-Token verfügbar ist, bietet Funes möglicherweise an, ein eigenes Repository unter <user>/funes-memory einzurichten. Für einen rein lokalen Test lehnst du diese Abfrage ab.

Die Claude-Integration besteht aus einem Plugin, das ausschließlich Hooks nutzt, sowie einer separaten MCP-Registrierung. Funes verändert Claude Codes settings.json nicht. Die Automatisierung indexiert abgeschlossene Turns; eine Konfiguration für gemeinsamen Speicher ergänzt die Veröffentlichung an Sitzungsgrenzen. (Funktionsweise der Automatisierung)

Öffne Claude Code und teste eine bekannte frühere Entscheidung, statt die Einrichtung allein anhand der erfolgreichen Installation zu beurteilen:

Find the previous decision about the streaming parser. Use Funes recall if the repository history does not explain it, and cite the session you used.

Ein gutes Ergebnis verweist auf die frühere Passage, nennt die zugehörige Sitzung und trennt ein altes Experiment vom aktuellen Stand des Repositories.

Um die Integration zu entfernen, ohne gespeicherte Daten zu löschen, führst du aus:

funes remove claude

Laut der Dokumentation zum Entfernen wird damit nur die Funes-Anbindung gelöscht. Der lokale Speicher, die ursprünglichen Transcripts, Caches und der veröffentlichte Speicher bleiben erhalten.

Dieselbe Erinnerung an Codex anbinden

Sobald Claude Code funktioniert, bindest du Codex an denselben lokalen Speicher:

funes add codex local
funes status

Für einen gemeinsamen, Hub-basierten Speicher verwendest du für beide Agenten dieselbe Repository-Kennung:

funes add claude <org>/<repo>
funes add codex <org>/<repo>

Bei Codex gibt es einen leicht zu übersehenden Vertrauensschritt. Funes schreibt seine Hooks nach ~/.codex/hooks.json. Führe in Codex /hooks aus, prüfe die Funes-Einträge und vertraue ihnen. Solange die Hooks nicht freigegeben sind, überspringt Codex sie: Neue Turns werden dann weder indexiert noch veröffentlicht. Der dokumentierte Workflow für gebundenen Speicher setzt Codex 0.151.0 voraus. (Anforderungen für die Codex-Automatisierung)

Einen echten Übergabetest zwischen Agenten durchführen

Verwende eine markante Entscheidung, die in der einen Sitzung vorkommt, in der anderen aber nicht:

1. Suche in Claude Code die Parser-Entscheidung und merke dir einen eindeutigen Begriff aus der Diskussion.
2. Beende die Sitzung, damit Indexierung und Automatisierung an der Sitzungsgrenze ausgeführt werden können.
3. Frage Codex nach diesem Begriff und bitte um die ursprüngliche Begründung.
4. Prüfe, ob die Antwort Claude als Quell-Harness nennt und auf die ursprüngliche Sitzung oder den ursprünglichen Turn verweist.

Die Belege kannst du direkt im Terminal prüfen:

funes recall "why did we switch away from the streaming parser"

recall liefert gerankte Passagen statt einer automatisch erzeugten Zusammenfassung. Jeder Treffer enthält Angaben zur Quelle sowie einen generierten get-Befehl. Kopiere diesen Befehl, wenn du die umgebenden Turns benötigst.

Wenn Codex nichts zurückgibt, prüfe die Version, den Vertrauensstatus unter /hooks, funes status und die Frage, ob die Claude-Sitzung vor der Integration entstanden ist. Versuche es anschließend mit einem markanten Begriff aus der ursprünglichen Diskussion.

pi, Hermes oder einen anderen MCP-Client verbinden

Funes unterstützt neben Claude Code und Codex auch pi und Hermes direkt. Pi verwendet Extension-Events, Hermes Shell-Hooks; die Indexierung pro Turn ist bei Hermes als Beta dokumentiert. (Details zu den unterstützten Agenten)

Für einen MCP-kompatiblen Client außerhalb dieser vier Agenten startest du Funes als lokalen Stdio-Server:

{
  "mcpServers": {
    "funes": {
      "command": "funes",
      "args": ["mcp"]
    }
  }
}

Um den Server an einen gemeinsamen Speicher zu binden, ergänzt du das Repository hinter mcp:

{
  "mcpServers": {
    "funes": {
      "command": "funes",
      "args": ["mcp", "<org>/<repo>"]
    }
  }
}

Die MCP-Dokumentation beschreibt die Werkzeuge recall, get und status. funes mcp arbeitet nur lesend: Der Befehl indexiert keine Sitzungen und veröffentlicht keine Daten. Für diese Aufgaben verwendest du funes index, funes push oder eine unterstützte funes add-Integration.

Ein in einem einzelnen MCP-Aufruf angegebener Speicher überschreibt die Bindung auf Serverebene. Ist beides nicht gesetzt, verwendet Funes den lokalen Speicher.

Erinnerungen abrufen, ohne die Belege aus der Hand zu geben

Funes bietet drei klar getrennte Arbeitsweisen:

Die dokumentierten Standardwerte für recall sind 8 Treffer, ein nachgelagertes Kandidatenfeld mit 30 Ergebnissen, eine Halbwertszeit von 30 Tagen für die Aktualität und 1 benachbarter Chunk. (Recall-Optionen und Standardwerte)

Ein zuverlässiger Debugging-Ablauf sieht so aus:

1. Führe funes recall mit dem Fehler, dem Namen der Komponente oder der Formulierung der Entscheidung aus.
2. Nutze den generierten get-Befehl, um den vollständigen Turn zu öffnen.
3. Vergleiche die gefundene Entscheidung mit dem aktuellen Branch.
4. Setze die Änderung um oder führe das Experiment aus.
5. Starte anschließend erneut eine Suche mit dem Ergebnis, damit die nächste Sitzung es wiederfindet.

funes ask ist eingeschränkter. Zuerst werden passende Passagen abgerufen, anschließend erhält Claude oder Codex diese Passagen zusammen mit deiner Frage und formuliert eine Antwort. Der untergeordnete Agent bekommt keine Tools, kein stdin und keine MCP-Server und kann die Suche nach einem schlechten Treffer nicht wiederholen. Die Suche selbst läuft zwar lokal, aber Frage und abgerufene Passagen werden an den für den ausgewählten Agenten konfigurierten Provider gesendet. Die Ask-Dokumentation empfiehlt deshalb für Inhalte, die du nicht an diesen Provider schicken würdest, ausdrücklich funes recall.

Den Speicher vertrauenswürdig und betriebsbereit halten

Funes bewahrt Quellpassagen und Herkunftsinformationen auf. Ob ein historischer Workaround noch zum aktuellen Stand passt, kann das Tool jedoch nicht entscheiden.

„Coding-Agenten werden deutlich weniger seltsam, wenn der Speicher langweilige Infrastruktur ist: lokaler Index, exakte Herkunft, standardmäßig privat.“ — @TheArtemisHunts auf X

Eine kleine Checkliste für den produktiven Einsatz

Funes schwärzt Zugangsdaten während der Indexierung und führt vor der Veröffentlichung einen ausfallsicher blockierenden TruffleHog-Scan durch. Laut der Push-Dokumentation verhindert ein fehlender Scanner die Veröffentlichung. Gelangt ein aktives Zugangsdaten-Secret in einen Remote-Datensatz, musst du es sofort rotieren, denn das spätere Bereinigen eines Commits entfernt es nicht aus der Repository-Historie.

Verwende Hugging-Face-Tokens nach dem Prinzip der geringsten Rechte: Schreibzugriff für Rechner, die veröffentlichen, und schreibgeschützter Zugriff für Teammitglieder oder Hosts, die ausschließlich suchen. Veröffentlichen zwei Rechner in denselben Remote-Speicher, können außerdem Race Conditions entstehen. Die Automatisierungsdokumentation verspricht keine Serialisierung über mehrere Rechner hinweg.

Die praktische Entscheidung

Statt sofort jede Integration einzurichten, startest du am besten mit einem dieser Szenarien:

FAQ zum Funes-Speicher für Coding-Agenten

Ist Funes lokal?

Funes verarbeitet und speichert Erinnerungen standardmäßig lokal. Das Tool arbeitet nach dem Local-first-Prinzip, ist aber nicht automatisch ausschließlich lokal: Pushes, Shared-Memory-Hooks und ask können Daten außerhalb des lokalen Prozesses übertragen.

Funktioniert Funes mit Claude Code und Codex?

Ja. funes add unterstützt Claude Code und Codex ebenso wie pi und Hermes. Die Speicherbindung für Codex setzt 0.151.0 und vertrauenswürdige Hooks voraus.

Indexiert Funes Sitzungen automatisch?

Nach funes add installieren die unterstützten Integrationen eine Automatisierung zur Indexierung pro Turn. Der erste Bootstrap ist begrenzt, daher müssen ältere Sitzungen und umfangreiche Tool-Ausgaben möglicherweise in späteren Durchläufen nachgeholt werden.

Wie teile ich einen Speicher zwischen Claude Code und Codex?

Verwende für funes add claude und funes add codex dasselbe Argument <org>/<repo>. Funes hält den Arbeitsindex lokal und veröffentlicht den gemeinsamen Datensatz an den Sitzungsgrenzen.

Was passiert, wenn Funes eine veraltete Entscheidung abruft?

Prüfe sie mit funes recall, erweitere den Treffer über den generierten get-Befehl und vergleiche ihn vor einer Umsetzung mit dem aktuellen Branch. Formuliere die Anfrage um, wenn der erste Abruf nicht das Richtige findet.

Bleiben die Daten bei funes ask auf meinem Rechner?

Abruf und Reranking laufen lokal. ask sendet jedoch die Frage und die abgerufenen Passagen an den konfigurierten Claude- oder Codex-Provider. Für sensible Belege verwendest du recall.

Kann ich Funes entfernen, ohne den Speicher zu löschen?

Ja. funes remove claude, funes remove codex, funes remove pi und funes remove hermes entfernen die Integrationsanbindung, bewahren aber den indexierten Speicher und die Quell-Transcripts.