OpenAI Codex crossed 3 million weekly active users by April 8, 2026, with 70 percent month-over-month growth and 5x growth since January. The product has memory now, after the April 16 update. But the memory it ships with is project-scoped, cloud-only, and locked inside OpenAI. Three approaches actually solve the problem of giving Codex memory that survives sessions, follows you across machines, and connects to the same memory your other AI tools use: built-in memories with project files, an MCP memory server, or a hybrid setup that keeps OpenAI memories for sensitive code and an MCP server for everything else. The MCP path takes about 30 seconds to set up and works with Claude, ChatGPT, Cursor and seven other clients on the same memory store.
When the Codex usage numbers hit 3 million weekly users, what you are seeing is OpenAI shipping the productivity story Anthropic shipped 18 months ago, at a scale Anthropic never reached. Codex Web, Codex Desktop on macOS and Windows, the Codex app inside ChatGPT iOS, the Codex CLI, the VS Code extension. Five surfaces, one account, the same model behind all of them. By April 16 OpenAI added persistent memory to the Desktop app, alongside Computer Use, an in-app browser, image generation and a 90+ plugin marketplace.
If you read the announcement, "persistent memory" sounds solved. It is not. There are three different problems hiding behind that label, and Codex's built-in memory only solves one of them. Here is what is actually going on, and three practical paths through it.
What "Codex memory" actually means today
OpenAI's Codex memory, launched April 16, is project-scoped. You can pin instructions, code conventions and personal preferences inside a single Codex project. The memory persists between Codex sessions for that project. If you switch projects, you start fresh. If you switch from Codex to ChatGPT, you start fresh again. If you switch from Codex Web to Codex Desktop, the memory is supposed to follow but in practice users still report drift between surfaces.
This is the same model ChatGPT uses for its consumer memory feature. It is good for what it does. It is not what most developers mean when they ask whether Codex remembers them.
What developers actually want has three layers:
The first is session memory. Inside a single conversation, can the model remember what it did three turns ago? This was a problem in 2023. It is solved.
The second is project memory. Across multiple sessions on the same task, does the model recall the conventions of the codebase, the people on the team, the decisions you made last week? Codex's built-in memory solves this for projects that live entirely inside Codex. It does not solve it if half your work is in Claude Code or Cursor.
The third is operator memory. Across every AI tool you use, can the model recall who you are, what you build, what your customers care about, what mistakes you do not want to repeat? This is the layer nobody at the model providers wants to solve, because their incentive is to lock you to their stack.
The three solutions below address layers two and three. Use what fits.
Solution 1: Codex's built-in memories with project files
Codex has two ways to remember. The Memories feature stores user-specific preferences. Project-level config files store team-shared context. Together, for code that lives entirely inside Codex, this is enough.
The setup is straightforward. Inside any Codex project, create an AGENTS.md file at the repo root. Codex reads it on every task. This is the equivalent of the CLAUDE.md pattern that Anthropic established. Common entries: tech stack, coding conventions, deploy commands, PR rules, naming rules, "never do X" warnings.
# AGENTS.md
## Stack
Next.js 15, TypeScript strict, Prisma, Postgres on port 5433.
## Conventions
- Server Actions over API routes when possible
- Tailwind utility-first, no CSS modules
- Tests via Vitest for unit, Playwright for e2e
## Never
- `prisma db push --force-reset` on any branch
- Skip the read-before-edit hook
- Push to main without `pnpm typecheck`
For personal preferences that cross projects, use the Memories panel inside Codex Settings. Pin things like "I prefer concise responses with code first, explanation after" or "always cite the line numbers when referencing code".
The limit of this approach is what I described earlier. It works inside Codex. It does not follow you to Claude or Cursor. If you live entirely in Codex, that is fine. If you do not, keep reading.
Solution 2: An MCP memory server connected to Codex
This is the path I run on. It takes 30 seconds to set up and gives Codex access to the same memory that Claude Code, Claude Desktop, Cursor, Codex CLI and seven other MCP clients read and write.
Codex supports MCP servers natively as of the late-March update. The configuration lives in ~/.codex/config.toml. Add a block like this:
[mcp_servers.memory]
url = "https://memory.studiomeyer.io/mcp"
type = "http"
That is it. No bearer token. No API key in your config. Restart Codex, run any tool that touches memory, and your browser opens a Magic Link login page. Enter your email, click the link in the email that arrives, and the OAuth flow finishes silently. Codex now has dauerhaften Zugriff auf the same memory store every other client of yours uses.
The numbers that matter: from "open config file" to "Codex queries memory" was 30 seconds in our test. The OAuth refresh token is stored in Codex's secure credential store. No token ever lives in a git repo. The same memory is reachable from Claude Desktop, Claude Code, Cursor, the Codex CLI and Goose with the same one-click login.
What you can ask Codex once memory is wired in:
- "Search my memory for past decisions about authentication."
- "What did I decide about the rate limiter last month?"
- "Remember that I prefer to ship small commits."
- "What customers did I onboard in April?"
The model now reads and writes facts to a backend that survives across surfaces. If you change your mind about the rate limiter in Claude Code on Tuesday, Codex sees the new decision on Wednesday.
The piece worth flagging: there is a known class of bugs in Codex Desktop right now where multiple chats spawn full MCP process stacks per thread (GitHub issues 11324, 14548, 18333, 20980 all track variants). Memory grows linearly with open chats. If you run 10+ Codex tabs at once, you will see the issue. The workaround is to use HTTP-transport MCP servers (like the example above) rather than stdio servers. HTTP servers run once on the network, not once per tab.
Solution 3: The hybrid setup most teams should run
If you build with Codex on customer code that has compliance requirements and you also use Codex for personal projects, you probably want both. Built-in memory for the customer project that needs to stay locked inside OpenAI's environment. MCP memory for everything else.
The way to wire this up: use Codex's Memories panel for personal cross-project preferences. Use AGENTS.md files for project conventions. Use an MCP memory server for the operator-level memory that follows you across tools. The three layers do not conflict. They cover different scopes.
Concretely, in our team setup, the MCP memory holds learnings from previous sessions, decisions about architecture, customer profiles, deployment patterns and "never do this again" warnings. The AGENTS.md files hold project-specific stack and rules. The Memories panel holds personal communication preferences. When Codex starts a task, it has access to all three.
Honest limitations
If you go down the MCP memory route, three things you should know.
First, the memory backend matters. We run our own at memory.studiomeyer.io because we built it. There are alternatives: Mem0, Letta, Zep, MemNexus. Each has different opinions on what to store, how to retrieve, and how to bill. Try at least two before committing.
Second, retrieval quality is not free. A bad memory backend gives Codex stale or irrelevant context that can degrade output quality. Look for backends that support semantic search (vector retrieval) plus full-text plus knowledge graph. Single-modality retrieval is too brittle.
Third, the OpenAI memory feature ships fast. By December 2026 we expect Codex's built-in memory to be much closer in capability to what an MCP backend offers. If you are betting on a long-term setup, the question is less "which is better right now" and more "which is portable when the landscape shifts again." MCP-based memory is portable across providers. OpenAI memory is not.
What this means for builders
The 3 million weekly Codex users are split into two groups. One group is happy with the built-in memory and never thinks about MCP. The other group is the one that figured out their AI workflow does not run inside one provider's walls. They use Claude for some things, Codex for others, Cursor for code, ChatGPT for research. For that second group, MCP memory is the load-bearing piece that makes the multi-tool workflow coherent instead of fragmented.
If you are in the first group, you are fine. The Memories feature is solid for what it covers.
If you are in the second group, the 30-second setup above is the move that compounds for the rest of 2026. Memory is the layer where context lives. Once it is wired, every AI tool you add later starts with the context already present, not from zero.
Try it
If you want to test the MCP memory path with our backend, the OAuth login is open at memory.studiomeyer.io. The free tier is 200 memory operations per month, enough to evaluate. Drop the config block above into ~/.codex/config.toml, restart Codex, log in once, and you are wired.
If you want a different backend, the same Codex config pattern works with any MCP-compliant memory server. The protocol is open. The lock-in is not in the memory layer. It is in the model layer above. Pick your memory backend on portability, not on which model maker promises memory next.
