As terrible as I find memory in AI tools, I have to admit it makes for a much better experience. After all, that’s why all the major AI labs are focusing their efforts so aggressively on personalization and continuous context development.
No one wants to re-explain their entire project every time they open a new conversation. While I’m not a fan of them, especially in chatbots that you use for day-to-day tasks, I’ve come to think of it in the context of coding. So when I actually found a way to give the ongoing Claude Code memory and studies between sessions, I had to try it.
Claude Code has two types of memory
One is written by you, the other is written by himself
Currently, the tool has two storage systems that are loaded at the beginning of each Claude Code session: CLAUDE.md files and AutoSave. Both of these systems are complementary, that is, they are designed to work alongside each other rather than as substitutes.
The CLAUDE.md is a file stored in the root of your projectand it holds the instructions you write for Claude Code: the conventions, commands, and hard rules you want each session to follow for the project you’re working on. This file is read in full by Claude Code at the beginning of each session, which is the perfect way to get him everything about the project – essentially everything you’ll be re-explaining every time. If you’re writing the same fix you wrote yesterday, or if the code review keeps pointing out something that Claude Code should already know, that’s what the file belongs to.
Although CLAUDE.md files can be automatically generated using the /init command, and you could technically ask Claude Code itself to write something for you, this file must first be written and maintained by you. That’s really the whole point. This is a part of Claude Code’s memory that is completely in your hands. Nothing gets in there unless you intentionally put it there, which is why it never sets off the same alarm bells that a regular chatbot would in memory. Instead of automatically fetching information in the background, the file is designed to host a set of instructions that you hand over on purpose.
This ties in well with the other half of the Claude Code memory I mentioned above: Automatic Memory. It does exactly what its name implies—instead of waiting for you to type everything, Claude Code takes notes as you work, noting your edits and choices so you don’t make the same mistake twice. However, it doesn’t save something every session. He makes judgments about whether a given fix or preference is worth keeping for next time, and writes it down only if he thinks it will be useful later.
Automatic Memory is designed to be completely hands-off. You don’t control it, you don’t instruct it, and it’s on by default (as long as you’re on Claude Code v2.1.59 or newer). Like your project’s CLAUDE.md file, it’s encapsulated for everything you work on, meaning each project gets its own storage folder, and what you learn in one Claude Code doesn’t carry over to another.
The difference is who does the writing and what ends up on the page. With CLAUDE.md, you write and all the thought-provoking stuff goes there: your coding standards, your workflows, and the way you architect your project. AutoMemory is for things that Claude Code has identified along the way: a build command that actually works, the concept of debugging a bug you’ve just followed, or the benefit of watching how you work.
claude-mem Claude gives Code a memory that will never be forgotten
He writes everything so that there is no need
The reason I went down the whole rabbit hole above is to clarify the shortcomings of Claude Code’s native memory system. AutoSave is selective by design, and there’s no way to go back and search for what it skipped. claude-mem he takes the opposite position: he tries to remember all this. Its tagline is “a persistent memory compression system built for Claude Code”, and the way it achieves this is by automatically capturing tool usage observations, generating semantic summaries and presenting them to future sessions. That way, even after you close your terminal and come back, Claude still knows what you’re doing.
The mechanism is a chain of lifecycle hooks (which are essentially Claude Code scripts that run at certain moments in the session, so the plugin can connect to what you’re doing without doing anything). claude-mem makes the threads a handful. It includes SessionStart which includes the context of your last sessions, UserPromptSubmit stores your prompts, PostToolUse observes each time the tool runs, and Stop and SessionEnd hooks generate a summary when you’re done. The background worker service takes those initial observations and, as the docs say, extracts the learnings via the Claude Agent SDK, then files everything into a SQLite database with an additional Chroma vector index for FTS5 full-text search and semantic search. In other words, where my native AutoMemory folder has two log files, claude-mem is a whole little pipeline running behind Claude Code.
As soon as you install it, the worker starts a local HTTP service and starts listening to those hooks to send something to it. It also serves up a web viewer with a live feed of whatever the tool decides to save, updating in real-time as you work. For example, I held a session directly within the project and asked Claude Code to suggest features to add to it. The stream was full of cards documenting what he did, including a session summary broken down into what he explored, learned, and completed, and separate discovery notes like “Existing Billing model found in codebase” and “Service and controller architecture defined.” Each of the cards is stamped with the project name, timestamp, and type (eg discovery, feature, session summary) because claude-mem actually goes ahead and categorizes what it catches.
The real test here was how Claude performed when starting another session within the same project. Once I did this, claude-mem listed what she remembered from the last session before I wrote anything down. This way I could quickly pick her up where we left off without having to explain anything again, or rather, I didn’t have to at all because she had already caught herself.
When I gave it a task to do (build the timeline), this summary picked up where the last one left off and built the feature into the existing style of the codebase. For example, since this is a project for a course I’m taking this semester, I preferred to use open iteration like simple for-loops rather than something too clever because it’s so easy to understand. The Claude-mem plugin had this advantage in previous sessions and it passed it through.
Memory is sought after and that’s the part that sold me
Ask what you decided five sessions ago
The automatic recall is the first half you see, but the half that really sells me is the search. Everything Claude-mem captures goes into a searchable database. This means you can go to a project weeks later and just ask about it instead of re-reading old sessions or scrolling through the viewer looking for cards. You can ask a simple question and get an answer. Under the hood, it’s a SQLite full-text search combined with an optional vector index, so it matches not just exact keywords, but semantics, and it’s equipped so that Claude pulls out a compact hit index first and only gets the full detail for the ones that actually matter. But you don’t need to know any of this to use it! There is a memory retrieval skill that allows you to ask in plain language, which I did.
In my hospital project, I wrote a simple question about whether or not I was involved in billing after a few sessions. The plugin clearly explained that the texture was offered as a feature twice and I chose another job instead. What’s interesting here is that it wasn’t just a single card in the mentioned stream. Instead, it combined the response across multiple sessions. It knew that billing came up twice, it knew what features I had selected on it each time, it knew from previous exploration that the billing module already existed in the codebase, and it even brought up a rule I just mentioned in passing: only the patient can pay their own bill, admin or doctor.
Searchable persistent memory is something you just can’t do with Claude Code’s native memory. None of the built-in options are built for this. The CLAUDE.md file is simply the instructions you manually typed and saved, so it only knows what you put into it. There is nothing to look for because it is not a record of anything and is just a set of rules.
AutoMemory, on the other hand, keeps a record of how I type and loads it when relevant, but there’s no index behind it and nothing to actually query. After five sessions I can’t open a project and ask what I decided on billing because no system is set up to answer that! The Claude-mem plugin bridges the gap between the two and keeps a complete record of everything you do in a session, allowing you to search for it when you need it, and also makes each subsequent session aware of its predecessors, so the context accumulates over time instead of being reset every time you close the terminal.
Encoding memory is memory I can live with
Instead of learning who I am as an individual, the tool is learning how I approach my work. This memory consists of my coding conventions, the commands I actually run, the tweaks I need to redo, and the parts of the codebase he needs to tie his hands to. Some are project specific and some follow me everywhere. But none of it feels as personal as a chatbot navigating my travel plans.
With Claude-mem, I get exactly the version I’m comfortable with: write it where I can see it, keep it on my machine, and look it up when I need it. If there’s something I don’t want it to record, I can put it in a private label and it stays out. I don’t mind handing this kind of storage over because I can see what it holds and discard anything I don’t want!
