FIMemory

Ein lokaler Store, den deine KI-Tools lesen können, sobald sie verbunden und dazu angewiesen sind.

FIMemory (FI Memory, von Future Industries) bewahrt deine Notizen auf deinem eigenen Computer auf und verbindet deine KI-Tools mit ihnen, damit du aufhörst, dasselbe Projekt in jeder Sitzung neu zu erklären. Der Store ist ein gewöhnlicher Ordner deiner eigenen Dateien: kein proprietäres Format, kein Server, kein Konto, nichts wird irgendwo hochgeladen. Neue Stores sind standardmäßig im Ruhezustand verschlüsselt. Du wählst eine Passphrase, eine 24-Wörter-Wiederherstellungsphrase wird einmal gedruckt, und die Dateien bleiben privat, wohin sie auch reisen: ein git-Host, ein Cloud-Backup, ein USB-Stick. Bevorzugst du Dateien, die du direkt in einem Texteditor öffnen kannst? Klartext ist bei setup eine explizite Wahl entfernt, und ein verschlüsselter Store exportiert jederzeit zurück in lesbares Markdown, gesperrt durch nichts außer deinem Schlüssel.

Hier starten

Zwei Befehle.

npm i -g fimemory
fimemory setup

Wenn dieser erste Befehl mit EACCES: permission denied fehlschlägt (häufig auf macOS, wo der Standard-Globalordner von npm root gehört), gib npm einen Ordner, der dir gehört, und versuche es erneut. Kein sudo nötig:

npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc
npm i -g fimemory

Schließe dann jedes KI-Tool, das bereits lief, und öffne es erneut, denn sie lesen ihre Einstellungen, wenn sie starten.

Das ist die gesamte Installation. setup erstellt den Store, wenn du keinen hast, verbindet jedes KI-Tool, das es auf dieser Maschine findet, prüft dann seine eigene Arbeit und druckt, was gelandet ist und was nicht. Es erneut auszuführen ist sicher und langweilig: alles, was bereits vorhanden ist, meldet unchanged und nichts wird neu geschrieben. Wenn du nicht sicher bist, ob es funktioniert hat, führe es erneut aus.

Beim Erstellen eines Stores auf einem Terminal führt dich setup durch die Verschlüsselung: Du wählst eine Passphrase (oder drückst eine Taste, um mit --plaintext abzulehnen), es druckt deine 24-Wörter-Wiederherstellungsphrase einmal und bittet dich zu beweisen, dass du sie aufgeschrieben hast, dann lässt es den Store auf dieser Maschine für etwa 8 Stunden entsperrt. In einem Skript oder CI gibt es keine Eingabeaufforderung: Übergib --passphrase "...", setze GESTALT_PASSPHRASE oder sage --plaintext. Mit keinem davon lehnt es sauber ab, statt zu raten. Verlierst du sowohl die Passphrase als auch die 24-Wörter-Phrase, sind die Daten bewusst weg; das kostet „dein Schlüssel, nicht unsere Server", und der geführte Durchlauf wird es nicht still geschehen lassen.

Ein Schritt, den setup nicht für dich abschließen kann, ist Claude Code, das seine eigene Konfigurationsdatei verwaltet. setup prüft, ob der claude-Befehl auf dieser Maschine existiert: Wenn ja, druckt es eine einzelne claude mcp add-Zeile zum Einfügen. Wenn nicht (die VSCode-Erweiterung und die Desktop-App installieren keine Kommandozeile), druckt es stattdessen den genauen JSON-Block und die Datei, in die er gehört. In beiden Fällen landet es unter Nächste Schritte, statt vorbeizuscrollen.

Wenn ein Schritt fehlschlägt, läuft der Lauf weiter und der Fehler bekommt seine eigene Zeile. Behebe diese Zeile, führe fimemory setup erneut aus, und die Schritte, die bereits funktioniert haben, bleiben an Ort und Stelle.

Drei Befehle, die du später wollen wirst:

