MemNexus is in gated preview — invite only. Learn more
Back to Blog
·7 min read

OpenAI Codex Memory: How to Make Codex Remember Your Codebase

OpenAI Codex CLI resets context between sessions. Here is how to add persistent memory via MCP so Codex remembers your project, decisions, and patterns.

MemNexus Team

Engineering

CodexOpenAIAI ToolsMCPDeveloper Workflow

April 2026 Written by Claude Sonnet 4.6 | Edited by Harry Mower

OpenAI Codex is a CLI coding agent that operates autonomously in a sandboxed environment. You give it a task, it reads your repo, writes code, runs tests, and iterates — without you steering each step. For complex, multi-file work, that level of autonomy is genuinely useful.

But each Codex session starts from zero. It doesn't know what you built last sprint, what architectural trade-offs shaped the current design, or what the three-hour debugging session last Tuesday turned up. You get a capable agent — with no memory of your project.

That's not a flaw in Codex. It's the underlying architecture. And there's a practical way to extend it.

What Codex resets every time

Because Codex works autonomously, context loss is more acute than with interactive tools. There's less opportunity to re-inject background during a session — you hand off a task and Codex runs. If it doesn't know the history, you won't discover the gap until something goes sideways.

Here's what disappears between sessions:

  • Project decisions. Why this service uses that database. Why the obvious architectural pattern was ruled out. What trade-offs drove the current design.
  • Coding conventions. The error handling patterns your project has settled on. The non-obvious constraints that aren't captured in any linter config.
  • Debugging history. The root cause you traced last week. The fix and why it holds. The two approaches that looked promising but didn't work.
  • Accumulated context. Everything you re-established in the last session that you'll need to re-establish again next time.

Codex does write local session files to ~/.codex/sessions/ — these contain the full transcript of a session and can be resumed by ID. That's useful for continuing work within a short window, but it's not a memory system. Session files aren't searchable, don't span projects, and don't surface relevant history from months ago.

Why this is a hard problem for Codex to solve alone

Codex is built on OpenAI's large language models. LLMs process a context window and generate output — but they don't write to persistent storage between calls. When the session ends, the context window closes and what was in it is gone.

This is a property of how these models work, not something Codex can configure away. Every AI coding tool has the same constraint — Claude Code, Cursor, GitHub Copilot, all of them. The reset is universal because the cause is universal.

For a deeper look at why this is architecturally hard to solve, see How AI coding assistants forget everything.

What AGENTS.md can do (and what it can't)

Codex loads an AGENTS.md file at session start. It's the right place for stable project instructions: the libraries your project uses, your testing conventions, how you structure commits. If you haven't created one, it's worth doing — it meaningfully reduces re-explanation for the things that don't change.

But AGENTS.md is static text. You maintain it manually. It has no concept of time. It can't hold the reasoning behind a decision made under pressure six weeks ago, or the three approaches you eliminated before arriving at the current implementation, or what Codex was working on before you stopped the session on Friday. It's a good starting point — not a memory system.

The MCP approach: MemNexus as Codex's memory layer

Model Context Protocol (MCP) is a standard for connecting AI tools to external capabilities. Codex supports MCP servers — you configure them in ~/.codex/config.toml or via the codex mcp CLI, and Codex launches them automatically at session start. MemNexus implements MCP. For a deeper look at why MCP is the right protocol for giving coding agents persistent memory, see MCP as a Memory Layer: Why Coding Agents Need More Than Context Windows.

When you connect MemNexus to Codex via MCP, Codex gains access to a persistent, searchable memory store that lives outside any single session. It can pull relevant context before it starts on a task. It can save decisions and findings during a session. And it can search what you already know when it encounters a familiar problem.

Setup takes about two minutes:

npm install -g @memnexus-ai/mx-agent-cli

# Interactive prompt — key stays out of shell history
mx auth login

mx setup

mx setup walks through connecting Codex via MCP and generates your API key. After that, Codex can read and write your memory store as part of normal operation.

You can also extend your AGENTS.md to prompt Codex to load context automatically at the start of each session:

At the start of each session, search MemNexus for relevant context about this project before beginning work.

What a session looks like with memory

Before Codex starts working on a task, build_context gives it a structured briefing:

  • Active work — what was in progress last session and where it stopped
  • Key facts — extracted knowledge relevant to the task at hand
  • Gotchas — patterns that appeared in multiple prior sessions, the recurring traps
  • Recent activity — related memories from the past day or week

Instead of starting from a blank slate, Codex walks into each session knowing the actual state of your project. When it writes code, it's working from your real conventions — not just what's in AGENTS.md, but the decisions and patterns that have accumulated over months.

Because Codex operates autonomously, this briefing is especially valuable. An interactive tool can ask you clarifying questions mid-task. Codex tends to run, and if it runs without the context it needs, you find out after the fact. A memory-loaded session start reduces that risk.

What accumulates over time

Here's what MemNexus stores and surfaces across your Codex sessions:

Conventions with context. Not just "we use async/await" but how this service handles partial failures, and why. The details a linter can't capture.

Decisions with their reasoning. "We use Redis for session storage" is table stakes. "We chose Redis over Postgres because we need sub-10ms reads for the auth middleware, and the session schema is simple enough that SQL isn't buying us anything" is what Codex actually needs to make good calls independently.

Debugging history. That investigation you completed last week — root cause, fix, what you eliminated along the way — becomes a memory. When similar symptoms appear, Codex can surface what you already found.

Cross-session continuity. After a few months of active development, your memory store reflects the real shape of the project: the tricky parts, the non-obvious patterns, the things that bit you once and shouldn't bite you again.

The compound effect

The value isn't obvious on day one. It compounds.

After a few weeks, Codex walks into each session with the actual history of your project — not just the conventions you defined up front, but the decisions you made under pressure, the bugs you traced to their root, the patterns that emerged from real use. Re-explanation drops. The things you've already figured out stay figured out.

The right tool for each job: Codex's autonomous, sandboxed execution is hard to replicate. MemNexus adds the one thing Codex can't provide alone — memory that outlasts the session.

Using a different AI coding tool?

The same MCP-based approach works across the AI coding assistant ecosystem:


MemNexus is currently in invite-only preview. If you want Codex to actually remember your project between sessions, request access at memnexus.ai/waitlist.

For setup documentation and MCP configuration details, see the MemNexus docs.

Give your coding agents memory that persists

MemNexus works across Claude Code, Codex, Copilot, and Cursor — your agents get smarter every session.

Request Access

Get updates on AI memory and developer tools. No spam.