Disabling Claude Code's memories is the best upgrade I ever made to my AI coding setup

Published Sep 21, 2026, 5:30 PM EDT Anurag is an experienced journalist and author who’s been covering tech for the past 5 years, with a focus on Windows, Android, and Apple. He’s written for sites like Android Police, Neowin, Dexerto, and MakeTechEasier. Anurag’s always pumped about tech and loves getting his hands on the latest gadgets. When he's not procrastinating, you’ll probably find him catching the newest movies in theaters or scrolling through Twitter from his bed. Claude Code can inspect a codebase, make changes across several files, and test its own work without needing every step spelled out. That level of autonomy is what makes it such a useful coding tool. Auto memory sounds like a natural addition to all of this. Claude could save useful details from one session and carry them into the next, which means I wouldn’t have to repeat the same preferences, corrections, and project context every time. However, auto memory hasn't really been very convenient for me. In fact, I've been watching it derail my projects in real time. It gives Claude another collection of assumptions to consult, including ones that were outdated, overly specific, or no longer relevant to the work in front of it. I eventually disabled the feature, and that ended up being the best upgrade I’ve made to my AI coding setup. Claude Code was remembering the wrong things And that made things worse Claude Code’s Auto Memory is separate from the instructions stored in CLAUDE.md. The feature watches for details it considers useful, such as corrections, working preferences, project decisions, and references that might matter later. It then writes those details to a memory directory associated with the repository. Claude loads the first part of its MEMORY.md index at the start of every conversation, and it can retrieve more detailed notes as it works. The problem is that Claude decides what qualifies as a useful memory, which means even a temporary instruction can easily become a lasting preference. I could tell Claude to avoid a particular approach while debugging one issue, then start another session and find it still working around a restriction that no longer applied. Claude would sometimes remember a discussion as a decision. I often use it to explore several ways of implementing something before choosing one, and those conversations include plenty of ideas that never make it into the project. Auto memory then preserves one of those ideas without the surrounding uncertainty. Several sessions later, Claude would treat it as part of the project’s architecture even though I had never approved or implemented it. I wouldn’t say Auto memory caused an obvious failure on its own. However, it sent me into a loop where I had to redo a task and re-prompt Claude Code to do something the way I wanted because it had decided to follow what it had logged in memory. That, in turn, increased my usage, so over a longer playoff event, this becomes a problem. CLAUDE.md is all the memory I need You can add all the relevant context to this file I still want Claude Code to understand how a project works when I start a new session. I keep the important context in CLAUDE.md so I can see exactly what Claude is told before it touches the code. Claude Code now also supports AGENTS.md, which makes it easier to carry the same project instructions across different coding agents. My CLAUDE.md contains information that should remain true across the project, such as the package manager I use, the commands required to test changes, and any architectural rules that aren’t immediately clear from the repository. If something changes, I update the file instead of waiting for Claude to notice that one of its memories is outdated. Writing these instructions myself also forces me to decide whether a correction deserves to become a permanent rule. If Claude repeats the same mistake, I can add a short and specific instruction to prevent it. It's also important not to clutter CLAUDE.md, because too much information can become a problem of its own. A lot of people keep adding unnecessary details when the file is really meant for key instructions Claude needs to follow consistently. It's generally recommended to keep each file under 200 lines, since shorter instructions generally lead to better adherence. I want every session to start clean That somehow makes Claude Code work better Auto memory assumes that the next Claude Code session is a continuation of the previous one. That isn’t how I always use it. Carrying the reasoning and restrictions from older tasks doesn’t always give Claude a useful head start. It gives the new task baggage. A clean session is also easier to debug. If Claude makes a strange decision, I can check my prompt, inspect the repository, and review the project instructions. Those are visible sources of context that I can correct. Auto memory adds another influence created across earlier conversations, so figuring out why Claude chose a particular approach becomes another task on my list. This becomes a bigger problem when you use multiple worktrees or move between coding agents. Claude Code stores auto memory locally and shares it across worktrees belonging to the same repository. The resulting behavior depends partly on info that isn’t present in the repository and won’t follow the project to another machine or tool. What this means is two sessions working from the same code can start with different assumptions simply because one of them has access to that history. Get the most out of Claude Code While disabling auto memory helps, getting the most out of Claude Code also means enabling the right features. Hooks, for example, can help ensure Claude stays aligned with the goal you give it and follows specific rules throughout a task. There are also several less obvious settings you can change to give Claude more control and make it more capable within a project.