Codex Project Context: Persistent Memory and Shared State for OpenAI Codex
Codex reads AGENTS.md before work starts, giving it stable, repo-specific conventions. It is static text read once at the start of a run, though — it does not represent what changed mid-session or what a parallel Codex run already decided. A hosted MCP context layer adds decisions, active work, and code impact that AGENTS.md was never meant to hold.
What AGENTS.md already does well
Codex reads AGENTS.md at the repository root before work starts. It is the canonical cross-agent instruction file in Snipara's templates, meaning Claude Code and other clients can also treat it as the shared source of conventions, with CLAUDE.md or a Cursor rule layered on top as a compatibility file where a client expects one.
That makes AGENTS.md a solid place for style rules, architecture constraints, and testing conventions — anything stable enough that writing it once and reading it every run is the right tradeoff.
Where AGENTS.md stops being enough
AGENTS.md is text a person wrote. It does not update itself when a decision changes or a task moves from planned to done.
Codex reads AGENTS.md before work starts. It has no built-in way to represent what changed an hour into the session, or what a parallel Codex run already touched.
AGENTS.md is a good cross-agent convention, but each client still needs its own copy in the right place, and none of them see a teammate's session state through the file alone.
AGENTS.md can state conventions, but it cannot tell Codex which files a change is likely to affect or what a similar prior change broke.
AGENTS.md, session context, and a hosted context layer
| Layer | Scope | Updates | Shared across agents | Good for |
|---|---|---|---|---|
| AGENTS.md | Repository root, read by Codex before work starts | Manual edits only | Partially — other clients need their own copy or read the same file | Stable conventions: style rules, architecture notes, house rules |
| Codex session context | Single run or conversation | N/A — lost when the session ends | No | The current task, inside the current run |
| Hosted MCP context layer | Project, reachable by any connected MCP client | Reviewed captures, not automatic scraping | Yes — Codex, Claude Code, Cursor, and other MCP clients query the same state | Decisions, active work, code impact, verification evidence |
Before and after: starting a task in Codex
"Implement OAuth." Codex reads AGENTS.md for conventions, then answers from the prompt alone or starts reconstructing project context that a previous Codex run or another agent already worked out.
Codex opens a Start Work Brief through hosted MCP: prior decisions, active work, architecture, likely code impact, and what still needs verification, before the first edit.
How Snipara approaches this
Snipara is a context and memory layer for AI coding agents. It gives each repository a Project Brain powered by Project Intelligence, connecting decisions, active work, code impact, verification evidence and handoffs across Claude Code, Cursor, Codex, Gemini CLI and other MCP clients.
For Codex specifically, the hosted MCP endpoint is exposed as a streamable HTTP MCP server in config.toml, with the API key loaded from SNIPARA_API_KEY rather than hardcoded. Setup does not overwrite an existing AGENTS.md — generated copies are kept under .snipara/templates for merge review. The same hosted endpoint also serves ChatGPT Desktop and direct OpenAI API integrations, so Codex and ChatGPT can draw on the same reviewed project state.
Limitations
- Codex still does all the reasoning and editing — Snipara only supplies context.
- Project Intelligence briefs are reviewable evidence views, not canonical project truth or autonomous approval.
- It does not remove the need to run tests or review diffs before merging.
- Memory updates come from reviewed captures, not automatic scraping of every session.
- Snipara is not an LLM provider — you bring your own Codex client and model.
FAQ
Does Codex support MCP?
Codex config supports streamable HTTP MCP servers, using bearer auth from an environment variable such as SNIPARA_API_KEY, or a codex config.toml snippet pointed at the hosted MCP endpoint.
Is AGENTS.md enough for project memory with Codex?
AGENTS.md is a good place for stable conventions Codex should always read before starting work. It is static text, so it will not represent what changed this week or what a parallel Codex run already decided — that needs a layer outside the file.
Does Snipara overwrite AGENTS.md?
No. Snipara's setup does not overwrite an existing AGENTS.md file. Generated copies are kept under .snipara/templates for a human or agent to merge deliberately, so the file a Codex run reads stays under your control.
Can Codex share context with Claude Code or Cursor on the same repo?
Yes, through the shared hosted MCP context layer. Codex, Claude Code, and Cursor can each connect to the same project endpoint and query the same reviewed decisions, active work, and code impact, even though AGENTS.md, CLAUDE.md, and Cursor rules stay separate files.
Does this apply to ChatGPT and other OpenAI MCP clients too?
Yes. Snipara's OpenAI-compatible integration path covers ChatGPT Desktop's native MCP support and the OpenAI API directly, in addition to the Codex CLI config.toml path, all against the same hosted MCP endpoint.