
Codex CLI 0.165.0: Memory V2 Defaults and External Agent Imports
In Codex CLI 0.165.0, Memory V2 becomes the default engine for freshly initialized profiles, enabling local asynchronous context persistence across sessions. We also explore external memory imports from tools like Claude Code and Cursor, session-level controls via /memories, and several quality-of-life CLI fixes.
Chapter 1
Memory V2 becomes the default
Ethan Park
So, Jellypod is helping make this daily show a reality, so thanks to them. Today is one default that changed in Codex CLI 0.165.0, published October 27. Memory V2 is now the default engine for freshly initialized profiles. That's PR 56211.
Maya
Back in episode 0.155.0 we covered Memory V2 as an opt in feature, with isolated storage and dual write options. What's different now is that you don't opt in anymore, if your profile is new. And the scope matters. This applies to fresh profiles. Existing profiles are not migrated automatically. So if you've had Codex installed for months, nothing flips under you.
Ethan Park
Right, and the release notes are scoped that way too. Fresh profiles only. If you want to know which side you're on, look at whether your profile was created before or after you updated.
Maya
Let's talk about what the engine does, because it explains why this is a workflow change and not just a toggle. Memory V2 doesn't stuff your past conversations into the system prompt. It processes them in asynchronous background sweeps, when sessions go idle. So the extraction happens while you're away from the keyboard, and what persists across sessions are your patterns and preferences. The prompt doesn't bloat.
Ethan Park
That's the concrete benefit. Say you tell the agent three sessions in a row that your integration tests need a particular environment variable, or that you never want a certain helper touched. Without memory, you repeat that every time. With it, a later session can recall it without you pasting it in.
Maya
Where does it live? Locally, under ~/.codex/memories/. That's on your machine. And that's a boundary to understand. It doesn't synchronize across your teammates, and it doesn't match the memory settings in ChatGPT Work enterprise workspaces. Two engineers on the same repo will have two different agent memories.
Ethan Park
Which is a double edged thing. It prevents unintended prompt leaks between people. But it also means you can't assume a teammate's agent knows what yours knows.
Maya
For control inside a session, there's the /memories command. In any active session you use it to toggle whether the turn reads from or writes to the local memory store. So if you're doing something sensitive, or you're testing a weird experiment you don't want remembered, turn writing off for that turn.
Ethan Park
And that's worth building as a habit. Before you paste anything odd into a session, check /memories. Then, separately, you can just open ~/.codex/memories/ and read what's in there. It's local files. You can inspect them.
Chapter 2
Importing memories and what to watch
Maya
Now the second half of PR 56414, which is importing memories from external agents. Codex CLI can ingest memory context and conversation history from other coding agents, Claude Code and Cursor being the examples. The CLI import pulls up to 50 conversations from the last 30 days, along with project memories.
Ethan Park
The impact is on migration. If you're adopting Codex alongside Claude Code, or after it, you don't start from zero. Repository quirks, architectural patterns, the preferences you spent weeks teaching another tool, those can come across.
Maya
In practice, you start the import through the CLI migration flow, and you do it when you're not inside a running task or a remote session. Do it from a clean prompt. Then, and this is the step people will skip, review what came across. Especially tool restrictions, hooks, and authenticated MCP servers. Those aren't just notes. They change what the agent is allowed to do, or what it can reach.
Ethan Park
Two related fixes landed with it. PR 56462 prevents memory imports from racing with the background consolidation engine. Think about it. You import a batch while the sweep is merging memories at the same time. That's a classic race. Now the import and the consolidation don't step on each other. And PR 56465 adds experimental reads of thread memory summaries, so that's early, and I wouldn't build on it yet.
Maya
Caveats. First, and OpenAI is explicit about this, memories are a recall layer, not authoritative policy. If a rule has to hold for everyone on the team, it belongs in AGENTS.md or your repository docs, checked in. Don't rely on a memory to enforce it.
Ethan Park
Second, redaction. Codex redacts recognized secrets and API tokens during background consolidation. Recognized is the key word. It's not guaranteed. So before you share a ~/.codex folder, or attach a snapshot to a bug report, audit the memory files yourself.
Maya
Third, stale context. A memory captured months ago might describe a module layout you've since refactored. The agent may confidently recall something that's no longer true. Prune the memory store when you do a big restructure. And if you import from another agent, remember those 30 days of conversations might include old assumptions too.
Ethan Park
A few smaller things in 0.165.0. PR 56308 adds a repository filter to the session picker, plus directory grouping in the agent command center. If you run multiple linked worktrees, that keeps things tidy.
Maya
PR 56330 stops queued agent messages from waking work after an interrupt, so Ctrl+C actually means stop, or when you switch to Plan mode. And PR 56132 cancels remote MCP tool requests as soon as the local response futures are dropped, which should cut down on hung backend requests.
Ethan Park
So the practical checklist is short. Update to 0.165.0. Know whether your profile is fresh. Use /memories for per turn control. Read ~/.codex/memories/ once. And keep real rules in AGENTS.md.