• fimemory onboard ist der geführte erste Schritt NACH setup: Es führt dich durch das Genehmigen deiner ersten vorgeschlagenen Bearbeitung, stellt drei Fragen darüber, wie du arbeitest, und schreibt die Antworten in den Store, dann zeigt es eine Suche, die mit deinen eigenen Fakten antwortet. Ein verdrahteter Store, der nichts über dich enthält, fühlt sich kaputt an, auch wenn nichts kaputt ist; das ist der kürzeste Weg daran vorbei.

• fimemory doctor liest die gesamte Einrichtung zurück und sagt dir in klaren Worten, was fehlt und was du dagegen tun kannst. Eine halb fertige Installation ist die häufigste Art, wie das schiefgeht.

• fimemory setup --plaintext macht dieselbe Installation mit einem UNVERSCHLÜSSELTEN Store: jede Datei in einem Texteditor lesbar, von dir und von jeder Person oder jedem Programm mit Zugriff auf den Ordner. Es ist eine echte Wahl, klar ausgesprochen, keine versteckte Herab

Grok CLI, am 2026-07-31 aus erster Hand gegen grok 0.2.117 auf der Platte verifiziert. Grok durchsucht standardmäßig ~/.claude/settings.json nach Hooks ([compat.claude] hooks = true, dokumentiert in ~/.grok/docs/user-guide/05-configuration.md, und die Tabelle „Hook Locations“ in 10-hooks.md führt diese Datei als eine globale, immer vertrauenswürdige Quelle auf). Es lädt unsere beiden Handler. Eine Injektion kann es nicht ausliefern, aus zwei unabhängigen Gründen:

1. Grok verwirft das stdout des Hooks. Das ist der entscheidende Grund, denn er lässt sich nicht umgehen. Wir haben es gemessen: vier Ausgabeformen (Claudes hookSpecificOutput, ein additionalContext auf oberster Ebene, reiner Text, systemMessage), jede davon per Markierungsdatei, die sie geschrieben hat, als tatsächlich ausgelöst bestätigt, jede ohne injizierten Kontext – verglichen mit einer Positivkontrolle, die bewies, dass die Testumgebung injizierten Kontext überhaupt sichtbar machen kann. Gemessen im headless-Modus -p; das interaktive TUI wurde nicht gemessen. Groks eigene Dokumentation klärt das nicht. 10-hooks.md sagt, nur PreToolUse und die Stopp-Ereignisse können entscheiden, und „jedes andere Ereignis ist passiv“; der Abschnitt zu passiven Hooks sagt, dass stdout „für Ereignisse wie SessionStart oder PostToolUse“ ignoriert wird – es nennt Beispiele, nicht UserPromptSubmit. Genau deshalb ist hier das Experiment die Autorität und nicht die Dokumentation.

2. Das Handler-Format hat kein args-Feld. Die Tabelle „Key Fields“ in 10-hooks.md zählt type, command, url, timeout und env auf; unser gesamter Aufruf liegt in args. Grok startet den Interpreter ohne Argumente, und dieser Prozess stirbt sofort. Das sieht behebbar aus, denn command akzeptiert einen Inline-Shell-Befehl – aber beheben heißt nur, dass der Hook überhaupt läuft. Injizieren würde er weiterhin nichts, wegen (1).

Blockiert wird in keinem der beiden Fälle etwas: Grok fällt offen aus. Aber „fällt offen aus“ ist nicht „bleibt still“. 10-hooks.md besagt, dass jeder Hook-Fehler für das Scrollback der UI aufgezeichnet wird – Sie werden also bei jedem Grok-Prompt eine Hook-Fehlerzeile sehen. Wenn Sie das nicht wollen, setzen Sie in ~/.grok/config.toml [compat.claude] hooks = false. Entfernen Sie die Handler nicht aus ~/.claude/settings.json. Das ist die Datei, die Claude Code tatsächlich verwendet, und wenn Sie sie dort entfernen, schalten Sie den einzigen Host ab, auf dem der Hook funktioniert.

