Turning off Claude Code's auto memory is reasonable. Keep the decisions.
Friday afternoon, you open /memory out of curiosity and read what your agent has been writing about you for three weeks. "Prefers pnpm." "Wants tests before the commit, not after." A note about a deadline that passed. All accurate, none of it what you would have written down. Somewhere in there, between the preferences, is a line about the queue you moved off of, missing the part that mattered: what broke when you tried it the first way.
So you turn it off. autoMemoryEnabled: false in the project settings, or CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, and the folder stops growing. That is a defensible call, and worth being precise about why. Auto memory does more than people assume. It keeps a MEMORY.md index plus a topic file per memory, stamps writes with a modified timestamp so you can see how current a note is, and when the index approaches its load limit of 200 lines or 25KB, Claude Code tells the agent to shorten it, merge entries, drop stale ones. It is a careful design. The objection is not that it forgets the date or the reason.
The objection is whose notes those are. Auto memory holds what the agent observed about working with you. That is a genuinely useful thing and a personal one. It is machine-local by design, it never crosses to a teammate, and its index is a fixed budget that something must leave when it fills. None of that is wrong for observations. It is wrong for the ruling your team spent an afternoon reaching, because a ruling is not a note the agent took. It is a commitment, and commitments do not expire because an index got long.
That distinction is why we build kgai, a decision memory for AI dev teams. A decision lands in an append-only, immutable log, and the graph the agent reads is a deterministic projection of it. Change your mind and the next decision supersedes that one through an explicit link that carries the reason, so nothing gets dropped to make room. Recall returns only what is in force, while the dead ends stay queryable, which is the point of keeping them at all. The read path is lexical matching plus graph traversal, no embeddings in it.
Capture sits at the write boundary, driven by a skill and hooks, in the session where the change is made. Sharing across the team is opt-in through an S3 bucket you own, and because each writer appends to a shard of their own, two people recording at once never produce a textual conflict. No daemon, no server. At 1,000,000 decisions across 30 writers' shards a decision lookup answers in about 100 ms, though recall and free-text search are slower. MIT, a Claude Code plugin with a standalone kg CLI. If the model is new to you, what decision memory is walks through it.
Leave auto memory off if it is not for you. Just do not let the team's decisions go off with it.
Try it on your repo. Two commands, MIT, nothing leaves your machine until you configure a bucket.
See how kgai compares to other tools on the comparison page, or browse the other notes.