Codex Memory v2 on by Default: What Teams Should Know

Codex now has memory switched on for new setups. On 27 October 2026, OpenAI released Codex CLI 0.165.0. Its release notes say memory v2 is "enabled by default for fresh profiles" and that Codex can import "external-agent memories" into it. In plain terms: a new Codex setup can carry notes from earlier chats into later ones, and it can pull in notes kept by another coding agent.

This article explains what that means, where it helps, where it can cause trouble, and what a team should decide before relying on it.

What is Codex memory?

Codex is OpenAI's AI coding agent. Like other agents, it starts each chat without knowing what happened in earlier ones. Memory is meant to fix that. According to OpenAI's documentation, once memories are enabled, Codex can turn useful context from past chats into local memory files, so later work can draw on things like your preferences, recurring workflows and project habits.

A few details from the docs are worth knowing:

• Codex skips chats that are still active or short-lived.
• It updates memory in the background, not at the end of every chat, and may wait until a chat has been idle. So memory can lag behind what you did a minute ago.
• A background pass can be skipped when your remaining usage allowance falls below a threshold you can set.
• Codex redacts secrets from the memory fields it generates. The docs add that you should still review memory files before sharing them, because redaction is not a guarantee.
• The files live under a "memories" folder inside the Codex home folder (by default ~/.codex/memories/). The docs call them generated state and say that editing them by hand is not the main way to control memory.
• A setting lets you keep chats that used outside context, such as tool connections or web search, out of memory.

You can also control memory for a single chat. The /memories command decides whether the current chat uses existing memories and whether it adds to future ones, without changing your global settings.

What changed on 27 October 2026?

The 0.165.0 release notes list one line that matters here: memory v2 is enabled by default for fresh profiles, with support for importing external-agent memories into it. Related entries in the changelog say imports no longer collide with a background step that merges memories, and that reading summaries of a chat's memory is available as an experimental feature.

"Fresh profile" means a new Codex setup, not one you already had. The release notes do not explain what v2 does differently from the first version, and the memory documentation page I read does not mention v2 at all. That page also still says local Codex memories are off by default and must be enabled in settings. The pages do not clearly agree, so do not assume. Open the settings on a new install and look.

The same release also turns on changing the model's reasoning effort during a conversation (for supported models), adds a built-in Google Cloud Vertex AI provider, and improves the session picker for people working across several linked copies of a project. Those are separate stories.

Can Codex import memories from Claude Code?

Partly. OpenAI's import page describes how to bring your setup from other agents into Codex. The ChatGPT desktop app can import from Claude Code, Claude Cowork and Cursor. The Codex command-line tool can import from Claude Code and Cursor. The list of things that can come across includes instruction files, skills, plugins, tool connections, hooks, subagents (helper agents), slash commands, existing project folders, project memories from Claude Code, and chats from the last 30 days.

Some limits from that page:

• The command-line import takes up to 50 chats from the last 30 days.
• The import leaves your existing agent setup unchanged, so trying it does not cost you your old setup.
• The page names memories only for Claude Code. It does not say whether Cursor or Cowork memories come across.
• The import command is unavailable during a running task or in a remote session.

The page also lists what to review afterwards: tool restrictions or permissions in imported skills and agents, tool connections that use custom sign-in (you may need to sign in again), hooks, whose behaviour may differ after import, plugins that need manual follow-up, and prompt templates that use arguments or file-path placeholders.

That list is the useful part. An import moves notes and settings, but nothing guarantees they mean the same thing in the new tool.

What this means for a team building software

Memory sounds like pure gain. For a team, it is a trade.

The good

• Less repeating yourself. If your agent learns that your project uses a certain naming style or test routine, you stop typing it every morning.
• Easier switching. A team trying Codex next to Claude Code does not have to start from nothing.
• Smoother long projects, where the same person returns to the same work for weeks.

The risks

• Memory is local. Codex keeps it in files on one machine. Two people on the same project can end up with different memories and get different behaviour from the same request.
• Memory can be stale. A note learned in March may be false in October, and nothing in the docs says Codex checks old notes against the current project.
• Secrets. Codex redacts secrets from what it writes, but the docs say redaction is not a guarantee and that you should review memory files before sharing them.
• Imported settings can behave differently. OpenAI tells you to check tool restrictions, permissions and hooks after an import, because they may not carry over the way they worked in the old tool.
• Rules hidden in memory are not rules. OpenAI's own advice: "Treat memories as a helpful recall layer, not as the only source for rules that must always apply." Must-follow team rules belong in AGENTS.md or checked-in documents, where everyone can read and review them.

One more caveat: the docs say ChatGPT Work does not use the local Codex memory store or its controls. It follows the memory settings available to your account and workspace. If your company uses both, the memory your engineers see in the command line is not what your workspace settings control.

What should you decide now?

A short checklist for a founder, product owner or tech lead:

1. Decide whether memory is on. Check the setting on every new install. Make the choice on purpose.
2. Write the rules down. Anything that must always hold (security rules, naming, what never to touch) goes in a shared file, not in memory.
3. Mind what goes into chats. Chats can feed memory, so keep passwords and keys out of them, and review memory files before sharing a Codex home folder.
4. Review imports. If someone moves over from Claude Code or Cursor, have a second person look at the permissions, hooks and sign-ins that came with them.
5. Expect lag and gaps. If the agent forgets something it should know, add it to the shared file instead of waiting for memory to catch up.

How does Atlas handle this?

Atlas is a team of AI engineers built on Claude Code, so it does not run Codex or use Codex memory. It does have its own way of carrying knowledge forward: lessons from finished work are passed to future engineers. One lesson is held back as a control, and lessons that track worse results or higher cost are retired automatically. That limits how long a weak lesson stays in use.

Atlas does not import memories from other agents. Keep the rules that matter in shared project files and read them as a team. You can see how the team works on the Atlas home page. Atlas is independent.

Conclusion

Memory is moving from an optional extra to a default for new Codex setups. That is convenient, but it adds a layer that nobody reviews unless you make time for it. Treat it as a notebook the agent keeps for itself. Keep the real rules in files your whole team can read, review memory files before sharing them, and check anything imported before you trust it.