Grok liest auch ~/.claude/CLAUDE.md. Eine Rules-Datei ist nicht privat gegenüber dem Host, in dessen Verzeichnis sie liegt. Groks 12-project-rules.md besagt, dass Grok bei eingeschalteter Claude-Kompatibilität (Standard) das ~/.claude/ auf Home-Ebene unter anderem nach CLAUDE.md durchsucht, und grok inspect --json hat auf einer echten Maschine genau diese Datei aufgelistet. Auf einem Claude-Code-und-Grok-Rechner erreichte der Shim-Text, der „für Claude Code“ gedacht war, also auch Grok. Das tut er jetzt nicht mehr: Wenn ein erkannter Host, der den Hook nicht ausführen kann, eine Rules-Datei gemeinsam nutzt, bekommt diese Datei die Such-zuerst-Formulierung – egal, wem sie nominell gehört. fimemory doctor meldet, welchen Inhalt jede Rules-Datei trägt, nicht nur, dass dort ein Block liegt.

Codex CLI hat Hooks. In seiner ausgelieferten Binärdatei @openai/codex 0.145.0, Stand 2026-08-01, gelesen: Die Ereignismenge umfasst user_prompt_submit, session_start, pre_tool_use und stop; die Binärdatei enthält Quellpfade unter hooks/src/events/ und einen Loader hooks/hooks.json. Wir schreiben keine Codex-Hook-Konfiguration, unser Hook läuft dort also nicht. Ob unser Handler unter Codex funktionieren würde – das Handler-Schema und ob das stdout eines user_prompt_submit-Hooks injiziert wird – ist unverifiziert, und es wird in keine Richtung eine Aussage getroffen.

Gemini CLI hat Hooks und bringt einen First-Party-Import für genau die Datei mit, die wir schreiben. In @google/gemini-cli 0.52.0, Stand 2026-08-01, gelesen: UserPromptSubmit wird auf das BeforeAgent-Ereignis von abgebildet und gemini hooks migrate liest <cwd>/.claude/settings.json und importiert dessen Hooks. Eine Warnung, falls Sie diesen Befehl verwenden: Sein Import kopiert nur command, type und timeout und lässt args weg – genau wie Grok. Führen Sie ihn Löwen in einem Verzeichnis aus, dessen .claude/settings.json unsere Handler trägt, erhalten Sie einen Node-Prozess, der bei jedem Prompt scheitert. Wir schreiben keine Gemini-Hook-Konfiguration, das geschieht also nur, wenn Sie die Migration selbst durchführen.

Windsurf und Claude Desktop: Ob sie überhaupt Hooks unterstützen, ist unverifiziert. Keines von beiden ist auf einer Maschine installiert, die wir überprüft haben. Wir schreiben für keines eine Hook-Konfiguration und beanspruchen darüber hinaus keine Einschränkung.

Cursor: Groks Dokumentation verzeichnet eine Cursor-Hooks-Datei (~/.cursor/hooks.json). Wir schreiben sie nicht und haben unseren Handler nicht dagegen getestet.

fimemory install-rules --list-hosts gibt all das für Ihre Maschine aus: welche Hosts erkannt werden, wo jeder seine Rules-Datei aufbewahrt und der jeweilige Hook-Grund pro Host mit dir Quelle.

Warum der Regelblock der entscheidende Teil ist

install-mcp verleiht Ihrem Assistenten die Fähigkeit, den Store zu lesen. install-rules --mode shim ist der Druchstieg, durch den er den Store ohne Aufforderung vorträgt, indem die relevanten Notizen vor Ihrem Prompt injiziert werden. In unseren eigenen Messungen kostet das nur einen Bruchteil davon iswhat es kostet, wenn der Assistent den Store selbst über Tool-Aufrufe durchsucht. Ohne Shimodern die Tools vorhanden und meist ungenutzt.

