Claude Code does have memory now. It just never leaves your machine

For most of its life the answer was no, and people wrote their own patches around it. That is now out of date. Claude Code carries two separate memory systems across sessions, both of them plain markdown, both loaded before you type anything. The interesting question is no longer whether it remembers. It is where the remembering is kept, and who else can reach it.

What exactly does Claude Code remember between sessions?

Two things, and they are different in kind. As of 9 October 2026 Anthropic's own memory documentation opens by saying that "Each Claude Code session begins with a fresh context window" and that two mechanisms carry knowledge across that gap.

The first is CLAUDE.md files, which you write. They load at the start of every session, from the filesystem root down to your working directory, concatenated rather than overriding each other.

The second is auto memory, which Claude writes about you, without being asked. The docs describe four kinds of note, recorded as a type field in each file's frontmatter: user (your role and working preferences), feedback (corrections you give it and approaches you confirm), project (ongoing work and decisions it cannot derive from the code), and reference (where to find things outside the project). It deliberately skips anything derivable from the codebase and anything your CLAUDE.md already says.

A third thing gets called memory and is not: the conversation itself. That is session state, and it goes when the session does.

So the honest answer to the query is yes. The limit is not that it forgets.

Where do the memory files actually live?

In a directory per project, at ~/.claude/projects/<project>/memory/. The docs are specific that the <project> path is derived from the git repository, so every worktree and subdirectory of one repo shares a single memory directory, and nothing crosses between repos.

Inside it is a MEMORY.md index plus one topic file per memory. Only the index is loaded at session start, and only partly: the first 200 lines or the first 25KB, whichever comes first. Topic files like user_role.md are read on demand with ordinary file tools when Claude decides it needs them. If the index goes over the limit the write still succeeds, but Claude Code returns an error telling Claude to rewrite it, because everything past the threshold is dropped on the next load.

All of which is unusually good design, and you can open every file in it with a text editor. Which makes the next part of the documentation the one that matters here.

The documentation says it in three sentences: "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 the constraint, stated by the people who built it. The memory is real, it is durable, it is yours to read and edit, and it stops at the edge of the laptop.

What happens to that memory when a second person joins?

Nothing happens to it, which is the problem. Five people working on one repository build five separate memories of that repository, each on a different machine, each correctable by exactly one person. The teammate who spent a session explaining why the billing service retries twice has that fact in ~/.claude/projects/... on their own disk. Yours never learns it. Neither does theirs when they get a new laptop.

CLAUDE.md is the half that does travel, because it is committed to the repository, and that is exactly why it is the wrong place to put everything. Its own documentation asks you to keep it under 200 lines, because the file is loaded into every session for every teammate whether the question needs it or not. What to put in an AGENTS.md file goes through that budget properly. An instruction file is a push channel. The things auto memory collects are mostly pull: useful when a particular question comes up, dead weight the rest of the time.

Baalda is a team second brain built on plain markdown files on your own disk. Several people edit the same note in real time over a CRDT, permissions are set per folder and per note, and it is open source under Apache-2.0 and self-hostable. It exposes the vault over MCP, so an assistant reads and writes the same files a person does and is held to the same permissions. It is free to run locally, with an optional managed Team plan for hosted sync. If the category is new, what a team second brain is covers the idea before the plumbing. The rest of this post is about the two routes from a machine-local memory directory to one a team shares.

Can you point Claude Code's memory at a folder the team shares?

Partly, and it is worth knowing the limits before you try. Claude Code has a documented autoMemoryDirectory setting that moves the memory directory somewhere else:

{
  "autoMemoryDirectory": "~/Baalda/Engineering/agent-memory"
}

The value has to be an absolute path or start with ~/, and it is read from any settings scope. Because a Baalda vault is a real folder of .md files on disk, pointing the setting inside one means the memory files are vault files: they sync to everyone, they open in the app, and a teammate can correct a line Claude got wrong.

Be clear about what this is. It is a documented setting applied to a synced folder, not a team memory feature Anthropic ships. Three things it does not fix:

• Claude Code is still the only writer it knows about. It has no idea the folder is shared.
• Everyone's sessions write into one MEMORY.md, and that index has a 200 line budget that was sized for one person.
• Two people's sessions can write the file at the same moment. Baalda's desktop bridge reconciles an external edit by comparing the file against what it last observed and merging the newer version in rather than overwriting it, so the edit is not lost, but nothing serialises the two writers at the point of writing.

It is a real option for a small team that wants the agent's accumulated notes visible to everyone tomorrow. It is not the structured version.

What does an agent writing its own memory need the server to guarantee?

The structured version is the agent reaching the shared notes as tools rather than as files, over Baalda's MCP endpoint. Each person mints their own token in Vault settings under MCP, and it authenticates as that one user inside that one vault, so what the agent can reach is what that person can reach.

The guarantee that matters for memory specifically is narrower than permissions, and it is the one a filesystem cannot give you. An agent keeping a memory file writes to the same path over and over, across sessions, after crashes, on retries. On a vault several people share, "create the note at Engineering/agent-memory/billing.md" has to be safe to call a hundred times.

In Baalda, create_note takes a vault-relative path ending in .md and, when a live note already sits at that path, adopts it instead of inserting a second row. The reason is written into the code: a vault-relative path addresses one note, nothing in the schema enforces that, and the desktop's path-to-id map just picks one of a duplicate pair, so the loser becomes a row no client can see or delete. The comment finishes the thought plainly: an LLM retrying a tool call must not be able to create that.

Adoption alone would be a different hazard, so there is a second rule on top of it. Seed content goes only into an empty note. The code says why in one line: "Create" must never become a way to overwrite a note that already says something. That is update_note, which the caller can reach for once the response has told it what happened, because the result carries adopted and seeded as separate booleans. A retry that adopts a note somebody has since written into gets adopted: true, seeded: false and has to decide, rather than quietly flattening the paragraph a human added this morning.

The same response hands back the row's own spelling of the path, so an agent that asked for a case variant of a path that already exists learns which one this vault actually uses.

None of that is exotic. It is the difference between a memory an agent can maintain unattended on shared storage and one that needs somebody watching it.

When is the local memory directory the right answer?

Often. Auto memory is on by default in local sessions, costs nothing, needs no server, and for one person on one machine it is simply correct. If your knowledge lives in one repository and your team is you, ~/.claude/projects/<project>/memory/ is the answer and a vault adds a moving part for no gain.

Three more places this does not help:

• Baalda does not replace auto memory. There is no setting that redirects it to an MCP server. Claude Code keeps its own directory; the vault is where the part other people need to read and correct goes.
• If the context belongs to the codebase, it belongs in the codebase. A convention that only makes sense for one repo is better as a CLAUDE.md in source control than as a note in a vault, as the team Claude Code setup argues at more length.
• Obsidian is a better single-player editor, and it is free. If nobody else needs to read the agent's notes, a vault with no server in it is less to run. Obsidian's own help pages are also honest that Sync shares a vault whole and gives every collaborator the owner's permissions, which is the point at which the comparison stops being close.

The thing to take from the documentation is not that Claude Code forgets. It is that it remembers in a place with exactly one reader, and that a team's memory of its own work should not be a set of parallel private files that disagree.