DEV Community: nnyannya

Codex can now read Claude Code's memory

nnyannya — Fri, 24 Jul 2026 10:29:37 +0000

The problem: every AI coding agent starts from zero

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:

You spend an hour with one agent working out an architecture decision, then have to re-explain the whole thing to the other agent the next day.
You genuinely forget which tool you fixed a particular bug with.
Every time you switch tools, you're starting the conversation from a blank slate, even on the exact same project.

Each 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.

I 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.

https://github.com/nnyannya-tech/memcp

How it works

An agent's session ends
        │  (automatically)
        ▼
  Log gets parsed and normalized
        │
        ▼
 Stored in a local SQLite DB (full-text search via FTS5)
        │
        ▼
Any connected agent can search it later, via MCP

All 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):

ParseFn = Callable[[Path], tuple[Session, list[Message], list[ToolCall]]]

Adding support for a new agent means writing one function with that signature. That's the whole extension point.

memcp exposes four MCP tools that any connected agent can call:

Tool	Description
`search_memory(query, limit)`	Full-text search across all past sessions, from any source
`read_session(session_id, query, max_messages)`	Read a specific session's transcript, optionally filtered
`list_recent_sessions(limit)`	List sessions in reverse chronological order
`ingest_session(path)`	Manually ingest a specific log file

What's new: memory that crosses agent boundaries

Here'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 to wire up both agents' MCP registration in one command.

The result looks like this in practice:

── A Claude Code session, a few days ago ──
User: How did we implement JWT refresh token rotation for the auth service?
Claude: We used a sliding-window approach with Redis for token revocation.
        (session ends here)

── Today, starting a fresh Codex CLI session ──
User: How did we handle JWT refresh token rotation again?
Codex: [calls search_memory("JWT refresh token rotation")]
       Found it — a Claude Code session from a few days ago.
       You used a sliding-window approach with Redis for revocation.
       Want me to pull up the implementation details?

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.

One setup detail worth calling out: registering the MCP server makes search_memory callable, but an agent only calls it proactively — without being asked — if a project instruction tells it to. This repo's CLAUDE.md and AGENTS.md both 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 (Claude Code) or AGENTS.md (Codex CLI and other AGENTS.md-reading tools).

What works today, what doesn't yet

Being upfront about the current state:

Works:

Ingesting and parsing session logs from both Claude Code and Codex CLI
Cross-agent search and session reading via the shared MCP tools

Doesn't work yet:

Automatic ingestion on session end isn't live for Codex CLI yet — as of the current Codex CLI release, there's no SessionEnd hook 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 manually (or just using Claude Code alongside it, since its hook scans every configured source) picks up new Codex sessions.
Other agents (Cursor, Windsurf, etc.) aren't supported yet — the parser interface is designed for it, but nobody's written those parsers.
No semantic/embedding-based search yet — it's still keyword-based full-text search.

Wrapping up

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.

Feedback and PRs welcome.

https://github.com/nnyannya-tech/memcp

Claude Code Forgets Everything Between Sessions. I Built a Fix.

nnyannya — Sat, 18 Jul 2026 07:51:31 +0000

Claude Code Starts From Scratch Every Session

If you use Claude Code every day, you've probably found yourself repeating the same explanations over and over again.

Why did we choose this architecture?
Why did we reject that implementation?
What parts are we planning to improve later?

Even when you're working on the same project, Claude Code forgets everything once a session ends.

The conversation logs are still there—they're stored as JSONL files under ~/.claude/projects/—but Claude doesn't use them in future sessions. In other words, the memory exists, but the agent can't access it.

Git can tell you what changed, but it can't tell you why. The design decisions, trade-offs, and discussions that happened during development are often lost, even though they're some of the most valuable context for future work.

To solve this problem, I built an open source tool called memcp.

https://github.com/nnyannya-tech/memcp

What is memcp?

In short, memcp stores Claude Code session logs locally and lets Claude search them through MCP (Model Context Protocol).

When a session ends, its log is automatically ingested into a local SQLite database. In future sessions, Claude can call MCP tools such as search_memory to retrieve relevant context from previous conversations.

Before

User:
Why did we decide to store refresh tokens in Redis for this authentication service?

Claude:
I don't have access to previous sessions.
Could you explain the reasoning behind that decision again?

