Codex CLI Memory: Keep Context Across Sessions

Codex CLI memory does not survive a session restart by default — every terminal opens with an empty context window. Here is how to fix that: install the plugin, share one memory layer with Claude Code and OpenCode, and import the sessions you already have.

Why Codex CLI memory starts every session blank

Codex CLI opens every session with an empty context window. The package manager you settled on yesterday, the branch naming convention, the fact that tests run through a wrapper script — none of it carries over. You either repeat yourself at the start of every session or let the agent guess, and guessing produces diff noise you then have to review.

The cost is easy to underestimate because each correction looks small on its own. Fifteen seconds to explain the test command, a minute to reject the wrong import style, another minute to point out that migrations run in a specific order. Multiply that by every session and every developer on the team, and the real price is not the typing — it is the review cycles spent catching mistakes the agent should not have made.

That is not a Codex-specific flaw. A conversation is a context window, and that window is discarded when the session ends. Most coding agents work this way, which is why the same corrections come back week after week; why your coding agent forgets conventions covers the pattern.

Codex CLI memory moves durable facts out of the conversation and into a layer every session can query. The setup is one plugin pointed at a project.

Install the Codex CLI memory plugin

The Codex integration ships as one npm package. Run this from the root of the repository you want it to remember:

npx @audaxic/memory-codex install

The installer wires the plugin into your Codex CLI setup and connects it to an Audaxic project. You need a project key (ak_...) from your workspace; the key scopes both storage and retrieval, so use a separate project for each codebase whose conventions should stay apart. A monorepo can be one project or several, depending on which conventions are shared.

If you have not created a project or key yet, start there — the quickstart covers account setup — and keep the Codex plugin docs open while you install. Afterward the plugin runs in the background: it saves memories as you work and injects relevant ones when a session starts. There is no local server or database to maintain, and no daemon to restart when you switch projects.

What gets remembered across sessions

The plugin stores the knowledge that is expensive to re-derive:

• Preferences. Test runner, package manager, formatter, preferred libraries.
• Project decisions. Database choice, service boundaries, branch and commit conventions.
• Constraints and gotchas. Build steps that must run in order, environment variables that are easy to miss, files that should not be touched.

Memories live outside the conversation in your Audaxic project, not in Codex's context window. A new terminal, a restarted machine, or a fresh clone of the repository does not reset them, and session-start retrieval pulls in what is relevant to the current task instead of replaying yesterday's transcript.

Retrieval is targeted, so the injected context stays small: you get the conventions that apply to the code you are touching, not a summary of every conversation you have ever had. If a stored memory turns out to be wrong, the API can correct the record without disturbing the rest — PUT /update to fix a memory and DELETE /delete/{memory_id} to remove one that should never have been saved.

Retrieval is scoped to the project key, and vector search is namespace-scoped, so a memory saved in your API repository does not surface in your frontend repository. The same isolation applies at the organization level: data is isolated per organization, and Audaxic does not train on customer data.

One memory layer for Codex, Claude Code, and OpenCode

Most developers do not commit to a single agent. You might run Codex CLI on one project, Claude Code on another, and OpenCode on a third. If each tool keeps private notes, you teach the same conventions three times and the copies drift apart.

Audaxic ships plugins for all three, and they can point at the same project key:

npx @audaxic/memory-codex install
npx @audaxic/memory-claude install
npm install -g @audaxic/memory-opencode

With that setup, a constraint you explain to Codex on Monday is available to Claude Code on Tuesday. The memory layer is the shared component; the agents are clients of it. If you later drop one of them, nothing has to be migrated, because the memories were never stored inside that tool.

The API underneath is mem0-like: POST /add, POST /search, GET /list, PUT /update, and DELETE /delete/{memory_id}. That matters when a tool is not on the plugin list. MCP clients — Claude Desktop, Cursor, and Windsurf — connect to the same project with a Bearer ak_... key, and anything that can call HTTP can read and write the same memories from a script or a CI job.

Import your past Codex sessions

The plugin gives Codex memory from now on, but the sessions you already have are still worth keeping: months of decisions, fixes, and conventions that would otherwise be relearned from scratch.

The importer handles the backfill:

npm install -g @audaxic/memory-import

It imports past Claude Code, Codex, and OpenCode conversations with correct timestamps, so imported history lands in the order it happened rather than as one undated block. The main trade-off is volume: a year of history holds plenty of noise, so import it once and let retrieval surface the relevant parts instead of curating memories by hand. If you would rather start small, run the plugin for a week first and import the old history once you have a feel for what gets stored. There is a full walkthrough in import past conversations.

Verify recall and know the limits

Do not trust the demo — verify with a fact only an earlier session would know: a package manager choice, an internal service name, a naming rule. A fresh session is the fastest check that Codex CLI memory works, but also query the store directly: a search request against the data plane uses the same project key the plugin does. Data-plane calls also carry a date-based X-Api-Version header, currently 2026-09-25.

Run this check after the first week, not the first hour. Early on there is not much stored, so an empty search result says nothing about whether the pipeline works.

A practical sequence:

If a step fails, narrow it down in order: confirm the plugin is using the same project key you are querying with, confirm the memory exists with a list call, then confirm search returns it. Each check maps to one endpoint, so a failure tells you which half of the system to look at.

What counts and what it costs

There is no per-token fee. An add request is counted per memory extracted from a message batch: one /add call that extracts five memories counts as five adds. Retrieves are tiered — the first 10 memories retrieved count as one request, and each additional 10 counts as one more, so 25 retrieved memories equal 3 requests.

All plans include graph memory and unlimited projects, and billing is flat monthly — no per-token fees and no overages — so a heavy week does not produce a surprise invoice. Enterprise adds on-premise deployment on request. Full tier details live in the pricing section.

Two limits matter if you write automation around the API. Management create operations are capped at 100 per hour per IP, and failed authentication attempts are capped at 100 per four hours per IP; 429 responses include Retry-After. Normal plugin use stays well below both.

FAQ

Written by Efe — Sep 25, 2026 · More articles · X @AudaxicTech