Does Codex Have Memory? Persistent Context

Does Codex have memory?

Yes, with limits. Codex has two built-in layers. AGENTS.md files carry instructions you write, loaded at the start of every session. Memories, which are off by default, let Codex summarize eligible past chats into local files under ~/.codex/memories and inject them into later sessions on the same machine. Neither layer reaches Claude Code, Cursor, ChatGPT, or your other laptop.

Checked against OpenAI's Codex docs on September 29, 2026:

Layer	On by default?	What it keeps	Where it lives	Limits
AGENTS.md	Yes	Instructions you write	Your repo and `~/.codex`	A size cap truncates large files; nothing from conversations
Codex Memories	No, opt in	Summaries of eligible past chats	`~/.codex/memories` on one machine	Generated in a background pass after a chat goes idle; skips short or active sessions; Codex only
`codex resume`	Yes	One earlier session, continued	Local session history	You pick the session; compaction still rewrites old turns
MemoryRouter	Install once	Your request and the final answer from every completed turn	Your vault, reachable from any machine	Managed service after a 14-day trial

Sources: OpenAI docs: Memories, configuration reference, AGENTS.md guide, Codex CLI commands.

How to turn on Codex Memories

Add the feature flag to ~/.codex/config.toml:

[features]
memories = true

In the desktop app the same switch is Settings > Personalization > Enable memories. In a session, /memories decides whether the current chat can use existing memories and whether it can feed future ones. A few settings worth knowing: memories.use_memories controls injection, memories.generate_memories controls whether new chats become inputs, and memories.disable_on_external_context keeps chats that used MCP tools or web search out of memory generation. OpenAI's own guidance is to keep required rules in AGENTS.md and treat memories as a recall layer, not the source of truth.

Codex persistent context: what still gets lost

Turn Memories on and Codex is better than it was a year ago. Four gaps remain, and they are the ones that cost you time:

Timing. Memories are generated in the background once a chat has been idle for a while, not at the end of the turn. The decision you made at 4pm may not be there when you open a new session at 4:30.
One machine. The files live under your Codex home directory. Your desktop, your laptop, and a cloud task each have their own.
One tool. Claude Code, Cursor, and ChatGPT never see them. ChatGPT web memory is a separate store from local Codex memory.
Instructions are not history. AGENTS.md is the right place for build commands and conventions, and the wrong place for last week's reasoning.

That is where an external memory layer fits: the same conversation memory, written after every completed turn, readable from Codex, Claude Code, Cursor and ChatGPT on any machine. The rest of this post is how the split works and how to set it up.

Why the conversation disappears

Start a fresh Codex session in a repo you have worked in for months. Ask it to continue the caching change from Tuesday. It reads your AGENTS.md, it reads the code, and it asks you why the first cache design was rejected.

The code kept the outcome. Nothing kept the conversation.

The instinct at that point is to write Tuesday's decision into AGENTS.md. Do that a few times a week and the file becomes a junk drawer. Stable rules start sharing space with a running log of moments, every session pays the context cost of the whole thing, and the file stops being trusted as a source of truth.

Instructions, state, decisions

Three different jobs get asked of one file, and they only look similar.

Instructions are true before any task starts. Build commands and test conventions belong in AGENTS.md, and they should stay short.
State is what is true right now. The current task and anything in flight. It changes fast and deserves its own small surface, not the rules file.
Decisions are what happened in a conversation. Why the caching layer works the way it does, which approach got rejected and what made it wrong. These are episodic. You cannot know on Monday which decision from last week will matter on Friday.

Keep rules in the rules file. Put decisions in a memory layer that gets searched at the right moment.

What we built for Codex

memoryrouter-codex is the package we built for exactly this job. It connects Codex to a MemoryRouter vault, which is the private memory collection behind your key, through two mechanisms that do different things on purpose.

The first is deterministic lifecycle hooks. Before each prompt, relevant project memory is recalled and injected as context. After each completed turn, your request and the final answer are captured. This does not depend on the model deciding to call a tool, which matters, because "remember this" is not something you should have to say.

The second is a remote MCP connection at mcp.memoryrouter.ai, authenticated with OAuth. That gives Codex explicit memory tools for the moments you do want to ask directly, like searching the vault or storing something by hand.

