Claude Code's Memory Feature Does More Harm Than

Imagine hiring an office assistant who, after every task, scribbles notes about what just happened and files them somewhere in the building. They never tell you they're doing this. The notes pile up. Some are useful for a day or two, then go stale. Some were wrong from the start. The assistant keeps consulting them anyway — or more often, just keeps adding new ones without reading the old ones. You only discover any of this when you go looking.

That is Claude Code's memory feature, according to developer Theo — known online as t3.gg — who published a detailed audit of what the tool had quietly saved across his machines. The numbers are hard to argue with: 45 stored memories on his main development box alone, and 26 of them had never been read once.

What stale notes actually cost

The content of those memories is where it gets genuinely troubling. There were notes about a GitHub CLI version that was out of date — and had since been updated. Notes about a feature comparison from three months prior, for a feature that either shipped or didn't. Notes about a build conflict on a phone that caused a rage-quit moment and led Theo to switch tools entirely for iOS work. The conflict was resolved. The note remained, dutifully preserved, potentially steering future sessions toward a problem that no longer existed.

Think of a personnel file that still lists an address someone moved away from four years ago. The file doesn't know the address is wrong. It doesn't flag itself as suspect. It just sits there, confident, available, waiting to be cited. That's what a stale memory file does to an AI agent starting a fresh session — it hands the model a map of a city that's been half-demolished and rebuilt since the map was printed.

This is not a subtle failure mode. Theo found memories describing "point in time states" — moments when a drift was being migrated, a PR was open, a process was leaking — without any indication of whether those states had since resolved. "These describe a moment," he said. "The PR's merged or didn't. The leak got fixed or didn't." The memory system preserved the snapshot but discarded the resolution.

The ratio tells its own story: of all the sessions Theo ran against his main T3 Code clone, the memories were being written to far more often than they were being read. Of the 45 stored, 26 had never been consulted at all. The system was optimizing for capture, not for use.

"Code is truth"

A clip Theo shared in the video makes the underlying argument cleanly. Mario Livadariu, the creator of the Pi framework, said it plainly in a conversation that sparked the video: "For coding, I don't want a memory system. Code is truth. Code is the ground truth. It's also evolving and I don't need another place that I need to maintain. I already have a codebase to maintain."

That's the crux of it. A codebase is already a record of decisions — what was tried, what was kept, what was structured which way and why. When you add a memory layer on top of it, you're not supplementing the record. You're creating a second, competing record that has no mechanism for staying in sync with the first. Every comment that outlives the code it describes is a small version of this problem. Memory files are that problem, systematized and automated.

Cursor's trajectory is worth noting here. The company built significant early infrastructure around dynamically feeding AI agents the right code context — sophisticated graph-based traversal systems that could map a codebase and serve up relevant pieces. Theo notes in the video that even Cursor has since moved away from that approach entirely. The lesson the industry drew, however belatedly, is that models trained to use bash tools can find what they need on their own. The elaborate scaffolding was solving a problem that better-trained models stopped having.

The open-source ecosystem has been busy building persistence layers for Claude Code — tools that claim to fix the statelessness problem with smarter storage and retrieval. What Theo's audit surfaces is a harder question: even if the storage is smarter, is statelessness actually the problem you need to solve?

The notes you write yourself are different

Theo's answer to memory isn't amnesia — it's intentional, human-authored context. He maintains a claude.md configuration file for each project that reads less like technical documentation and more like onboarding a new colleague who needs to understand not just the codebase but the product, the values, and the decisions already made.

His file for T3 Code explains what the project is, why it's open-source and must stay that way, why remote performance matters, what breaks when you change the data layer without thinking about all three platforms simultaneously. There's a glossary so the agent and the humans working alongside it share a common vocabulary. There's a "taste" section — contributed largely when collaborators complained about specific code patterns — that describes the aesthetic sensibility the project is trying to maintain.

None of this goes stale the way memory files do, because it's maintained deliberately. When the project changes direction, a human updates the file. The difference between that and an auto-generated memory is the difference between a decision and a side effect.

Developer Lauren Tan, who ships code at Cursor and has written publicly about agent workflow, frames the hierarchy well: the first move when an agent makes a mistake should always be to ask whether the codebase architecture can be changed so the mistake becomes impossible. If not, make it a lint rule or a CI check so the agent catches the problem before surfacing it to you. Theo built exactly this for T3 Code's data layer — a CI check that measures how much data traverses the websocket per session, with a ceiling that fails the PR if bandwidth spikes past acceptable levels. The agents now fix regressions before declaring themselves done.

That's the ladder: architecture first, automated enforcement second, explicit instruction third. Auto-generated memory doesn't appear on the ladder, because it doesn't prevent mistakes — it just narrates them after the fact and hopes the narration proves useful next time.

The question the memory advocates haven't answered

There's a version of the Claude Code memory argument that sounds reasonable: the model forgets everything between sessions, so why not help it remember? Theo's audit is a useful stress test for that intuition, because it shows what "helping it remember" looks like in practice when left to run autonomously. It remembers the GitHub CLI version you updated three months ago. It remembers a sidebar variant you considered and discarded. It remembers the topology of a Railway deployment from a project that's since been restructured.

Theo offers one important concession: memory in conversational contexts is different. When a user asks about shoulder pain and the relevant context is a keyboard they mentioned six weeks ago, there's no programmatic path connecting those two things — the connection is genuinely non-obvious and a memory system might surface it usefully. Code doesn't work that way. If a button isn't doing what it should, you can trace from that button through every function it touches. The structure is explicit. The agent doesn't need to remember; it needs to look.

The harder challenge for memory advocates is evaluation. As Mario noted in the clip Theo shared, "I'm pretty sure you've never done an evaluation if that actually produces better outputs and I guarantee you it does not." That's a strong claim, but it's the right question to be asking. The enthusiasm for memory systems has largely outrun the evidence that they help.

Every session, the model wakes up with no recollection of what came before. The right response to that isn't to flood it with automated notes that may or may not reflect current reality. It's to make sure that when it opens its eyes, the codebase itself — clean, well-structured, honestly documented — tells it what it needs to know.

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG