The best memory tool for Claude Code depends on what actually forgot

The honest answer is that Claude Code already has two memory systems, and most people asking this question have not run out of either one. CLAUDE.md is the one you write, auto memory is the one Claude writes, and between them they cover almost everything the tools ranked on the first page of results are sold to fix. What they do not cover is the one case that genuinely needs a tool, which is memory that several people have to read and that only some of them should. That case is what Baalda is built for, and it is the half of this question nobody on that results page answers.

So this post is a diagnosis before it is a comparison. Work out what actually forgot, and the shortlist usually gets shorter.

What does Claude Code already remember without any tool?

Two things, and they are not the same thing.

Anthropic's own memory documentation opens by naming both: "Each Claude Code session begins with a fresh context window. Two mechanisms carry knowledge across sessions", which are "CLAUDE.md files: instructions you write to give Claude persistent context" and "Auto memory: notes Claude writes itself based on your corrections and preferences".

That table is quoted from the documentation, and the last row is the part people miss. Auto memory is not a retrieval system you query. The index is read into every session up to a ceiling, with topic files pulled in as needed.

Auto memory writes four kinds of note, recorded as a type field in each file's frontmatter: user for "your role, expertise, and working preferences", feedback for "corrections you give Claude and approaches you confirm", project for "ongoing work, deadlines, and decisions that Claude can't derive from the code or git history", and reference for "where to find information outside the project". It deliberately skips what it could work out for itself: "Claude skips anything it can derive from the codebase, such as architecture, file paths, or debugging fixes."

The files are at ~/.claude/projects/<project>/memory/, with a MEMORY.md index and one file per memory. They are not a database. The documentation is explicit: "Auto memory files are plain markdown you can edit or delete at any time." Run /memory in a session to browse them, toggle the feature, or open the folder.

Before you install anything, open that folder and read what is in it. A surprising number of "Claude Code keeps forgetting" complaints turn out to be auto memory switched off, or a CLAUDE.md that never loaded, which /context will tell you.

And then the sentence that decides the rest of this post, straight from the same page: "Auto memory is machine-local. All worktrees and subdirectories within the same git repository share one auto memory directory. Files are not shared across machines or cloud environments."

That is not a defect. It is a scope. It is also the exact point at which a tool starts being the right answer.

Which layer is your problem at: a file, a skill, a plugin or a server?

Four words get used interchangeably in this search, and they are four different things.

Anthropic's plugins documentation settles it in one line: "Skills, subagents, hooks, and MCP servers all work on their own, without a plugin." A plugin is packaging, not a capability. It is "a directory of skills, agents, hooks, MCP servers, or other components that Claude Code installs and loads as one unit", and you want one "when you want several skills, subagents, hooks, or MCP servers packaged as one unit".

The skills documentation draws the line that matters for memory specifically: "Unlike CLAUDE.md content, a skill's body loads only when it's used, so long reference material costs almost nothing until you need it." If your problem is that the team's style guide is eating a quarter of your context window, that is a layer problem, and the fix is a skill, not a memory product.

Plugins carry a standing cost that is easy to miss. For everything a plugin bundles that Claude can invoke on its own, "the name and description are in Claude's context on every turn so that Claude knows it exists. Those tokens count toward your usage and leave less room in the context window even in sessions where nothing from the plugin runs."

And one line from that page is worth holding onto, because it comes back later: "Permissions: what the plugin runs, it runs as you."

Baalda sits on the bottom row. It is an MCP server over a vault of plain markdown files, so the team's notes are fetched by tool call rather than carried, and nothing is in context until something asks for it.

What do the memory tools on that first page actually store?

Four real answers, and they are not competing implementations of one idea.

claude-mem hangs off Claude Code's lifecycle hooks. Its README describes it as something that "Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions", across five lifecycle hooks, into a "SQLite Database" storing "sessions, observations, summaries", with optional backup to its own cloud. It is a good answer to "I keep re-explaining this repository to myself". It documents no team or multi-user memory sharing.

The official MCP memory server from the Model Context Protocol project is "A basic implementation of persistent memory using a local knowledge graph", built from entities, relations and observations, exposing create_entities, add_observations, search_nodes and the rest. It persists to a JSONL file whose path is set by MEMORY_FILE_PATH, defaulting to memory.jsonl in the server directory. One file, one process, whoever is running it.

Mem0 and the hosted memory layers alongside it extract facts rather than keeping text. That whole category, and what it does to a record a person later needs to correct, is covered in how to give an AI agent memory a person can open, so this post will not relitigate it.

Basic Memory is the one on that page closest to what we think is right, and it deserves saying plainly. Its pitch is "Plain text on your disk. Forever.", your knowledge "lives as Markdown files that both you and your AI can read, write, and search", reached over MCP. If you are one person and you want your agent's memory in files you own, it is a straightforwardly good answer and you may not need to read further.

When is a memory server actually the right answer?

When the thing that forgot was the team, not the session.

Here is the test, and it takes about ten seconds. Say out loud what you wish Claude had remembered, then ask who else needs to know it.