Two design details worth knowing. Capture is message-only: your request and the final assistant response, with tool names, inputs, results, commands, and patches excluded, so your tool noise never becomes memory. And project identity is derived from the git remote, so memories from one repo do not leak into another. Worktrees of the same repository share one identity, and a clone on a new machine resolves to the same project.

The two authentication paths people mix up

This causes more confusion than anything else, so it gets its own section.

Codex uses two separate authentication paths for MemoryRouter. The browser login (codex mcp login memoryrouter) authenticates the explicit MCP tools. The automatic hooks run outside that OAuth session and need their own credential: a MemoryRouter API key supplied at install time, plus trusted command hooks inside Codex.

If you skip the key, the MCP tools can work perfectly while automatic recall and capture quietly do nothing. A successful browser login is not proof that the hooks are running. That is what /hooks, /mcp verbose, and doctor are for.

Set it up

Install the hooks with your key passed on stdin, so it never lands in shell history:

printf '%s' "$MEMORYROUTER_API_KEY" | npx -y memoryrouter-codex init --scope user --auth oauth --api-key-stdin

On macOS you can copy the key first and swap printf for pbpaste. Then sign in and choose the vault the hooks should use:

codex mcp login memoryrouter

Start Codex, run /hooks, and trust the MemoryRouter definitions. Then verify everything:

npx -y memoryrouter-codex doctor --scope user

You need Node 18 or newer and Codex 0.145.0 or newer, with 0.146.0 for the OAuth path. The key is stored under ~/.memoryrouter with owner-only permissions. It is never written to config.toml, hooks.json, AGENTS.md, or your repository. The Codex page has the short connect flow, and the documentation covers Windows, project scope, and enterprise rollout.

Prove it in two sessions

Do this on day one.

In one session, tell Codex something specific and harmless: "For the memory test, the project code phrase is amber glacier 62." Let the turn finish and close the session. Open a new Codex session in the same project and ask what the code phrase is. If the hooks are running, the new session answers from injected project memory without you pasting anything.

That exercise is the whole product test. If it fails, doctor tells you which layer is down. The two causes the documentation calls out are a hook key that was never provided and hooks that were never trusted.

What it does not do

No memory setup is honest if it only lists wins, so here are the boundaries.

The install captures from now on. It does not import your old ChatGPT or Codex conversations. There is a guided path for extracting an export, but it is experimental, not a one-click time machine.

Hooks are a lifecycle extension, not a security boundary. If you need strict isolation, use a separate vault, because the hosted MCP server does not take a project argument.

Codex cloud does not inherit your laptop's config or secrets. Project scope plus a provisioned key in the cloud environment is the documented path, and ChatGPT web never reads local ~/.codex files, so it uses MemoryRouter's separate connector.

Codex's own Memories can stay enabled. They are local to Codex by design. MemoryRouter is the cross-machine, cross-tool layer on top. If you want both layers to stay out of each other's way, memories.disable_on_external_context = true keeps chats that called MemoryRouter's MCP tools out of Codex's local memory generation.

Codex memory FAQ

Does Codex remember previous sessions? Only if you turn on Memories, and then only after a background pass on the same machine. Otherwise a new session starts from AGENTS.md and the code. codex resume continues one specific earlier session.

Where does Codex store memories? Under your Codex home directory, ~/.codex/memories/ by default. OpenAI describes the files as generated state that you can inspect but should not hand-edit as your main control.

Is there a Codex memory plugin? MemoryRouter publishes memoryrouter-codex, which installs lifecycle hooks and a remote MCP connection. It recalls before each prompt and captures each completed turn, so it does not wait for an idle pass. Other MCP memory servers also work in Codex; they are model-directed, so recall happens when the model decides to call them.

Can Codex and Claude Code share memory? Not natively. Codex Memories and Claude Code auto memory are separate, machine-local stores. Point both at one MemoryRouter vault and a decision made in either tool is available in the other. See the coding tool memory table for every tool side by side, or best memory for Codex for the full option list.

One next step

Your vault holds more than Codex. Decide something in Codex and Claude Code starts with it. Explain a project once and every connected tool begins from the same context. If the caching story at the top of this post felt familiar, fix it tonight. Create your MemoryRouter account, copy the key, and run the two commands above.