Memory for AI Coding Agents: A Cross-Tool Setup That Works

Memory for AI coding agents should preserve the engineering facts that are expensive to rediscover: architectural decisions, deployment constraints, failed approaches, and the reason a workaround exists. A transcript is not that memory. Neither is a large context window. Both retain conversation; neither guarantees that the next agent receives a current, scoped, reviewable fact.

For durable project knowledge, a strong default is memory stored as files you can read, edit, diff, and self-host—not only embeddings behind a retrieval API. Meshnote exposes a markdown wiki over MCP, so Claude Code, Codex, Cursor, and other clients can maintain the same source without locking knowledge to one coding agent.

What the leading results cover—and what they miss

The two leading pages for this query are AgentMemory's GitHub repository and product page. They cover an ambitious local runtime: automatic hooks, hybrid BM25/vector/graph retrieval, consolidation, provenance, a viewer, MCP and REST interfaces, and adapters for many coding agents. The site reports 95.2% retrieval recall on LongMemEval-S and roughly 92% fewer input tokens than full-context replay. Those are vendor-reported results on its implementation, not a neutral comparison across products.

The third result is a current LocalLLaMA discussion about practical persistence. Contributors describe approaches such as markdown project notes, Basic Memory over MCP, architecture-decision records, debugging notes, and local databases. It is useful field evidence that developers want cross-session context, but it is a collection of preferences rather than an operating procedure.

What these results do not provide is a reproducible cross-agent handoff gate: write a corrected decision with one agent, retrieve it with another, verify provenance, and prove stale text no longer wins. This guide supplies that gate, plus a promotion pipeline that separates noisy session observations from durable team knowledge.

Use four layers, not one giant memory bucket

A coding workflow already has several kinds of persistence. Give each a narrow job:

Layer	Put here	Do not put here
Repository instructions	Build commands, coding conventions, safety boundaries	Long incident narratives or changing product facts
Session state	Current task, open files, temporary hypotheses	Facts that must survive compaction or a new chat
Durable project memory	Verified decisions, runbooks, domain glossary, known traps	Every tool call and speculative thought
System of record	Source code, tests, issue state, production configuration	Summaries that can override the actual system

The key boundary is promotion. An observation becomes durable memory only when it is useful beyond the current task, specific enough to test, scoped to a project, and linked to evidence. This prevents “remember everything” automation from turning retrieval into transcript archaeology. For a deeper explanation of the protocol boundary, see the MCP memory server guide.

Choose the storage model by failure mode

Option	Strength	Trade-off	Best fit
Native Claude or ChatGPT memory	Low-friction personalization inside the product	Tool-specific scope and limited team governance	Personal preferences and recurring interaction context
Mem0	Memory layer with hosted and open-source paths; current docs list integrations across many frameworks and coding agents	Requires application-level decisions about extraction, retrieval, and infrastructure	Apps needing programmatic personalized recall
Zep	Temporal context graphs, fact invalidation, summaries, and governed retrieval	More operational machinery than a small codebase may need	High-scale, time-aware user and business context
Letta	Stateful agent runtime where agents can manage memory blocks and archival memory	Memory is coupled more closely to the agent runtime	Long-lived agents whose evolving state is the product
Readable markdown over MCP	Human review, normal backups, portable files, cross-tool access	Needs editorial discipline; semantic recall at huge scale may need another index	Engineering decisions, runbooks, and shared project knowledge

These approaches are complementary. A support agent may use Zep or Mem0 for high-volume conversational recall while keeping operating policy in reviewed markdown. A stateful Letta agent may still read repository instructions. Readable memory is strongest when correctness, ownership, and deletion matter more than automatic capture volume. The Mem0 vs Letta comparison explores the runtime distinction in more detail.

Working setup: connect Claude Code and Codex to one memory

Create a Meshnote project, create an API key, and keep the key out of source control. For Claude Code, add this server entry to your user MCP configuration, replacing the placeholder:

{
  "mcpServers": {
    "meshnote": {
      "type": "url",
      "url": "https://meshnote.io/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_MESHNOTE_API_KEY>"
      }
    }
  }
}

Restart Claude Code, open /mcp, and confirm the server and tools are visible. Prefer an environment variable rather than a literal token where your client supports header expansion.

Codex CLI can read the bearer token from the environment. On macOS or Linux:

export MESHNOTE_API_KEY='mnk_replace_with_your_key'
codex mcp add meshnote   --url https://meshnote.io/mcp   --bearer-token-env-var MESHNOTE_API_KEY
codex mcp list

The resulting ~/.codex/config.toml entry is:

[mcp_servers.meshnote]
url = "https://meshnote.io/mcp"
bearer_token_env_var = "MESHNOTE_API_KEY"

On Windows, create MESHNOTE_API_KEY as a User environment variable and start Codex from a new terminal. Never commit the token. The dedicated Codex CLI memory guide covers the native AGENTS.md layer too.

Add a memory promotion contract

Put the following policy in CLAUDE.md and AGENTS.md. It makes memory use selective rather than automatic:

## Durable project memory
Before an architectural or deployment change, search the "payments-api"
Meshnote project for relevant decisions and read the source page.

Write memory only for verified facts useful in a later session.
Include scope, date, evidence, and what would invalidate the fact.
Update an existing page instead of creating a near-duplicate.
Never store secrets, tokens, customer data, or unverified hypotheses.
Source code, tests, and production config remain authoritative.

This contract is deliberately boring. It defines when to retrieve, when to write, and what wins during conflict. Those controls matter more than whether recall uses vectors, keywords, or a graph.

Run the cross-agent handoff gate

Write with Claude Code. Ask it to create decisions/payment-migrations in the payments-api project: “Run backward-compatible database migrations before switching application traffic.” Require date, scope, and a link to the migration runbook.
Read with Codex in a new process. Ask: “Search payments-api memory. What must happen before traffic switches, and which page says so?” It must name the decision and source page without seeing Claude's transcript.
Correct with Codex. Update the page to add: “Destructive cleanup runs only after the rollback window closes.” Do not create a second decision page.
Re-read with Claude Code. Start a new session and ask for the complete ordering. It must return migration, traffic switch, rollback window, then cleanup.
Inspect outside both agents. Open the markdown page, verify the edit history and evidence, then export or back it up. Search for the superseded wording and confirm it does not outrank the current decision.

A green connection icon proves transport, not memory. This gate tests persistence, cross-tool scope, correction, provenance, and human auditability. Repeat it after changing clients, retrieval settings, or storage backends.

Operational rules that prevent memory rot

Store conclusions, not exhaust. Link to logs and issues instead of copying whole transcripts.
Use stable page ownership. One canonical page per decision or subsystem reduces contradictions.
Record invalidation conditions. “Applies until queue v3 ships” is safer than an immortal assertion.
Review writes like documentation. Diff unexpected edits, restore bad versions, and test deletion.
Keep secrets elsewhere. Agent memory is context, not a credential vault.

If one agent and one repository are enough, native files may be the simplest answer. Add MCP memory when multiple tools or teammates need the same durable source. Add vector or graph retrieval when corpus scale and semantic matching justify the complexity. If readable, agent-agnostic memory is the fit, Start syncing — $8/mo. Teams that need infrastructure control can choose Self-hosted for teams from $10/seat/month.