• "That we use pnpm, not npm." Nobody else needs it from your agent, because it belongs in CLAUDE.md where every teammate's agent reads it too. No tool.
• "That I prefer short commit messages." That is exactly what auto memory's feedback type is for, it is already on by default locally, and it is yours alone. No tool.
• "The entire 40-page onboarding guide, without it eating my context." A layer problem. Make it a skill. No tool.
• "That staging is restored from a snapshot and not seeded, which is why the test data looked wrong." Every engineer on the team needs that, it is nowhere in the code, and right now it exists in exactly one person's machine-local memory directory. That is the one.

Only the fourth needs a server, and it needs a particular one. It needs the memory to be something a human can open and fix, which rules out the extraction layers, and it needs the memory to reach more than one machine, which rules out everything native. What breaks when the second person arrives covers the concurrency half of that, where two sessions write the same note. This post is about the half before it: who is allowed to see the note at all.

Who can read the memory your agent wrote?

Ask the memory tools you are choosing between, because most of them have no answer.

Run the fourth case forward six months. The agent has been writing down what it learns about your deployment process, your billing migration, the service that has to go first. It is accurate, it is useful, and it is now a real body of team knowledge. Then somebody joins in March. What do they see of everything written before March?

For claude-mem, nothing, because it is on another laptop. For the official memory server, whatever its memory.jsonl contains, in full, to anyone pointed at that process. For the hosted layers, whatever the account the key belongs to can reach. That is the "what the plugin runs, it runs as you" problem, moved one layer out: the server acts with a scope, not with an identity, so the answer is always all of it or none of it.

Baalda answers it differently because a note is a resource in an access tree rather than a row in the agent's store. An MCP token "authenticates an AI client to POST /api/mcp AS one user WITHIN one vault", and the same per-file ACL the people use gates what each call touches, re-resolved every time. So the agent reading the deployment runbook is doing it as you, with your permissions, and a note nobody shared with you is not something it can quietly return.

The March question has its own setting, and it is reachable over MCP so the agent can be asked what the answer currently is:

{
  "name": "set_access_default",
  "arguments": { "mode": "readonly" }
}

Three modes: open (Can edit), readonly (Can view), private (No access). It sets "future members' initial access to content that already exists when they join", it is owner and admin only, and existing members are unchanged. Underneath, joining writes a snapshot row holding that mode, the access revision at the time and the moment it was taken, and the resolver compares each note's creation time against it. A note that already existed when you joined is governed by your snapshot. A note written after you joined is governed by the ordinary grants. Set the default to private and a new hire starts with the folders somebody deliberately opens to them. Set it to readonly and they can read the six months of accumulated runbooks on day one without being able to rewrite them.

That is the question to put to any tool on this list, and it is worth putting to ours too.

Where Basic Memory wins, and where it differs. Basic Memory Teams exists and is the real competitor here: a "Shared organization workspace", "Real-time collaborative editing", "Team projects and restricted projects", "Role-based access control" with Owner, Editor and Viewer, and "MCP access for AI tools", at $15 per seat a month as of 11 October 2026. If a project boundary and three roles describe your team, that is a complete answer and the difference below will not matter to you. The difference is the unit: theirs is a project and a role, ours is a note and a person, with folder grants inheriting down, file shares that can only raise, and per-user denies that nobody including an admin is exempt from. One of those is simpler to reason about. The other is the one you want when the contract with the legal folder in it should not be in the agent's reach for eleven of the thirteen people who can otherwise see everything.

Where does this not help?

Three places, and the first is the big one.

Nothing here watches your session and writes things down for you. A note in a Baalda vault exists because something called create_note, append_note, update_note or edit_note. There is no background extraction, no consolidation pass, nothing deciding a sentence was worth keeping. Auto memory does that, for free, already installed, and it is genuinely good at it. If what you want is the agent quietly noticing you prefer pnpm, auto memory is the right answer and a vault is the wrong one. The two are not alternatives, and the usual arrangement is both: auto memory for the preferences that are yours, a vault for the decisions that are the team's. Either way, somebody has to ask for the important things to be written, which is a cost, and the thing it buys is that nothing lands in the team's notes that nobody requested.

If you are one person, stop. Every tool in this post, ours included, is overhead on top of something that already works. CLAUDE.md plus auto memory plus a skill for the long reference material is a complete solo setup, and the solo Claude Code second brain walks through it without any of this. The multi-user machinery only earns its cost when there are multiple users.

It will not fix retrieval you have not noticed is failing. Memory that is kept but never surfaced at the right moment is a different problem from memory that was never kept, and agent memory fails by throwing things away rather than by searching badly is about that one.

On cost, so the comparison is fair: Baalda is open source under Apache-2.0 and free to self-host, the managed backend is free for 2 people and 1 synced vault, and Team is $10 per seat a month or $110 per seat a year with a minimum of 3 seats, as of 11 October 2026.

The useful version of this search, in the end, is not "which memory tool is best". It is "what forgot, and who else needed to know". Answer that honestly and most of the first page stops being relevant, which is the one thing none of the pages on it can afford to tell you.