Your Codex Session Remembers the Project, Not the Conversation

Picture a Codex scheduled task that runs every weekday morning: review open PRs, check CI, flag problems. Monday's run learns your team's conventions, the flaky test everyone ignores, the reviewer who wants summaries up top. Tuesday's run wakes up and re-learns all of it, because Monday's run never wrote any of it down where Tuesday's run could find it.

That is the honest shape of Codex memory today. It remembers the project. It does not remember the conversation.

What survives a session

Codex ships with a real persistence story, and it is worth naming exactly what it covers. Project memory files live at ~/.codex/projects/*/memory/: markdown files with frontmatter holding preferences, feedback, and project context. They load at the start of every session, so conventions and corrections carry forward.

AGENTS.md files supply project instructions. Lifecycle hooks let external tools observe a session and feed context into the next one. That hook system is the reason a small ecosystem of memory add-ons exists: Honcho captures sessions and injects relevant context at startup, Perseus Vault offers an encrypted local store through MCP tools, and mem0 connects a cloud memory layer that captures learnings at lifecycle points.

So the machinery for "remember my preferences" is there. What is missing is "remember what we did."

The two things memory files cannot hold

First, they cannot hold episodes. A memory file records that the flaky payment test gets skipped in CI summaries. It does not record the morning you spent discovering that, the two wrong hypotheses, or the decision to skip it instead of fixing it. Summaries compress away the reasoning, and reasoning is what next month's session needs when the test starts failing for a different reason.

Second, they cannot hold anything nobody wrote. Memory files grow through explicit writes. Nothing in a default Codex setup automatically records session content into them. A scheduled task that reviews PRs every morning accumulates no usable record of its own reviews unless someone built that capture. Most teams discover this around week three, when the agent starts repeating questions that were answered in week one.

Why scheduled runs feel it hardest

Interactive sessions at least have you in the loop, carrying context in your head between runs. Scheduled runs have no you. A cron task wakes with a fixed prompt and the project memory files, does its job, and goes back to sleep with nothing new persisted. Its memory of "yesterday" is whatever the prompt author remembered to include.

This is why operators who schedule Codex tasks end up as the memory layer themselves. They keep the running notes, update the prompts, curate the memory files. The automation is automated; the remembering is manual. That is the tax the whole "agents forget between runs" conversation is really about.

What the add-ons get right, and what they cost

The ecosystem's answer splits three ways, and each is honest about its price.

Hook-based capture keeps the loop automatic: sessions land in a store, relevant context returns at the next start. You pay with another service in the path and another place your full session content lives.

Local encrypted MCP memory keeps everything on your machine with explicit remember and recall tools. You pay with reach: it does not follow you to a second machine, a cloud runner, or your phone.

Cloud memory plugins give you hosted capture and retrieval over MCP. You pay with a cloud dependency and a subscription for something that touches every session.

Each one fixes the single-tool case. None of them makes memory shared across everything you run.

One memory under all of them

The fix operators keep landing on is architectural, not additive: stop bolting memory onto each agent and put one memory layer underneath all of them. Codex writes to it. Claude Code reads it. The scheduled job reads it. The n8n workflow reads it. Everything runs over MCP, so the memory follows the operator instead of being trapped in the tool.

It also needs to hold full conversation history, not just extracted facts. Facts tell next week's run what was decided. History tells it what was tried, what failed, and why the decision stuck. That is the difference between an agent that repeats your preferences and an agent that continues your work.

That is what Vilix AI provides. It is cloud-hosted with zero infrastructure for you to run. The same memory is available everywhere over MCP, so every tool you use reads and writes one store. It keeps full conversations, so recall works on what actually happened. The free plan is free forever, the Pro trial gives you seven days with no credit card, and you can export or delete your data whenever you want.

A checklist for your own setup

Before wiring Codex, or any agent, into a schedule, answer these:

• What does each run remember from the last one, without you intervening?
• Where does session content go when the session ends: nowhere, a local file, or a layer every tool can reach?
• If you switch tools next month, does the memory come with you or stay behind?

Codex will keep getting better at remembering the project. The conversation, the part where the actual work happened, still needs somewhere to live.