Die Shim-Formulierung wird nur in eine Datei geschrieben, die ausschließlich von Hosts gelesen wird, bei denen der Retrieval-Hook tatsächlich läuft – also auf einem Rechner ohne Grok CLI heute Claude Code. Jede andere Datei bekommt stattdessen den Such-zuerst-Block, die Formulierung, die jenen Assistenten sagt, fimemory_search selbst aufzurufen – denn für sie wird nichts injiziert. Installieren Sie Grok CLI, und beim nächsten setup fällt ~/.claude/CLAUDE.md zur Such-zuerst-Formulierung zurück, weil Grokanz diese Datei liest.

Related MCP server: Munin Memory

Wenn etwas falsch aussieht

fimemory doctor prüft die Store-Mode, die Schlüsselquellen, die MCP-Registrierung in jeder Host-Konfiguration, die Regelblöcke, den Retrieval-Hook, den Katalog-Index und den Zeitpunkt des letzen Speicher-Lesezugriffs. Er benennt, was fehlt und wie man es unter der Non-null, wenn etwas wirklich zerlegt ist. Ein Store, dessen Index fehlt oder Notizen, die auf der Platte liegen, nicht auflistet, ist ein Fehler und keine Wartung: Die Suche liest den Index – also heißt ein blinder Index, dass ein Assistent stillschweigend nichts findet.

Verschlüsselung ruht (Standard)

Neue Stores werden mit XChaCha20-Poly1305 hinter einem Argon2id-Passphrase versiegelt, und bei der Erstellung wird einmalig ein Passwort mit 24 Wörtern ausgegeben (fimemory encrypt bringt einen älteren oder --plaintext-Store in denselben Zustand). Verlieren Sie beide Passphrase-Satz, und die Daten ist per Design weg. Es gibt keinen Account und kein Reset – genau deshalb zählt der Satz.

Die Tools öffnen den Store mit GESTALT_PASSPHRASE. Setzen Sie die Variable so, wie Ihre eigene Shell es will:

$env:GESTALT_PASSPHRASE = 'your passphrase here'          # PowerShell
set "GESTALT_PASSPHRASE=your passphrase here"             # cmd.exe
GESTALT_PASSPHRASE='your passphrase here' fimemory list   # macOS, Linux

Ein einmaliges Entsperren macht Befehle geht etwa 8 Stunden schnell (sessionKeyCacheTtlHours, 0 deaktiviert es). fimemory lock beendet das Entsperren vorzeitig.

Die Wahrheit von Tag zwei, damit Sie nicht überrumpelt werden: Wenn dieses Zeitfenster abläuft und keine Passphrase in der Umgebung liegt, fragen CLI-Befehle erneut nach; MCP-Tools antworten auf jeden Aufruf mit einem klaren Fehler „Store ist gesperrt“, der auch Lösung nennt (setzen Sie GESTALT_PASSPHRASE dort, wo das Tool läuft, oder führen Sie fimemory unlock in einem Terminal aus; ein laufender Servernehmer m die Entsperrung beim nächsten Aufruf über, kein Neustart und nötig), erwartet wäre der pro Prompt ausgeführte Retrieval-Hook bleibt einfach still, ohne Ihren Prompt zu blockieren. fimemory doctor ist es, das diesen Zustand laut benennt. GUI-Apps (Claude Desktop und andere) lesen die Systemumgebung des Benutzers, nicht Ihr Shell-Profil – legen Sie die Variable also dort ab, wo die Desktop-Sitzung sie sehen kann.

Und die Grenze sei ehrlich genannt: Sobald Ihr Store entsperrt ist, hat ein verbundener MCP-Client einen Lesezugriff, der dem eines Dateisystem-Werkzeugs entspricht. Das ist es für jeden MCap-Server; wir sagen es deutlich.

Uninstall

Ein Befehl für jede Ebene, und jeden, der nur das berührt, das sein Installer geschrieben hat:

fimemory uninstall-mcp      # remove the MCP entry from every host config
fimemory uninstall-rules    # remove the memory rule block, nothing else in the file
fimemory uninstall-hooks    # remove our two handlers from Claude Code's settings

