Claude Recall

Coding agents need useful project decisions across sessions without treating every past instruction as a permanent rule.

Persistent memory for coding agents, with project-scoped retrieval and controls for inspecting, correcting and retiring stored rules.

Scope and contribution

Raoul built the memory service and agent integrations in Claude Recall. The system uses SQLite for persistence and coding-agent hooks and MCP for integration. The coding agents and their underlying models are supplied by their respective vendors.

Problem and constraints

A coding session contains useful decisions alongside transient instructions. Carrying all of it into future work would add noise; carrying none of it loses project preferences and corrections. The engineering problem is choosing what to retain, where it applies, and when it should be retrieved.

Claude Recall stores structured memories with types and project identifiers. The repository includes integrations for Claude Code, Pi and Kiro, plus commands for inspecting the stored information. A shared database does not mean every project should receive every memory.

Capture, store, retrieve

Agent hooks classify candidate user text and pass durable information into a local SQLite store. Retrieval and rule injection make relevant memories available to later sessions and tool decisions. The source includes project-aware retrieval, correction handling, session checkpoints and outcome tracking.

Local storage and local-only processing are different claims. The capture code can invoke the coding agent’s CLI model, and it includes an explicitly opted-in API classification path. The privacy boundary therefore depends on the configured coding agent and classifier, not just the location of the database.

An inspectable example

The repository README illustrates a package-manager correction: a user requests pnpm, the correction is stored, and a later session retrieves it before installing a test runner. This is the project’s documented example, not a controlled before-and-after experiment or an independently reproduced session trace.

The useful engineering property is that the stored rule can be searched and inspected. That makes it possible to diagnose whether an incorrect action came from capture, scope, retrieval, stale information, or the model ignoring retrieved context.

Wrong and stale memories

The source contains explicit project identifiers, memory-management commands and a janitor path that can demote rules rather than permanently deleting them. These mechanisms make correction and retirement possible; they do not establish that automatic classification always gets the right answer.

A stale preference can be actively harmful when retrieved at the wrong moment. Memory needs an auditable lifecycle and a way to remove or supersede incorrect information, not simply an ever-growing store.

Evaluation and decision

The public code demonstrates the implemented capture, storage and retrieval mechanisms. It does not, by itself, establish improved coding accuracy, reduced token use or prevention of repeated mistakes. Those claims are deliberately absent from this case study.

The next evaluation would compare matched tasks with memory enabled and disabled, with repeated runs, fixed model settings, and checks for contamination from earlier attempts. Until then, assess Claude Recall as an inspectable memory implementation rather than a measured productivity improvement.

Practical implications

The implementation demonstrates how a coding workflow can retain inspectable, project-scoped context. It offers a concrete starting point for evaluating memory in a development workflow.

Before adoption, validate capture permissions, project separation, deletion and stale-rule handling. Compare representative tasks with memory enabled and disabled before claiming a benefit.

Evidence

View repository

Read the documented example

What this project demonstrates