Need ability to disable auto-memory (MEMORY.md)
Status Fixed / completed
Maintainer reply ✓ Yes — rboyce-ant
Workaround ✓ Mentioned in description ↑
Activity 14 comments · opened Feb 6, 2026 · closed Feb 17, 2026
💡 Likely answer: A maintainer (rboyce-ant, contributor)
responded on this thread — see the highlighted reply below.
Problem
Claude Code's auto-memory system (~/.claude/projects/*/memory/MEMORY.md) cannot be disabled. There is no setting, flag, or configuration option to turn it off.
Why this is a problem
For users who manage their own context systems, auto-memory is actively harmful:
- Shadow state - It creates a parallel memory system outside the user's control. The user can't easily view, audit, or understand what's been stored.
- Not git-tracked - MEMORY.md lives in
~/.claude/projects/which is outside the repo. It can't be committed, reviewed in PRs, or versioned alongside the codebase. This is a significant regression from keeping context in repo-local files likeCLAUDE.md.
- Not portable across CLIs - Users who work with multiple AI CLIs (Claude, Gemini, Codex) and maintain shared instruction files (e.g.
AGENTS.mdsymlinked toCLAUDE.md/GEMINI.md) have no way to share auto-memory. It's a Claude-only silo.
- Context bloat - Auto-memory consumes context window tokens on every conversation. For users who already have well-structured
CLAUDE.mdand skill files, this is redundant context that displaces useful working memory.
- No opt-out - The system prompt includes "You have a persistent auto memory directory at..." with instructions to use it. There is no setting to suppress this. Even deleting the files doesn't prevent Claude from recreating them.
Requested solution
A setting to disable auto-memory entirely, e.g.:
// ~/.claude/settings.json
{
"autoMemory": false
}Or at project level:
// .claude/settings.json
{
"autoMemory": false
}When disabled:
- The auto-memory system prompt injection should be suppressed
- Claude should not read from or write to the memory directory
- No memory files should be created
Workaround attempts
- Deleting
~/.claude/projects/*/memory/- files get recreated - Adding "do not use auto-memory" to CLAUDE.md - unreliable, competes with system prompt
- There is no
settings.jsonkey that controls this
Environment
- Claude Code CLI (latest)
- macOS
14 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
The other issue is not nearly as clearly defined so I upvote this one for review.
Given how detailed people's workflows are, I am surprised that this feature came into being with no setting to disable.
Given just how serious folks are about managing context using skills, agents and docs this feature is at best an anti-pattern and worst infantilization.
I get wanting to take the wizardry out of the tool, but maybe turn it on for new users or have CC detect that the user has very low use of skills / agents.md etc and offer to turn it on for them?
There is apparently an undocumented environment variable which turns this off:
CLAUDE_CODE_DISABLE_AUTO_MEMORY.See https://github.com/anthropics/claude-code/issues/23341#issuecomment-3857098145
I like to iterate on instructions in my skills, commands and claude.md by discussing what might have caused it to not follow my instructions.
IE
"Why did you stage the files when the workflow specifies that you should not do that since we do manual testing first"
And now every time I initiate a discussion like that it just unprompted writes it to memory. "Remember to not do x" which most of the times do not solve the problem and repeats instructions that already exists in the Claude.md or my command and skill documents.
As it is right now with my workflow this feature seems completely useless.
This feature makes sense for a user of claude.ai but for anyone using the command line this just seems unwanted and inappropiate. Let me keep the data where it is relevant (in my claude.md, my dedicated skill and command docs and my manually created planning documents)
Other use cases where I explicitly do not want it to remember: "review the tests without looking at code, for an unbiased opinion". "Do a fresh review of changes in this branch" [after issues from previous review were addressed].
Just had Claude come up with a plan, where the verification step said “Pre-existing failures listed in MEMORY.md are unrelated and may still fail”, which was both outdated and a misunderstanding to begin with, and could have caused unfortunate issues if I did not catch it… Last thing we need is to give Claude more excuses to ignore test failures!
The way to disable this is from the environment variables
It’s documented here: https://code.claude.com/docs/en/memory#auto-memory
I don't mind the auto-memory so much as it being outside my direct control. The idea of indexing notes in a memory.md isn't exactly novel, but I appreciate that it's simple to reason about.
Just like with plans, we should be able to configure the directory where memory is stored. Give us a
projectMemoryDirectoryfield in the project settings.I don't like the idea of adding env vars to .zshrc to configure claude code. It would be better to keep it in the settings file where every other aspects can be configured (and can be changed through /config in the app)
@tamasarpad You can set env vars in any Claude settings.json.
This is what I do:
You can manage this directly from
/memoryas well without touching the config file!I've had CLAUDE_CODE_DISABLE_AUTO_MEMORY set to 1 for a while now. While Claude Code is no longer automatically writing the memory. It still proposes writing to it when I am debugging agent issues. This flag is just disabling a specific aspect of MEMORY.md and not the whole feature. Is this expected behavior? I am surprised to see us closing this issue.
Did some testing now. I used to have an MEMORY.md it prompted me to write to. But it no longer seems aware of it. When I prompt it to write to memory it updates my claude.md. So I take back what I wrote. The behavior of this flag seems to have changed to what I wanted. Thank you very much :)
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.