One Memory Layer for Claude Code, Cursor, and Windsurf

Every coding agent's native persistence is tool-local. Claude Code writes a CLAUDE.md file the agent reads at session start; Windsurf's Cascade Memories live in ~/.codeium/windsurf/memories/; Codex CLI has a built-in Memories layer at ~/.codex/memories/ since v0.100.0. Each is invisible to the others. When you switch tools mid-project, or run two agents side-by-side on the same codebase, those stores do not talk.

MCP changes this because memory is externalised into a separate server process that any MCP client can call. The memory server exposes write and search tools; each agent calls those tools via its mcpServers block instead of reading its own private store. Because all four coding agents — Claude Code, Cursor, Windsurf, Codex CLI — support MCP with the same mcpServers JSON format, the practical implication is concrete: add the same server block to each tool's config, and every session — regardless of which tool opens it — reads and writes to a single shared store. No sync, no export, no re-explanation. The ai-memory-integration-surfaces overview maps the full range of integration surfaces (MCP, hooks, CLI, SDK) and when each applies; this article focuses on the MCP path, which is the one that works across all four tools.

Both tools ship a single command that writes the mcpServers config for multiple coding agents at once, removing the need to copy and edit JSON blocks by hand.

ByteRover's brv connectors install auto-configures the MCP shim for Claude Code, Cursor, and Windsurf in one step, per the CLI reference verified 2026-06-29. ByteRover stores decisions as a human-editable, git-trackable Markdown tree in your project directory. Its read path is tiered: cache lookup first, then full-text search, and LLM-powered search only as a last resort — so reads are fast without an LLM call on the primary path. The git-native format means portability is auditable: teammates can read, diff, and roll back the memory the same way they handle code. One open gap to note: ByteRover's quickstart supported-agents table also lists Codex CLI (docs.byterover.dev/quickstart, fetched 2026-06-29), but the card's connector notes currently name only Claude Code, Cursor, and Windsurf — if you rely on Codex portability, check the quickstart doc directly until the card is updated. For Windsurf-specific setup details, the memory-for-windsurf guide covers ByteRover's brv connectors install in context.

Agentmemory takes the widest coverage approach: agentmemory connect <agent> wires the MCP shim in one command for Cursor, Claude Code, Copilot CLI, Codex, Cline, Continue, Windsurf, Zed, Warp, and more than ten others, per the README verified 2026-06-29. The server runs on embedded SQLite with no external database and uses hybrid BM25 + vector + graph retrieval fused with Reciprocal Rank Fusion. Its SessionStart hook loads a project profile (top concepts, files, patterns) into conversation context within a configurable token budget, so each tool opens with relevant prior context injected automatically. The README's self-reported benchmark numbers (95.2% retrieval recall, 92% fewer tokens) are vendor claims without independent reproduction — treat them as marketing framing rather than verified performance figures.

Basic Memory takes a structural approach to portability: memory is plain Markdown files on local disk, and a knowledge graph accumulates from wikilinks between those files as agents write notes. Because the files are the truth — not a binary database — the store is inherently readable, editable, and git-trackable by anyone with access to the directory.

The MCP integration notes for Basic Memory explicitly name Claude Desktop, Claude Code, Cursor, VS Code, and Codex CLI as supported clients out of the box (PyPI page, verified 2026-06-29). The setup is a standard mcpServers block using uvx basic-memory mcp as the command. Once the server is running, each tool just needs that same block in its own config file — the Markdown store itself never moves. There are no embeddings to sync, no vector index to share, and no cloud dependency. A bundled local model handles similarity retrieval, so no external API key is required at query time.

The main licensing caveat: Basic Memory is AGPL-3.0. If you plan to incorporate it into a commercial service that users access over a network, that license requires open-sourcing your modifications. For personal or team-internal use, the practical constraint is minimal. For a tool-by-tool setup walkthrough covering Basic Memory alongside other options, see the memory-for-claude-code and memory-for-cursor companion pieces.

Claude-Mem is the most-starred tool in the coding-agent memory category and delivers real value for Claude Code users: npx claude-mem install auto-detects active agent CLIs and registers lifecycle hooks — SessionStart, UserPromptSubmit, PostToolUse, Summary, SessionEnd — for Claude Code, Codex, Antigravity CLI, OpenCode, Hermes, and Copilot. Progressive-disclosure MCP tools keep injected context token-light.

The portability limitation is architectural. Claude-Mem's capture path relies on lifecycle hooks that are specific to CLI-based agents which expose that hook interface. Cursor and Windsurf are GUI IDEs, not CLI runtimes; they do not expose the hook interface that claude-mem uses for automatic session capture. On the MCP side, the transport situation is an open gap (G2 in the open-gaps log): claude-mem ships an mcp-server.cjs, but the public docs do not show a mcp.json config block or confirm whether transport is stdio or HTTP. Until that transport is documented and confirmed, it is not possible to verify that you can point Cursor or Windsurf at the same claude-mem server instance you run for Claude Code.

If your workflow is Claude Code plus one or two other CLI-based agents (Codex, Antigravity CLI), claude-mem is the most capable and most widely adopted option for that context. If you use Cursor or Windsurf and want to share the same memory store across them, byterover or agentmemory are the cleaner choices until G2 resolves.

The right answer depends on which combination of tools you are actually running and whether team sharing matters.

If you use Claude Code plus Cursor or Windsurf and want a single memory store that works across all of them today, start with agentmemory (agentmemory connect cursor and agentmemory connect windsurf wire both in minutes) or ByteRover (brv connectors install covers Claude Code, Cursor, and Windsurf from one command). Both are verified against those tool surfaces in the catalog as of 2026-06-29.

If your team needs memory that is version-controlled, diffable, and readable by anyone in the repository without a database running, ByteRover's Markdown-in-git model or Basic Memory's Markdown-on-disk model are the strongest options. ByteRover makes memory look like code history; Basic Memory makes it look like a personal wiki. Both are local-first with optional cloud sync.

If you want the widest single-command coverage across CLI agents — Cursor, Claude Code, Codex, Windsurf, Cline, Continue, Zed, Warp — agentmemory's connect command reaches the most targets from one package.

If you are primarily in Claude Code and Codex CLI, and portability to Cursor or Windsurf is not a near-term need, claude-mem's hook-driven capture is the most automatic and most widely deployed option in that specific pair. Check the transport docs before expecting it to cover IDE-based tools.

For deeper context on MCP transport choices (local-stdio vs remote-http) and which memory servers support each, the ai-memory-mcp-servers overview covers the full field. Tool-specific walkthroughs are in memory-for-claude-code, memory-for-cursor, memory-for-windsurf, and memory-for-codex-cli.