After

User:
Why did we decide to store refresh tokens in Redis for this authentication service?

Claude:
[search_memory("refresh token design")]

Found a session from June 10.

- Easier TTL management than PostgreSQL
- Better suited for high-frequency access
- Automatically removes expired tokens

That's why we chose Redis.

The goal is simple: let Claude search and remember its own past code, discussions, and design decisions instead of starting from scratch every time.

How It Works

The idea is simple.

Session ends
      │ (automatically)
      ▼
Ingest session log
      │
      ▼
Store it in a local SQLite database
      │
      ▼
Claude searches it when needed in future sessions

All data is stored locally in SQLite and is never sent to external services. There is no cloud synchronization and no telemetry.

Currently, memcp provides four MCP tools:

Tool	Description
`search_memory(query, limit)`	Full-text search across all previous sessions
`read_session(session_id, query, max_messages)`	Read a specific session (optionally filtered by a query)
`list_recent_sessions(limit)`	List recently ingested sessions
`ingest_session(path)`	Manually ingest a JSONL session log

When users say things like "earlier...", "last week...", or "we discussed this before...", Claude can proactively call search_memory to retrieve relevant context. You can also invoke these tools explicitly by asking Claude to do so.

Getting Started

Installation takes just a single command if you already have uv installed.

git clone https://github.com/nnyannya-tech/memcp.git
cd memcp
uv tool install .
memcp setup

Running memcp setup will automatically:

Create ~/.agent-memory/ and initialize the SQLite database.
Generate a default ~/.agent-memory/config.yaml.
Register the MCP server in ~/.claude.json.
Add a SessionEnd hook to ~/.claude/settings.json so logs are ingested automatically when a Claude Code session ends.
Enable automatic ingestion for all future sessions.

During setup, you'll be asked whether you'd like to import your existing session logs. If you choose Yes, memcp will backfill the history from all of your existing Claude Code projects.

After that, simply restart Claude Code. Your previous sessions will become searchable in future conversations.

Design Principles

Local-First, Zero Cloud

Coding session logs often contain project-specific context and, in some cases, sensitive information. Because of that, I decided from the beginning that everything should stay on the local machine.

All data is stored in SQLite, with no external services, no cloud synchronization, no telemetry, and minimal dependencies.

Why SQLite FTS5?

I considered using a vector database or an external search engine, but for the MVP I wanted something that would work without any additional infrastructure.

SQLite FTS5 provides fast and practical full-text search out of the box, with no extra services to run. Semantic search using embeddings is certainly appealing, but I first want to validate whether traditional full-text search is sufficient before introducing additional complexity.

A Pluggable Parser Architecture

At the moment, memcp only supports Claude Code session logs. However, I'd like to support other coding agents such as Cursor and Codex CLI in the future.

To make that possible, parsers are implemented as simple pure functions with the following signature:

ParseFn = Callable[[Path], tuple[Session, list[Message], list[ToolCall]]]

Supporting a new agent is simply a matter of implementing this interface.

Current Status

memcp is still an MVP, so here's what it can—and can't—do today.

What it can do

Automatically ingest Claude Code session logs
Perform full-text search using SQLite FTS5
Search across sessions and read specific sessions through MCP

What it can't do (yet)

Support agents other than Claude Code (e.g. Cursor, Codex)
Semantic search (embedding-based retrieval)
Automatically extract long-term memories or key decisions from sessions (currently it searches the raw logs)
Windows support (currently macOS and Linux only)

Roadmap

memcp status — View ingestion statistics (session count, last ingestion time, database size)
Support additional coding agents such as Cursor, Codex, and Cline
Hybrid search (FTS + embeddings)
Automatic memory extraction (summarize and store key decisions)
memcp search <query> — Search memories directly from the CLI without opening Claude Code

Closing Thoughts

I believe persistent memory across sessions will become a standard capability for AI coding agents.

memcp is my attempt at a simple, local-first implementation of that idea.

The project is still in its early days, and I'd love to hear your feedback.

What worked well?
What felt inconvenient?
Pull requests for supporting additional coding agents are always welcome.

If you find the project interesting, I'd really appreciate a ⭐ on GitHub, as well as any Issues or PRs.

https://github.com/nnyannya-tech/memcp