Main idea

Claude Code already keeps a memory of what it has been told, but it files it under ~/.claude/projects/: it belongs to the installation, not to the project. Switching computers, rereading it, knowing when a given decision entered it, sharing it with a colleague — none of that is provided for, because the storage location was never thought of as an object of work.

Writing the same memory into Markdown files dropped inside the project's git repository changes four things at once, and all of them come from the same gesture. It travels with the repository, so a clone on another machine finds it again. It is versioned, so git log memory_sessions/ tells the story of how technical decisions evolved. It opens in the editor, so you can correct it by hand when the agent misunderstood. And it splits the way the repository splits.

The flat format is not a technical concession pending something better: it is what makes the memory inspectable by a human, and a memory no human ever rereads never gets corrected.

Layer added by "Information systems aren't going away. Their shape is changing." (2026-07-08). The same split holds at company scale, and the format matters even less there than you would think: Markdown, JSON, a document store, a graph or a vector database all do the job; the line runs between what is movable and what isn't. Working intelligence left inside chat histories is useful only as long as the interface exists, the subscription is active and you can find the right conversation: it is a usage trace, not a company memory. The criterion that decides is a list of operations, not an aesthetic preference — being readable by a human, picked back up by another AI, moved, backed up, enriched, audited.

Why it matters

This shifts the question you ask in front of a memory tool. You usually ask what it retains; the question that counts first is where it writes it, because that choice decides everything else — portability, history, rereading, sharing.

It also explains why a native memory, even a good one, leaves something missing: what lives inside the tool is out of reach of the tools you actually work with.

Nuances and limits

Putting the memory in the repository makes it visible to everyone who has access to the repository. What gets written there automatically — a customer's name, a mistake made, a hesitation — becomes content published at team scale, without anyone having reread it.

And a versioned file rereads badly as it grows: inspectability depends on size as much as on format.

Open questions

• What do you do with the memory of an abandoned branch, which was written but whose work was never merged?