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.