Your Coding Agent Has Amnesia: Memory-Augmented Generation, Explained Through Codex

The Monday Problem

On Friday, you spent forty minutes teaching Codex about your project. You explained that the backend uses PostgreSQL, that the test suite must run with make test-fast because the full suite takes twenty minutes, and that the payments module is fragile and should never be refactored without a ticket. Codex worked beautifully for the rest of the session.

On Monday, you open a new session. Codex suggests refactoring the payments module. It runs the full test suite. It asks what database you use.

Nothing broke. This is the design. Large language models are stateless functions: everything the model "knows" about your project lives in the context window of the current session, and when the session ends, that context is destroyed. The forty minutes of Friday context did not degrade or get misplaced. It never existed anywhere except in a buffer that no longer exists.

This article is about the class of techniques built to fix that, known as Memory-Augmented Generation (MAG), and about how OpenAI's Codex implements it in practice.

Why the Context Window Is Not Enough

The obvious objection: context windows are huge now, so why not just keep everything in context?

Three reasons.

First, context is per-session. A million-token window does not help you on Monday if Friday's session is gone. Window size solves a capacity problem, not a persistence problem.

Second, long context degrades. Attention effectiveness falls with distance, a failure mode documented as the "lost in the middle" phenomenon: models reliably use information at the beginning and end of a long context but miss information buried in the middle (Liu et al., 2024, https://arxiv.org/abs/2307.03172). Stuffing your entire project history into context is not only expensive, it is unreliable.

Third, context is undifferentiated. A transcript contains everything: the useful architectural decision and the fourteen failed attempts that preceded it. What you actually want to carry forward is a distilled fact ("we chose SQLAlchemy 2.0 style because of X"), not the raw log that produced it.

What MAG Is

Memory-Augmented Generation extends an LLM with an external memory system that persists across sessions and is actively managed: written to, consolidated, retrieved from, and pruned. The term was formalized in the MemOS paper (Li et al., 2025, https://arxiv.org/abs/2505.22101), which argued that LLMs need memory as a first-class architectural concern rather than an afterthought, and distinguished three memory types: parametric memory (knowledge baked into weights), activation memory (the ephemeral runtime context), and plaintext memory (external, editable knowledge). Earlier work in the same lineage includes MemGPT (Packer et al., 2023, https://arxiv.org/abs/2310.08560), which treated the LLM like an operating system paging data between a small "main context" and larger external storage.

The most useful way to understand MAG is by contrast with the pattern everyone already knows: Retrieval-Augmented Generation.

RAG retrieves. MAG remembers. RAG pulls relevant chunks from a static external corpus at query time; the corpus does not learn anything from the interaction. MAG adds a write path and a lifecycle: the system decides what is worth keeping from an interaction, merges it with what it already knows, retrieves it later, and eventually forgets what stopped being useful.

The loop on the right is the defining feature. A RAG system with a read-only vector database is not doing MAG, no matter how sophisticated the retrieval. MAG requires the write, consolidate, and forget stages. Pruning runs as a background sweep over the store rather than sitting inline in the loop, which matters later when we look at how Codex schedules it.

One terminology caveat for the careful reader: MAG is an emerging term, not a settled standard like RAG. Much of the industry still says "agent memory," and there is a separate framework called MMAG (Mixed Memory-Augmented Generation, Zeppieri, 2025, https://arxiv.org/abs/2512.01710) that organizes agent memory into five cognitive layers. Do not confuse the two.

Case Study: How Codex Remembers

Codex, OpenAI's coding agent, ships a two-layer memory model that maps almost perfectly onto the static-versus-lifecycle distinction above. Both layers are documented at https://developers.openai.com/codex.

Layer 1: AGENTS.md, the static layer

AGENTS.md is a markdown instruction file that Codex reads at the start of every session. It follows a cross-tool open convention (https://agents.md) also used by Cursor, Aider, and others. Codex discovers these files hierarchically: a global one at ~/.codex/AGENTS.md, then every AGENTS.md from the repository root down to the working directory, concatenated in path order.

This layer is for stable facts: the test command, the deploy process, code style rules, which modules are fragile. It is source-controlled, team-shareable, and fully under human control.

It is also, strictly speaking, not memory. It is configuration. A human writes it, a human maintains it, and it captures only what someone remembered to write down. The Redis quirk you discovered on Tuesday afternoon does not appear in AGENTS.md unless you put it there. And there is a hard practical limit: the combined file content is capped at 32 KiB by default, and truncation past the cap is silent.

Layer 2: Memories, the generated layer

The second layer is where Codex actually implements MAG. Codex summarizes its own prior sessions in the background and writes the results to ~/.codex/memories/, which subsequent sessions read. Note that this layer is off by default: you have to enable it in ~/.codex/config.toml (see the config reference in the official docs). The pipeline, per OpenAI's documentation and the analysis at https://mem0.ai/blog/how-memory-works-in-codex-cli, works like this:

Several design choices are worth noticing because they generalize beyond Codex:

Consolidation is asynchronous. A session must be idle for hours before it becomes eligible. Memory formation happens offline, not inline with generation, which keeps the interactive loop fast. This mirrors a broader industry pattern of background "sleep-time" consolidation.

Two models, two jobs. One model extracts candidate memories from a session; a second merges candidates into the existing store. Extraction and consolidation are different problems, and separating them lets each be tuned independently.

Forgetting is a feature. Memories that go unrecalled for thirty days are pruned. This is the counterintuitive part of MAG design: an ever-growing memory store degrades retrieval quality and accumulates stale facts, so deliberate forgetting improves the system.

Storage is plain markdown, and retrieval is grep. No vector database. At session start, Codex reads a consolidated memory_summary.md whole (third-party analysis of the open-source CLI puts a cap of roughly 5,000 tokens on this injection, a budget decision that parallels the 32 KiB AGENTS.md ceiling), then instructs the agent to grep over the long-form MEMORY.md when it needs detail. This is a real engineering tradeoff: lexical retrieval is fast, predictable, and debuggable (you can cat your agent's memory), but it cannot match a stored fact whose phrasing differs from the query. Embedding-based systems invert that tradeoff.

Trying it yourself

The experiment is simple, but two prerequisites will silently sink it if you skip them. First, Memories must be enabled in ~/.codex/config.toml; on a default install the feature is off and nothing will be written. Second, if your account is in the EEA, UK, or Switzerland, the Memories layer is not available at launch, and only the AGENTS.md layer applies.

With that out of the way:

1. Run a session and establish a project-specific fact conversationally, not via AGENTS.md. Something distinctive enough to be unambiguous, like a made-up internal codename for a service.
2. Close the session and wait past the idle window (six hours by default).
3. Inspect ~/.codex/memories/ and read memory_summary.md. Did the fact survive extraction and consolidation, and in what form?
4. Start a new session and ask a question that requires the fact. Check whether Codex recalls it unprompted, and whether it greps the long-form memory to do so.

The interesting result is not step 4 succeeding; it is comparing what you said in step 1 with what got written in step 3. The distance between the two is the extraction model's editorial judgment, and it is worth seeing with your own eyes before you trust it.

Where It Breaks

An honest treatment of MAG requires the failure modes, because they are not solved problems, in Codex or anywhere else.

Wrong memories compound. If the extraction model records a misleading conclusion in week one, the agent confidently applies it in week four. Codex does ship provenance in the narrow sense: memory entries can be traced back to the session files and line ranges they came from via citation blocks. What is missing is dispute semantics. There is no mechanism to mark a memory as contested or superseded; correction happens implicitly through consolidation, if it happens at all. Traceability tells you where a bad memory came from. It does not stop the agent from acting on it.

Staleness. Code changes; memories do not automatically notice. The memory saying "deploys go through make ship" survives the migration to a new deploy pipeline until it is either pruned by disuse or overwritten by a newer session. In the gap, the agent is confidently wrong, which is worse than ignorant.

No sharing, no sync. Codex memories are local, per-user generated state. A second laptop starts cold. A new teammate inherits nothing from the team's accumulated agent context except what made it into the checked-in AGENTS.md. This is exactly the gap that external memory layers (Mem0, and open-source projects like agentmemory) exist to fill via MCP, at the cost of adding a dependency and, for hosted options, sending your project context to a third party. Disclosure: Mem0 sells exactly this layer, so its analysis of Codex's gaps, cited above, should be read with that in mind. The gaps are real; the framing is a sales funnel.

Privacy surface. A system that automatically summarizes everything you do and writes it to disk is a system that can memorize secrets. Codex ships secret redaction in the pipeline, but redaction is pattern-matching, and pattern-matching misses things.

Conclusion

MAG is the recognition that statelessness, the property that made LLMs simple to reason about, is the main obstacle to making them useful collaborators over time. Codex's implementation shows what the pattern buys, an agent that stops asking what database you use, and how early we still are: the failure modes above are open problems, not edge cases. RAG took roughly three years to go from the 2020 paper to standard practice. Memory looks to be on a similar trajectory, and those open problems are where the next few years of work will happen.

References

1. Li, Z. et al. (2025). MemOS: An Operating System for Memory-Augmented Generation (MAG) in Large Language Models. https://arxiv.org/abs/2505.22101
2. Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. https://arxiv.org/abs/2310.08560
3. Liu, N. F. et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172
4. Zeppieri, S. (2025). MMAG: Mixed Memory-Augmented Generation for Large Language Models Applications. https://arxiv.org/abs/2512.01710
5. OpenAI. Codex documentation: AGENTS.md guide, Memories, and config reference. https://developers.openai.com/codex
6. AGENTS.md open specification. https://agents.md
7. Sangshetti, H. (2026). Codex CLI Memory: How It Works. Mem0 blog. https://mem0.ai/blog/how-memory-works-in-codex-cli (third-party analysis by a vendor selling an external memory layer; used where official docs are thin, with that conflict of interest in mind)
8. Codex Knowledge Base (2026). Codex CLI Memory Internals: Pipelines, Secret Sanitisation and Intelligent Forgetting. https://codex.danielvaughan.com/2026/04/08/codex-cli-memory-internals/ (third-party analysis of the open-source CLI; source for the citation-block provenance mechanism and the memory summary token cap)