Codex Usually Does Not Need Memory
Persistent AI memory should be turned on for a clear reason, because repo context is often a better source of truth for Codex-style software work.
I usually do not want Codex to have memory turned on.
That is not because memory is useless. There are obvious cases where remembering something about the operator, the project, or the workflow can save time. If a tool keeps being told the same stable preference every day, persistent memory starts to look reasonable.
But for Codex-style software work, I want a very good reason before adding hidden state.
The repo is already memory.
It has the code. It has tests. It has docs. It has commit history. It has conventions. It has AGENTS.md, package scripts, content schemas, issue notes, planning documents, and all the little decisions that become visible once an agent actually reads the project.
That kind of memory has an important property: it can be inspected.
Hidden State Changes the Starting Point
The main problem with AI memory is not that it might remember something wrong, although that is a real problem. It is that memory changes the agent’s starting assumptions in a way that can be hard to see.
When Codex starts fresh and reads the repo, I know roughly where the context came from. If it cites a file, follows a convention, or notices a test, that context is sitting in the project. Another person can inspect it. A future agent can inspect it. I can change it with a commit.
Persistent memory is different. It can quietly nudge the work before the repo has had a chance to speak for itself.
That might be useful. It might also be stale, too broad, accidentally personal, or just mismatched to the task in front of us. The hard part is that the failure mode is subtle. The agent may sound confident because it is carrying an assumption from somewhere else.
Software work already has enough implicit context. Adding more should be intentional.
Stale Memory Makes Hidden State Worse
Project facts decay quickly.
The preferred framework changes. The deployment process changes. The naming convention changes. The thing that was true last month becomes a bad assumption after one refactor. Even personal preferences are less stable than they look, because preferences often depend on the kind of work being done.
Repo-based context handles this better because the correction path is straightforward. Update the file. Change the test. Rewrite the docs. Commit the new convention.
Memory outside the repo can lag behind the actual source of truth. If it keeps influencing future sessions, the agent may be optimizing for a project that no longer exists.
That is not a reason to ban memory everywhere. It is a reason to make memory prove its value.
The Repo Is Better Operational Memory
For software work, the best memory is usually explicit, local, and versioned.
If there is a convention Codex should follow, put it in AGENTS.md.
If there is article background, write it into docs/article-context.
If there is a tricky architecture decision, document it near the code or in a design note.
If there is behavior the system must preserve, encode it in a test.
This is slower than letting a product remember everything invisibly, but it creates a better operating model. The context travels with the repo. It survives handoffs. It can be reviewed in a pull request. It can be deleted when it stops being true.
It also keeps the agent honest. Codex has to take a fresh look at the project instead of leaning too hard on a remembered picture of the project.
That freshness is useful. It makes the initial assumptions easier to reason about. If the agent is wrong, the fix is usually to improve the repo context or point it at the right file, not to wonder which hidden memory shaped the answer.
Memory Should Be an Exception
The practical rule is simple: default to repo context, and turn on persistent memory only when the benefit is specific.
Good reasons might exist. Maybe there are stable personal preferences that apply across nearly every repo. Maybe the user has accessibility needs or workflow constraints that should not have to be restated. Maybe the tool exposes memory clearly enough that it can be inspected, edited, and scoped.
But “it might be convenient” is not enough by itself.
Convenience is real, but hidden context has a cost. It can make behavior less reproducible. It can make collaboration harder. It can make a clean review of the repo less clean. It can blur the line between what the project says and what the tool remembers.
For Codex, I would rather start from the repo.
Let the durable context be written down. Let the assumptions be visible. Let the agent read the project with fresh eyes.
Memory can be useful. But for software work, the repo should get the first chance to remember.