{"slug": "codex-can-now-read-claude-code-s-memory", "title": "Codex can now read Claude Code's memory", "summary": "A developer built memcp, an open-source tool that unifies session logs from multiple AI coding agents like Claude Code and Codex CLI into a single local SQLite database, enabling cross-agent memory sharing via the Model Context Protocol. The tool allows one agent to search and recall work done by a different agent in a different tool, eliminating the need to re-explain context when switching agents.", "body_md": "If you use more than one AI coding agent — say, Claude Code for some work and Codex CLI for other tasks — you've probably run into this:\n\nEach agent's session history lives in its own format, in its own directory, invisible to every other tool. Switching agents means switching to a different \"island\" of memory.\n\nI built **memcp**, an open-source tool that solves this: it captures session logs from multiple AI coding agents, stores them in one local SQLite database, and exposes them to any connected agent via MCP (Model Context Protocol) — so an agent can search work done by a *different* agent, in a *different* tool, and get a correct answer.\n\n[https://github.com/nnyannya-tech/memcp](https://github.com/nnyannya-tech/memcp)\n\n```\nAn agent's session ends\n        │  (automatically)\n        ▼\n  Log gets parsed and normalized\n        │\n        ▼\n Stored in a local SQLite DB (full-text search via FTS5)\n        │\n        ▼\nAny connected agent can search it later, via MCP\n```\n\nAll data stays on your machine — no cloud sync, no telemetry. Each agent gets its own log format handled by a small parser that normalizes it into a shared schema (session, message, tool call):\n\n```\nParseFn = Callable[[Path], tuple[Session, list[Message], list[ToolCall]]]\n```\n\nAdding support for a new agent means writing one function with that signature. That's the whole extension point.\n\nmemcp exposes four MCP tools that any connected agent can call:\n\n| Tool | Description |\n|---|---|\n`search_memory(query, limit)` |\nFull-text search across all past sessions, from any source |\n`read_session(session_id, query, max_messages)` |\nRead a specific session's transcript, optionally filtered |\n`list_recent_sessions(limit)` |\nList sessions in reverse chronological order |\n`ingest_session(path)` |\nManually ingest a specific log file |\n\nHere's the part I'm actually excited about. Claude Code and Codex CLI are built by different vendors, store session logs in completely different formats, and have entirely different mechanisms for registering MCP servers. Getting them to share one memory store meant writing a dedicated parser for Codex CLI's rollout-style JSONL logs, normalizing it to the same schema Claude Code's logs use, and extending `memcp setup`\n\nto wire up both agents' MCP registration in one command.\n\nThe result looks like this in practice:\n\n```\n── A Claude Code session, a few days ago ──\nUser: How did we implement JWT refresh token rotation for the auth service?\nClaude: We used a sliding-window approach with Redis for token revocation.\n        (session ends here)\n\n── Today, starting a fresh Codex CLI session ──\nUser: How did we handle JWT refresh token rotation again?\nCodex: [calls search_memory(\"JWT refresh token rotation\")]\n       Found it — a Claude Code session from a few days ago.\n       You used a sliding-window approach with Redis for revocation.\n       Want me to pull up the implementation details?\n```\n\n**A completely different vendor's tool correctly recalling work it never did, from a session it was never part of.** Seeing this actually work end-to-end was the most satisfying part of building this — the daily friction of re-explaining context every time you switch agents just disappears.\n\nOne setup detail worth calling out: registering the MCP server makes `search_memory`\n\n*callable*, but an agent only calls it proactively — without being asked — if a project instruction tells it to. This repo's `CLAUDE.md`\n\nand `AGENTS.md`\n\nboth carry a \"proactively search memory\" instruction, which is why it works unprompted here. If you want this behavior in your own projects, add the same kind of instruction to that project's `CLAUDE.md`\n\n(Claude Code) or `AGENTS.md`\n\n(Codex CLI and other AGENTS.md-reading tools).\n\nBeing upfront about the current state:\n\n**Works:**\n\n**Doesn't work yet:**\n\n`SessionEnd`\n\nhook event to attach to. The hook-registration code is already in place and will activate with zero changes once Codex ships that event; until then, running `memcp ingest-new`\n\nmanually (or just using Claude Code alongside it, since its hook scans every configured source) picks up new Codex sessions.As more people run multiple AI coding agents side by side, I think \"memory that doesn't reset when you switch tools\" is going to matter more, not less. memcp is a small, early project, but it's a real working piece of that — and I'm using it to develop itself, feeding its own development sessions back into its own memory store.\n\nFeedback and PRs welcome.", "url": "https://wpnews.pro/news/codex-can-now-read-claude-code-s-memory", "canonical_source": "https://dev.to/_548fe7f9c7fcd1125fd/codex-can-now-read-claude-codes-memory-3ek7", "published_at": "2026-07-24 10:29:37+00:00", "updated_at": "2026-07-24 10:36:04.679709+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-agents"], "entities": ["memcp", "Claude Code", "Codex CLI", "MCP", "SQLite"], "alternates": {"html": "https://wpnews.pro/news/codex-can-now-read-claude-code-s-memory", "markdown": "https://wpnews.pro/news/codex-can-now-read-claude-code-s-memory.md", "text": "https://wpnews.pro/news/codex-can-now-read-claude-code-s-memory.txt", "jsonld": "https://wpnews.pro/news/codex-can-now-read-claude-code-s-memory.jsonld"}}