Your AI's memory is a folder. And that's the problem.

This started as a complaint, not a theory. Since the Claude 5 series landed, the agents I run every day have been getting more things wrong. Not "I don't know" wrong. Confident wrong. Telling me a file lived somewhere it did not, describing a function that had been renamed two weeks earlier, stating a fact about my own repo with total certainty and being flatly incorrect.

That is the failure mode that actually costs you time. A model that says "I'm not sure" you can work with. A model that is sure and wrong sends you debugging the wrong thing for an hour.

So I went looking. What changed? What are people actually recommending now? And the trail kept ending in the same place: the memory folder.

Because not too long ago Claude shipped this thing called memory. The pitch was good: a place that remembers everything, without you having to build a pile of complicated hacks. An area where your AI puts the things that matter. You can see them. You can update them. That was supposed to be the fix for your agent not remembering where things are.

It isn't. And once you see what it actually is, you can't unsee it.

01 / The thing nobody tells youThere are two different "memories"

This is where most of the confusion lives. When people say "Claude has memory now," they could mean one of two completely different systems. They work differently, they live in different places, and only one of them is a folder you can open.

The one in the app is a hosted store. You get a Topics list in settings where you can view, edit and delete entries, but there is no folder on your machine and no file to open. It's per-project too, so a memory from one project doesn't leak into another. As of August 25, 2026 it also syncs across regular chat and Cowork, which it didn't before.

The ones in Claude Code are files. On your disk. Right now.

02 / What it actually isA folder. Some files. Rows of text.

Here is Claude Code's auto memory, the newer of the two. This is the whole thing:

Claude writes these itself, without being asked, based on your corrections and preferences. Only the first 200 lines or 25KB of MEMORY.md gets loaded at the start of a session, whichever limit hits first. The topic files load only when something actually reaches for them.

It's machine-local. It doesn't sync. And it never expires on its own - those files sit there indefinitely until you go in and change them.

03 / The actual problemYou just created a second source of truth

Here's what bothers me, and it's not that the feature is badly built. It's built fine.

The problem is what it is: you have now created another place where your knowledge base can go stale. Another thing pointing at something. And what happens when the thing it points at changes?

Now you have bad memories. Wrong memories. Memories that represent something from the past, being presented to you as the present.

Your codebase moves. Files get renamed, functions get deleted, the architecture you described six months ago got replaced in a refactor. The code knows all of that, because the code is the change. The memory file doesn't know any of it. It just sits there, confidently, being wrong.

And a confidently wrong memory is worse than no memory at all. No memory means the agent goes and looks. A wrong memory means it doesn't bother.

04 / This isn't just my opinionAnthropic's own docs say it

I want to be careful here, because it's easy to make a hot take sound like a fact. So let's look at what's actually written down.

From Anthropic's own Claude Code documentation, on the subject of keeping these files straight:

If two rules contradict each other, Claude may pick one arbitrarily. Review your CLAUDE.md files... periodically to remove outdated or conflicting instructions. Claude Code memory docs, code.claude.com

And from their guide on working in large codebases, which is even more direct:

Conventions drift, files go stale, and no one owns the root. Claude Code large codebases guide, code.claude.com

They know. This is documented behaviour, not a bug report.

The strongest tell is what they built in response. Claude Code ships a /doctor command, and what it does is propose trims for your CLAUDE.md - specifically cutting the content Claude can derive from the codebase, and keeping only the things it can't: the gotchas, the reasoning, the conventions that differ from the defaults.

Read that again. Their own tooling deletes the memory that duplicates the code. That's the whole argument, shipped as a feature.

05 / The one real fix they shippedA timestamp

There is one recent change that tells you Anthropic sees the same problem. In Claude Code v2.1.214, when Claude writes a memory file, it now stamps a modified: field into the frontmatter with an ISO timestamp.

The stated reason is so that you and Claude both know how current the fact is when you read it back.

Think about what that admits. The fix for a memory system isn't better recall - it's a date sticker, so you know how much to distrust it. That's an expiry label on milk. Useful! But you don't put an expiry label on something you're confident about.

06 / The part I keep thinking aboutRoughly a version a day

Let me be clear about where I'm standing, because this next bit reads as criticism and it isn't meant as a hit.

Anthropic is a great company. Claude Code is the tool I open every single morning. The rate they ship at is genuinely remarkable, and most of the changes make my work better. I'd rather have a team moving this fast than a team polishing a release for six months.

But that rate has a cost, and nobody is going to say it for them. Claude Code ships releases at roughly the pace of one a day. There is no version of reality where anyone can check every one of those changes against every way people actually use the tool. The surface is too big. My workflow is not your workflow, and neither of us is the workflow they tested.

Which means the burden of noticing quietly moves to us. When something starts behaving differently, you are the instrument. If you don't say it out loud, it does not get fixed, because it was never visible.

So this is honest feedback where I think it's due, from someone who uses the thing all day and wants it to be better: the memory feature is the piece I trust least, and the one I've had to work around most. That is worth surfacing, and surfacing it is the point.

07 / What I'd actually doCode is truth

So here's my take, and it's the whole reason I made the video.

Remove your memory for anything code-related. Not the feature. Just the code-shaped contents of it.

Code is truth. You do not want to create a second place that is going to collect dust and demand that you keep it updated forever. That's a maintenance job you invented for yourself, and the payoff is an agent that occasionally tells you confident lies about your own repo.

Instead: use the agents. Ask them to build an architecture where the code is the source of truth and it can be read. As your codebase evolves and changes, there's nothing to update, because the answer was never written down twice.

Memory isn't useless. For facts about you - your role, your preferences, how you like to work, what you've already told it twice - it's genuinely good, and the app version is good at exactly that.

But the moment a memory describes your codebase, you've built a copy of something that changes without telling you. And that copy is going to be wrong eventually. Not maybe. Eventually.

Delete it. Let the code speak for itself.

And when something breaks in a way that feels new, say it publicly. Not to dunk on anyone. These tools improve at the speed we describe what's actually happening to us, and quiet frustration improves nothing.