OpenAI Codex hat die 3 Millionen wochenaktive User am 8. April 2026 ueberschritten, mit 70 Prozent Monat-zu-Monat-Wachstum und 5x-Wachstum seit Januar. Das Produkt hat seit dem 16.-April-Update Memory. Aber das Memory mit dem es shippt ist projekt-skopiert, nur in der Cloud und in OpenAI eingesperrt. Drei Ansaetze loesen tatsaechlich das Problem Codex Memory zu geben das Sessions ueberlebt, dir ueber Maschinen folgt und mit dem gleichen Memory verbunden ist das deine anderen KI-Tools nutzen: eingebautes Memory mit Projekt-Files, ein MCP-Memory-Server, oder ein Hybrid-Setup das OpenAI-Memory fuer sensitiven Code haelt und einen MCP-Server fuer alles andere. Der MCP-Pfad braucht etwa 30 Sekunden zum Einrichten und funktioniert mit Claude, ChatGPT, Cursor und sieben weiteren Clients auf dem gleichen Memory-Store.
Wenn die Codex-User-Zahlen 3 Millionen pro Woche treffen, siehst du wie OpenAI die Produktivitaets-Geschichte shippt die Anthropic vor 18 Monaten geshippt hat, in einer Skala die Anthropic nie erreicht hat. Codex Web, Codex Desktop auf macOS und Windows, die Codex-App in ChatGPT iOS, das Codex CLI, die VS Code Extension. Fuenf Oberflaechen, ein Account, das gleiche Modell hinter allen. Bis zum 16. April hat OpenAI dem Desktop-App persistentes Memory hinzugefuegt, neben Computer Use, einem In-App-Browser, Bildgenerierung und einem Marktplatz mit 90+ Plugins.
Wenn du die Ankuendigung liest, klingt "persistentes Memory" geloest. Ist es nicht. Hinter diesem Label verstecken sich drei verschiedene Probleme, und Codex' eingebautes Memory loest nur eines. Hier ist was tatsaechlich los ist und drei praktische Pfade dadurch.
Was "Codex Memory" heute wirklich heisst
OpenAIs Codex-Memory, gelaunched am 16. April, ist projekt-skopiert. Du kannst Anweisungen, Code-Konventionen und persoenliche Praeferenzen innerhalb eines einzelnen Codex-Projekts pinnen. Das Memory ueberlebt zwischen Codex-Sessions fuer dieses Projekt. Wenn du das Projekt wechselst, faengst du frisch an. Wenn du von Codex zu ChatGPT wechselst, faengst du wieder frisch an. Wenn du von Codex Web zu Codex Desktop wechselst, soll das Memory mitfolgen aber in der Praxis berichten User immer noch ueber Drift zwischen den Oberflaechen.
Das ist das gleiche Modell das ChatGPT fuer sein Consumer-Memory-Feature nutzt. Es ist gut fuer das was es tut. Es ist nicht das was die meisten Entwickler meinen wenn sie fragen ob Codex sich an sie erinnert.
Was Entwickler tatsaechlich wollen hat drei Schichten:
Die erste ist Session-Memory. Innerhalb eines einzelnen Gespraechs, kann sich das Modell daran erinnern was es vor drei Zuegen getan hat? Das war 2023 ein Problem. Es ist geloest.
Die zweite ist Projekt-Memory. Ueber mehrere Sessions am gleichen Task, ruft das Modell die Konventionen der Codebase ab, die Leute im Team, die Entscheidungen die du letzte Woche getroffen hast? Codex' eingebautes Memory loest das fuer Projekte die komplett innerhalb von Codex leben. Es loest es nicht wenn die Haelfte deiner Arbeit in Claude Code oder Cursor laeuft.
Die dritte ist Operator-Memory. Ueber jedes KI-Tool das du nutzt, kann sich das Modell daran erinnern wer du bist, was du baust, was deine Kunden interessiert, welche Fehler du nicht wiederholen willst? Das ist die Schicht die niemand bei den Modell-Anbietern loesen will, weil ihr Anreiz ist dich an ihren Stack zu binden.
Die drei Loesungen unten adressieren Schicht zwei und drei. Nutz was passt.
Loesung 1: Codex' eingebautes Memory mit Projekt-Files
Codex hat zwei Wege sich zu erinnern. Das Memories-Feature speichert User-spezifische Praeferenzen. Projekt-Level-Config-Files speichern team-geteilten Kontext. Zusammen, fuer 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. Uebliche Eintraege: 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 moeglich
- Tailwind utility-first, keine CSS-Module
- Tests via Vitest fuer Unit, Playwright fuer e2e
## Niemals
- `prisma db push --force-reset` auf irgendeinem Branch
- Den Read-before-Edit-Hook ueberspringen
- Auf main pushen ohne `pnpm typecheck`
Fuer persoenliche Praeferenzen die Projekte ueberkreuzen, nutze das Memories-Panel in den Codex-Settings. Pinne Sachen wie "Ich bevorzuge knappe Antworten mit Code zuerst, Erklaerung danach" oder "zitiere immer die Zeilennummern wenn du auf Code verweist".
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.
Loesung 2: Ein MCP-Memory-Server an Codex angeschlossen
Das ist der Pfad auf dem ich laufe. Es braucht 30 Sekunden zum Einrichten und gibt Codex Zugriff auf das gleiche Memory das Claude Code, Claude Desktop, Cursor, Codex CLI und sieben weitere MCP-Clients lesen und schreiben.
Codex unterstuetzt MCP-Server seit dem End-Maerz-Update nativ. Die Konfiguration lebt in ~/.codex/config.toml. Fuege einen Block wie diesen hinzu:
[mcp_servers.memory]
url = "https://memory.studiomeyer.io/mcp"
type = "http"
Das war's. Kein Bearer-Token. Kein API-Key in deiner Config. Starte Codex neu, fuehre irgendein Tool aus das Memory anfasst, und dein Browser oeffnet eine Magic-Link-Login-Seite. E-Mail eingeben, auf den Link in der ankommenden E-Mail klicken, und der OAuth-Flow schliesst sich still ab. Codex hat jetzt dauerhaften Zugriff auf den gleichen Memory-Store den jeder andere deiner Clients nutzt.
Die Zahlen die zaehlen: von "Config-Datei oeffnen" bis "Codex queryt Memory" waren 30 Sekunden in unserem Test. Das OAuth-Refresh-Token ist im sicheren Credential-Store von Codex gespeichert. Kein Token lebt jemals in einem Git-Repo. Das gleiche Memory ist von Claude Desktop, Claude Code, Cursor, dem Codex CLI und Goose mit dem gleichen Ein-Klick-Login erreichbar.
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?"
Das Modell liest und schreibt jetzt Fakten zu einem Backend das ueber Oberflaechen hinweg ueberlebt. Wenn du am Dienstag in Claude Code deine Meinung zum Rate-Limiter aenderst, sieht Codex die neue Entscheidung am Mittwoch.
Die Sache die ich erwaehnen sollte: es gibt eine bekannte Klasse von Bugs in Codex Desktop gerade wo mehrere Chats volle MCP-Prozess-Stacks pro Thread spawnen (GitHub-Issues 11324, 14548, 18333, 20980 tracken alle Varianten). Memory waechst linear mit offenen Chats. Wenn du 10+ Codex-Tabs gleichzeitig laufen hast, siehst du das Problem. Der Workaround ist HTTP-Transport-MCP-Server (wie das Beispiel oben) statt Stdio-Server zu nutzen. HTTP-Server laufen einmal im Netzwerk, nicht einmal pro Tab.
Loesung 3: Das Hybrid-Setup das die meisten Teams fahren sollten
Wenn du mit Codex an Kundencode baust der Compliance-Anforderungen hat und Codex auch fuer persoenliche Projekte nutzt, willst du wahrscheinlich beides. Eingebautes Memory fuer das Kundenprojekt das in OpenAIs Umgebung gesperrt bleiben muss. MCP-Memory fuer alles andere.
Wie du das verkabelst: nutze Codex' Memories-Panel fuer persoenliche Cross-Projekt-Praeferenzen. Nutze AGENTS.md-Files fuer Projekt-Konventionen. Nutze einen MCP-Memory-Server fuer das Operator-Level-Memory das dir ueber Tools folgt. Die drei Schichten konfligieren nicht. Sie decken verschiedene Scopes ab.
Konkret, in unserem Team-Setup, haelt das MCP-Memory Learnings aus vergangenen Sessions, Entscheidungen ueber Architektur, Kundenprofile, Deployment-Patterns und "Tu das nie wieder"-Warnungen. Die AGENTS.md-Files halten projekt-spezifischen Stack und Regeln. Das Memories-Panel haelt persoenliche Kommunikations-Praeferenzen. 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 zaehlt. Wir betreiben unser eigenes unter memory.studiomeyer.io weil wir es gebaut haben. Es gibt Alternativen: Mem0, Letta, Zep, MemNexus. Jedes hat verschiedene Meinungen darueber was zu speichern ist, wie abzurufen ist und wie abzurechnen ist. Probier mindestens zwei aus bevor du dich festlegst.
Zweitens, Retrieval-Qualitaet ist nicht gratis. Ein schlechtes Memory-Backend gibt Codex stale oder irrelevanten Kontext der die Output-Qualitaet degradieren kann. Such nach Backends die Semantic Search (Vector Retrieval) plus Volltext plus Knowledge Graph unterstuetzen. Single-Modality-Retrieval ist zu sproede.
Drittens, das OpenAI-Memory-Feature shippt schnell. Bis Dezember 2026 erwarten wir dass Codex' eingebautes Memory in der Faehigkeit deutlich naeher an dem ist was ein MCP-Backend bietet. Wenn du auf ein Langzeit-Setup wettest, ist die Frage weniger "was ist gerade besser" und mehr "was ist portabel wenn die Landschaft sich wieder verschiebt." MCP-basiertes Memory ist portabel ueber Anbieter hinweg. OpenAI-Memory ist es nicht.
Was das fuer Builder bedeutet
Die 3 Millionen wochenaktiven Codex-User sind in zwei Gruppen geteilt. Eine Gruppe ist gluecklich mit dem eingebauten Memory und denkt nie ueber MCP nach. Die andere Gruppe ist die die rausgefunden hat dass ihr KI-Workflow nicht innerhalb der Mauern eines Anbieters laeuft. Die nutzen Claude fuer manche Sachen, Codex fuer andere, Cursor fuer Code, ChatGPT fuer Recherche. Fuer diese zweite Gruppe ist MCP-Memory das tragende Stueck das den Multi-Tool-Workflow kohaerent statt fragmentiert macht.
Wenn du in der ersten Gruppe bist, bist du okay. Das Memories-Feature ist solide fuer was es abdeckt.
Wenn du in der zweiten Gruppe bist, ist das 30-Sekunden-Setup oben der Move der fuer den Rest von 2026 compounded. Memory ist die Schicht in der Kontext lebt. Sobald sie verkabelt ist, faengt jedes KI-Tool das du spaeter hinzufuegst mit dem Kontext schon vorhanden an, nicht von Null.
Probier es
Wenn du den MCP-Memory-Pfad mit unserem Backend testen willst, der OAuth-Login ist offen unter memory.studiomeyer.io. Der Free-Tier ist 200 Memory-Operationen pro Monat, genug zum Evaluieren. Wirf den Config-Block oben in ~/.codex/config.toml, starte Codex neu, logge dich einmal ein, und du bist verkabelt.
Wenn du ein anderes Backend willst, das gleiche Codex-Config-Pattern funktioniert mit jedem MCP-konformen Memory-Server. Das Protokoll ist offen. Das Lock-in ist nicht in der Memory-Schicht. Es ist in der Modell-Schicht darueber. Waehle dein Memory-Backend nach Portabilitaet, nicht danach welcher Modell-Macher als Naechstes Memory verspricht.
