Codex kann sich bereits zwischen Sitzungen erinnern. Die lokale Memory-Funktion, ChatGPT-Memory, Projektdateien und ein externer MCP-Speicher haben jedoch unterschiedliche Geltungsbereiche. Dieser Leitfaden zeigt drei kombinierbare Wege: native Memories, nachvollziehbare Projektdateien und optional einen MCP-Memory-Server für mehrere kompatible Clients. Ein externer Server ist keine Voraussetzung für Codex-Memory und macht sensible Daten nicht automatisch sicherer.
Codex gibt es im Web, in Desktop-Anwendungen, im Terminal und in Editor-Erweiterungen. Die Oberfläche entscheidet mit, wo Arbeit und Erinnerungen gespeichert werden. Ein gemeinsames Konto bedeutet keine automatische Synchronisierung jedes lokalen Speichers. Unsere ChatGPT-Codex-Anleitung erklärt den Einstieg.
Die Frage ist deshalb nicht, ob Codex überhaupt Memory hat. Entscheidend ist, welche Informationen ein neuer Task erhält, wer sie pflegt und welche Clients darauf zugreifen dürfen. Prüfe diese drei Punkte, bevor du einen weiteren Speicher anbindest.
Was "Codex Memory" heute wirklich heisst#
Lokale Codex-Clients führen einen eigenen Memory-Speicher unter ~/.codex/memories. Er ist standardmäßig ausgeschaltet und wird je nach Oberfläche in den Personalisierungseinstellungen oder über die entsprechende Konfiguration aktiviert. Mit /memories lässt sich die Nutzung beziehungsweise Erstellung im aktuellen Chat steuern. Diese Dateien sind getrennt von ChatGPT-Memory im Web oder in ChatGPT Work. Sie sind weder pauschal cloud-only noch automatisch auf ein einziges Projekt begrenzt.
Lokale Speicherung der Erinnerungsdateien ist eine Aussage über den Speicherort. Wenn Codex daraus Kontext für einen Modellaufruf nutzt, kann dieser Kontext an den Modellanbieter übertragen werden. Trainingswahl, Aufbewahrung und organisatorische Vorgaben sind davon getrennt zu prüfen.
Was Entwickler tatsächlich wollen hat drei Schichten:
Die erste ist Session-Memory: Kontext innerhalb eines Gesprächs. Auch hier gelten Kontextgrenzen und gegebenenfalls Verdichtung langer Verläufe. Eine wichtige Entscheidung gehört zusätzlich in einen dauerhaften, überprüfbaren Eintrag.
Die zweite ist Projekt-Memory: Konventionen, Entscheidungen und Stand eines bestimmten Projekts. Versionierte Dateien wie AGENTS.md und Entscheidungsprotokolle sind dafür besonders nachvollziehbar und können auch von anderen Werkzeugen gelesen werden. Native Memory ersetzt diese verbindliche Teamdokumentation nicht.
Die dritte ist persönlicher Kontext über mehrere Clients. Ein gemeinsamer MCP-Speicher kann dafür sinnvoll sein, wenn die verwendeten Clients denselben Server unterstützen und mit dem richtigen Konto verbunden sind. Er ist eine zusätzliche Architekturentscheidung, keine automatisch notwendige Reparatur.
Die drei Lösungen unten adressieren Schicht zwei und drei. Nutz was passt.
Lösung 1: Codex' eingebautes Memory mit Projekt-Files#
Codex hat zwei Wege sich zu erinnern. Das Memories-Feature speichert User-spezifische Präferenzen. Projekt-Level-Config-Files speichern team-geteilten Kontext. Zusammen, für Code der komplett in Codex lebt, ist das genug.
Das Setup ist einfach. In jedem Codex-Projekt, lege eine AGENTS.md-Datei im Repo-Root an. Codex liest sie bei jedem Task. Das ist das Aequivalent zum CLAUDE.md-Pattern das Anthropic etabliert hat. Übliche Einträge: Tech-Stack, Coding-Konventionen, Deploy-Befehle, PR-Regeln, Naming-Regeln, "Niemals X tun"-Warnungen.
# AGENTS.md
## Stack
Next.js 15, TypeScript strict, Prisma, Postgres auf Port 5433.
## Konventionen
- Server Actions vor API-Routes wenn möglich
- Tailwind utility-first, keine CSS-Module
- Tests via Vitest für Unit, Playwright für e2e
## Niemals
- `prisma db push --force-reset` auf irgendeinem Branch
- Den Read-before-Edit-Hook überspringen
- Auf main pushen ohne `pnpm typecheck`
Aktiviere bei Bedarf zuerst die native Memory-Funktion und prüfe die entstandenen Dateien. Bitte Codex, Präferenzen wie knappe Antworten oder Code mit Zeilenverweisen zu berücksichtigen. Verbindliche Projektregeln schreibst du zusätzlich in AGENTS.md. Memory ist ein Kontextangebot, keine Garantie, dass eine Regel in jedem Task korrekt befolgt wird.
Die Grenze dieses Ansatzes ist was ich vorhin beschrieben habe. Es funktioniert in Codex. Es folgt dir nicht zu Claude oder Cursor. Wenn du komplett in Codex lebst, ist das in Ordnung. Wenn nicht, lies weiter.
Lösung 2: Ein MCP-Memory-Server an Codex angeschlossen#
Wir nutzen zusätzlich einen MCP-Speicher, weil mehrere unserer Clients denselben gepflegten Kontext brauchen. Die Einrichtung umfasst Server-Konfiguration, Anmeldung, Berechtigungen und einen lesenden Test. Die Dauer hängt von Client und Anbieter ab; unsere frühere 30-Sekunden-Messung ist keine allgemeine Einrichtungszusage.
Codex unterstützt lokale Stdio-Server und Remote-Server über Streamable HTTP. Für einen kompatiblen OAuth-Server kannst du den folgenden URL-Eintrag in ~/.codex/config.toml verwenden:
[mcp_servers.memory]
url = "https://memory.studiomeyer.io/mcp"
Starte danach die Anmeldung ausdrücklich mit codex mcp login memory. Codex öffnet den OAuth-Ablauf des Anbieters. Bei StudioMeyer folgst du der angebotenen Kontoanmeldung. Prüfe anschließend mit codex mcp list, ob der Server eingetragen ist, und teste einen lesenden Werkzeugaufruf. Andere Server können Bearer-Token oder eine andere Einrichtung verlangen.
OAuth vermeidet einen manuell in die Server-Konfiguration kopierten API-Schlüssel. Wie Zugangsdaten gespeichert werden, hängt von Client und Konfiguration ab. Halte Konfigurations- und Anmeldedateien aus öffentlichen Repositories heraus und entziehe nicht mehr benötigten Clients den Zugriff.
Was du Codex fragen kannst sobald Memory verkabelt ist:
- "Such in meinem Memory nach vergangenen Entscheidungen zur Authentifizierung."
- "Was hatte ich letzten Monat zum Rate-Limiter entschieden?"
- "Merk dir dass ich kleine Commits bevorzuge."
- "Welche Kunden habe ich im April onboarded?"
Wenn ein Client eine Entscheidung tatsächlich in den gemeinsamen Speicher geschrieben hat, kann ein anderer berechtigter Client sie später abrufen. Das geschieht nicht allein durch die Verbindung: Prüfe Schreibbestätigung, Datum und den gefundenen Eintrag. Alte oder widersprüchliche Erinnerungen müssen gepflegt werden.
Ein Remote-HTTP-Server wird vom Anbieter betrieben; ein lokaler Stdio-Server wird vom Client als Prozess gestartet. Daraus folgt keine pauschale Zusage, dass HTTP alle Ressourcenprobleme löst. Bei hoher Last prüfe Client-Version, aktive Threads und Server-Logs. Konkrete Fehlermeldungen sollten mit einer aktuellen, passenden Hersteller-Meldung abgeglichen werden.
Lösung 3: Ein Hybrid-Setup für passende Aufgaben#
Für Kundencode mit besonderen Vorgaben legst du zuerst fest, welche Daten wohin dürfen. Native lokale Memories, versionierte Projektdateien und ein externer Speicher können kombiniert werden, sofern die Organisation diese Verarbeitung erlaubt. Sensibler Kontext ist weder durch das Label OpenAI noch durch MCP automatisch geschützt.
Nutze native Memories für persönliche Hinweise, AGENTS.md für Projektregeln und optional MCP für ausdrücklich freigegebenen gemeinsamen Kontext. Lege bei Überschneidungen fest, welcher Eintrag maßgeblich ist. Unterschiedliche Speicher können widersprüchliche oder veraltete Angaben enthalten.
Konkret, in unserem Team-Setup, hält das MCP-Memory Learnings aus vergangenen Sessions, Entscheidungen über Architektur, Kundenprofile, Deployment-Patterns und "Tu das nie wieder"-Warnungen. Die AGENTS.md-Files halten projekt-spezifischen Stack und Regeln. Das Memories-Panel hält persönliche Kommunikations-Präferenzen. Wenn Codex einen Task startet, hat es Zugriff auf alle drei.
Ehrliche Limitierungen#
Wenn du den MCP-Memory-Pfad gehst, drei Dinge die du wissen solltest.
Erstens, das Memory-Backend zählt. Wir betreiben unser eigenes unter memory.studiomeyer.io weil wir es gebaut haben. Es gibt Alternativen: Mem0, Letta, Zep, MemNexus. Jedes hat verschiedene Meinungen darüber was zu speichern ist, wie abzurufen ist und wie abzurechnen ist. Probier mindestens zwei aus bevor du dich festlegst.
Zweitens, die Abrufqualität zählt. Ein Speicher mit vielen Funktionen kann trotzdem veraltete oder irrelevante Einträge liefern. Prüfe ihn mit bekannten Entscheidungen, widersprüchlichen Fassungen und klaren Suchfragen. Entscheidend ist, ob Quelle, Aktualität und passender Kontext zuverlässig erkennbar sind, nicht allein eine Liste von Suchtechnologien.
Drittens, Portabilität muss konkret getestet werden. Exportierbare Dateien lassen sich kopieren, und ein MCP-Speicher kann mehreren kompatiblen Clients dienen. Prüfe Exportformat, Löschung, Berechtigungen und Abrufqualität. Ein offenes Protokoll allein garantiert weder einen vollständigen Datenexport noch automatische Synchronisierung.
Was das für Builder bedeutet#
Für manche Workflows reichen native Memories und Projektdateien aus. Wer mehrere Clients nutzt, kann zusätzlich einen gemeinsamen Speicher prüfen. Vergleiche dabei den tatsächlich verbesserten Abruf mit Kosten, Pflege und dem zusätzlichen Datenempfänger.
Wenn native Memories und gepflegte Projektdateien deinen Bedarf decken, beginne damit. Eine zusätzliche Verbindung lohnt sich erst, wenn sie einen konkreten fehlenden Zugriff oder Abruf verbessert.
Beginne mit einer bekannten Entscheidung und prüfe, ob ein zweiter Client sie korrekt findet. Erst dieser Test zeigt, ob das Setup deinen Arbeitsalltag verbessert. Füge weitere Clients einzeln hinzu und kontrolliere deren Zugriff.
Probier es#
Wenn du unseren MCP-Speicher testen möchtest, findest du den aktuellen Zugang und die geltenden Limits auf StudioMeyer Memory. Trage den URL-Block ein, führe codex mcp login memory aus und teste zuerst lesend. Die Einrichtung eines einzelnen Clients ist kein Nachweis für die Unterstützung jedes anderen Clients.
Für einen anderen Backend-Anbieter prüfst du Transport, Authentifizierung und die tatsächlich angebotenen MCP-Werkzeuge. Das URL-Beispiel passt zu kompatiblen Streamable-HTTP-Servern; es ist kein Universalblock für jeden Server. Portabilität hängt außerdem von Export, Datenformat, Kontorechten und den unterstützten Clients ab. Teste diese Eigenschaften, bevor du den Speicher zum festen Bestandteil deiner Arbeit machst.
Quellen und Produktstand#
Lokale Codex-Memories / Codex-MCP und OAuth-Einrichtung / Codex-Zugang und Datenbedingungen
