Codex can already remember between sessions. Local memories, ChatGPT memory, project files and an external MCP store have different scopes. This guide covers three complementary options: native memories, inspectable project files and an optional MCP memory server for multiple compatible clients. An external server is not required for Codex memory and does not automatically make sensitive data safer.
Codex is available on the web, in desktop applications, the terminal and editor extensions. The surface helps determine where work and memories are stored. A shared account does not mean every local store automatically syncs. Our ChatGPT Codex guide covers getting started.
The question is not whether Codex has memory at all. What matters is which information a new task receives, who maintains it and which clients may access it. Check those three points before adding another store.
What "Codex memory" actually means today#
Local Codex clients maintain their own store under ~/.codex/memories. It is off by default and is enabled through personalization settings or the corresponding configuration, depending on the surface. /memories controls use or generation in the current chat. These files are separate from ChatGPT memory on the web or in ChatGPT Work. They are neither universally cloud-only nor automatically confined to one project.
Local storage of memory files describes their storage location. When Codex uses them as context for a model call, that context can be transmitted to the model provider. Training choices, retention and organization rules must be checked separately.
What developers actually want has three layers:
The first is session memory: context within a conversation. Context limits and compaction of long histories still apply. Also put important decisions in persistent, inspectable entries.
The second is project memory: conventions, decisions and status for a particular project. Versioned files such as AGENTS.md and decision logs are especially inspectable and can be read by other tools. Native memory does not replace authoritative team documentation.
The third is personal context across clients. A shared MCP store can help when the clients support the same server and are connected to the correct account. It is an additional architecture choice, not an automatically necessary repair.
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`
If needed, enable native memories first and inspect the files created. Ask Codex to retain preferences such as concise answers or code references with line numbers. Also write mandatory project rules in AGENTS.md. Memory supplies context, not a guarantee that every task follows a rule correctly.
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#
We also use an MCP store because several clients need the same maintained context. Setup includes server configuration, sign-in, permissions and a read test. Time depends on client and provider; our earlier 30-second measurement is not a general setup promise.
Codex supports local stdio servers and remote servers using Streamable HTTP. For a compatible OAuth server, use this URL entry in ~/.codex/config.toml:
[mcp_servers.memory]
url = "https://memory.studiomeyer.io/mcp"
Then start sign-in explicitly with codex mcp login memory. Codex opens the provider’s OAuth flow. For StudioMeyer, follow the account sign-in offered. Use codex mcp list to check that the server is configured and test a read tool call. Other servers may require bearer tokens or a different setup.
OAuth avoids manually copying an API key into the server configuration. Credential storage depends on the client and configuration. Keep configuration and authentication files out of public repositories and revoke access for clients you no longer use.
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?"
If a client actually writes a decision to the shared store, another authorized client can retrieve it later. Connection alone does not do this: check write confirmation, date and the retrieved entry. Old or conflicting memories need maintenance.
A remote HTTP server is run by its provider; a local stdio server is launched as a process by the client. This does not mean HTTP fixes every resource problem. Under high load, check client version, active threads and server logs. Match specific errors to current, relevant vendor reports.
Solution 3: A hybrid setup for suitable tasks#
For customer code with special requirements, first decide which data may go where. Native local memories, versioned project files and an external store can be combined if your organization authorizes the processing. Neither the OpenAI label nor MCP automatically protects sensitive context.
Use native memories for personal notes, AGENTS.md for project rules and optionally MCP for explicitly approved shared context. Decide which entry is authoritative when they overlap. Different stores can contain conflicting or stale information.
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 matters. A store with many features can still return stale or irrelevant entries. Test known decisions, conflicting versions and clear queries. What matters is recognizing source, recency and relevant context, not merely a list of search technologies.
Third, test portability concretely. Exportable files can be copied, and an MCP store can serve compatible clients. Check export format, deletion, permissions and retrieval quality. An open protocol alone guarantees neither a complete export nor automatic synchronization.
What this means for builders#
Native memories and project files are enough for some workflows. If you use several clients, consider a shared store as an additional option. Compare retrieval improvements with cost, maintenance and the additional recipient of data.
If native memories and maintained project files meet your needs, start there. Another connection is worthwhile when it improves specific missing access or retrieval.
Start with a known decision and check whether a second client retrieves it correctly. That test shows whether the setup improves your work. Add further clients individually and review their access.
Try it#
To test our MCP store, find current access and limits at StudioMeyer Memory. Add the URL block, run codex mcp login memory and begin with a read test. Configuring one client does not prove support in every other client.
For another backend, check transport, authentication and the MCP tools actually offered. The URL example fits compatible Streamable HTTP servers; it is not a universal block for every server. Portability also depends on export, data format, account permissions and supported clients. Test these properties before making the store a permanent part of your work.
Sources and product status#
Local Codex memories / Codex MCP and OAuth setup / Codex access and data terms
