Somewhere on your machine, if you use an AI coding assistant with any kind of session memory, there’s a file quietly accumulating notes about you. Not the instructions you wrote. Those live in a file you’d recognize if you opened it, the one where you tell the assistant your conventions and preferences. This is different: notes the tool wrote for itself. Corrections you made that it decided not to repeat. Small preferences it picked up along the way. A build command it learned works better than the obvious one. Genuinely useful. Also, almost certainly, not going anywhere you’d want it to go if you ever needed it later.
I don’t say that to be alarmist about a specific product. Claude Code’s version of this is called auto-memory, and it’s a real, well-built, well-documented feature — I’ll use it as the concrete example throughout, because naming a thing precisely beats gesturing at “AI memory features” in the abstract. But the shape generalizes. Several tools now ship something like this: a place the assistant writes its own notes, separate from the instructions you wrote, loaded automatically at the start of every session. The convenience is real. So is the trap, and the trap has nothing to do with whether the feature works well. It works fine. The problem is what it’s for.
Three questions, before you trust it with anything that matters
Ask these about any memory feature your tool gives you for free:
Is it portable across tools? If you ever use a second AI assistant, even occasionally, even just to compare, does the memory travel with you, or does it start over from zero?
Is it synced across machines? If you work from a laptop and a desktop, or hand a project off to a second computer, does the memory follow the work, or does each machine quietly build its own separate, diverging record?
Is it version-controlled? If the tool writes something wrong, or a bad session corrupts a note, can you see the history, diff it, and recover the previous version? Or is the current state simply the current state, with no record of how it got there?
Most tool-native memory features fail at least one of these. Many fail all three. The failure isn’t a bug. It’s the natural consequence of building a feature scoped to “make this one tool feel smarter on this one machine, with zero setup” — a legitimate design goal, and not the same one as “keep a durable record of what’s true about my work.” Convenient and durable are different properties, and a vendor shipping the first one has no particular reason to tell you it isn’t the second.
What the audit found
I’d known this in the abstract for a while: durable project memory is something I’ve written about before, specifically because chat history and tool-specific memory aren’t a substitute for it. What I hadn’t done was run the audit on my own setup. So I did.
The first directory I checked, the memory folder for the project I happened to be working in, had seventeen files. All real, all things I’d genuinely want to keep. What made it interesting wasn’t that directory — it was checking whether that was the only one. It wasn’t. Five more turned up, each tied to a different piece of work I’d touched on that same machine, thirty-five files in total, and every single one of them existed only on that one computer. Nothing about how the feature works would have surfaced the other five on its own. I had to go looking, the same way you’d have to go looking on yours.
The more useful discovery wasn’t the sprawl, though. It was finding that a chunk of those files were no longer real notes at all: they’d been quietly turned into forwarding addresses. A past working session, hitting the same structural problem I was now investigating on purpose, had already started routing new learnings into a proper git-tracked system and left short pointer files behind, redirecting to where the real content now lived. Nobody had told that session to do this. It had run into the portability problem directly, mid-task, and improvised a fix on the spot — informally, inconsistently, without ever naming what it was doing. That’s the tell. When the assistant itself starts working around its own memory feature unprompted, the feature has already been judged and found wanting by the system best positioned to know.
What solves this
The fix isn’t a smarter memory feature. It isn’t keeping notes in the tool at all — it’s a small number of plain files, in a git repository, that any tool capable of reading and writing files can use: a working-state file for what’s true right now, a reference file for facts that don’t change often, a folder of dated session logs, a folder of cross-project lessons. Nothing exotic. The value comes from three unglamorous properties: any AI tool can read and write plain text, git already solves cross-machine sync and version history, and none of it requires the vendor of any particular tool to have thought about your problem in advance.
That’s synthesis project management in one paragraph, the durable-memory piece of the broader synthesis engineering discipline. I won’t re-litigate the full case for it here. The tiered structure that keeps working memory small while still preserving history is its own piece, and the underlying decision framework for when a system like this is worth the setup cost is another. The point that matters for this one: once a durable system like that exists, tool-native memory stops being a convenience and starts being a liability, a second, unsynced, unversioned copy of some of the same information, quietly drifting from the real one every time either gets updated and the other doesn’t.
When this genuinely doesn’t matter
Not every use of a coding assistant needs any of this. A short-lived task on one machine that you’ll never revisit (a quick script, a one-off debugging session, work you’ll finish and forget by design) doesn’t need durable memory any more than a scratch pad needs version control. The three questions above are a filter, not a universal verdict. Apply them to work that’s going to matter next month, next quarter, or to someone other than you. Skip the ceremony for work that genuinely won’t. The failure mode worth watching for is the opposite one: reaching for extra tooling and process on a task simple enough that a single focused session was always going to be enough.
What to do
If your tool’s memory feature can be disabled or redirected (check; more of them support this than you’d expect, usually via a setting most people never open), decide deliberately whether to turn it off rather than defaulting to whatever shipped. If real content is already sitting in one, don’t just delete it. Read through it once, and you’ll likely find the same two categories I found. Some of it duplicates a decision, a lesson, or a fact you already have recorded properly somewhere durable — safe to let go. The rest is real and belongs somewhere with history, sync, and portability, which means moving it there before you turn anything off.
None of this is a criticism of any specific product. A tool that writes its own notes and loads them automatically is a genuinely good feature for what it’s built for: a single session, on a single machine, feeling more competent than it did an hour ago. Just don’t mistake that for a record of what you know.