Einen einzigen Teardown-Befehl gibt es noch nicht – uninstall-mcp gibt daher die anderen beiden Befehole aus, und der alte Bostand bleibt auf den Bildschirm passen.

uninstall-mcp ist derselbe Scan wie install-mcp mit leerer Substitution: gleiche Hosts, gleiche Dateien, gleiche Regel – das Konfig-Verzeichnis eines Hosts entscheidet, ob es installiertist. Ersmodell löscht unseren Eintrag und nichts anderes. Eine Config, die er nicht parsen kann, wird abgelehnt und bleibt byte-idisch statt neu geschrieben; die Ablehnung ist Exit-Code 1, also stoppt fimemory uninstall-mcp && rm -rf ~/.fimemory as wenn etwas dazwischenkommt. Ein ein Host, mit nichts von uns drin, ist ein Erfolg und does with 0.

Claude Code verhält sich symmetrisch zur Installation: Wir geben claude mcp remove fimemory -s user aus und ~/.claude.json read-only nur lesen, um Ihnen zu sagen, ob dort ein Eintrag hinterlegt ist.

Reihenfolge der Passphrase, bevor Sie etwas entfernen

Wenn Sie jemals install-mcp --env-passthrough GESTALT_PASSPHRASE ausgeführt haben, liegt die Passphrase für Ihren verschlüsselten Store in Klartext in diesen Host-Konfigurationsdateien. Das Entfernen unseres Eintrags diesem mit dem Eintrag mit, und für manche Leute ist diese Config-Datei die einzig existierende Bindungsüberbrücke. Entsprechend ist es in beide Richtungen wichtig:

• Store behalten: Vergewissern Sie sich, dass Sie den Store noch öffnen können – mit einer erinnertbaren Passphrase oder Ihrer 24-Wörter-Wiederprüfphase – BEVOR Sie etwas entfernen. Führen Sie zuerst fimemory uninstall-mcp --dry-run aus. Der Befehl nennt die Variablen, die er entfernen würde, niemals ihre Werte, und schreibt nichts.

• Store verwerfen: Entfernen Sie zuerst die Konfiguration, dann den Store-Ordner. Diese Reihenfolge ist richtig und hinterlässt in keiner Config-Datei eine Passphrase.

• Claude Code eigenen Binary gibt die, das claude mcp remove die Server-Konfiguration dauerhaft löscht, inklusive Umgebungsvariablen und Headern, also nimmt der gedruckte Befehlens die Gültigkeit mit.

Der Store selbst ist Ihre Ordner – ihn zu entfernen heißt, ein Verzeichnis zu entfernen: /.fimemory(oder/.gestaltbei einer Installation vor der Umbenennnamen) bzw. den Ort, den Sie mit--home` angegeben haben. Exportieren Sie, wenn Sie die Fragmente behalten wollen.

Ihre Dateien, Ihr Ausgang

fimemory export --plaintext <dir> schreibt jede Notiz, jedes Log und jede vorgeschlagene Änderung als schlichtes ZKLAR in ordinary Markdownaußerhalb des Stores. Der Notausgang ist real und er funktioniert am ersten Tag.

Hinweis zur Benennung

Alles, was der user sieht, heißt fimemory: der Befund, der MCP-Server-Schlüssel und die Tool-IDs (fimemory_search, fimemory_get, ...). Installationen, die vor dem Renaming liegen, bleiben betriebs längst aktiv: ein Store unter ~/.gestalt, GESTALT_*-Umgebungsvariablen und ein alter MCP-Eintrag gestalt` werden immer noch erkannt und respektiert.

Lizenz

Source-cestellung verfügbar unter FSL-1.1-ALv2 (siehe LICENSE.md). Frei für Nutzung und Modifikation. Sie dürfen es nicht verkaufen **oder als konkurrierende Dienstleistung betreiben. Jede Version ist zwei Jahre nach ihrer Veröffentlichung Apache-2.0.