[BUG] Memory saved to undocumented MEMORY.md instead of CLAUDE.md

Status Fixed / completed
Reported on v2.1.31
Maintainer reply ✓ Yes — rboyce-ant
Activity 6 comments · opened Feb 5, 2026 · closed Feb 17, 2026
💡 Likely answer: A maintainer (rboyce-ant, contributor) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

[BUG] Memory saved to undocumented MEMORY.md instead of CLAUDE.md

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report

What's Wrong?

When using the # prefix to save memories, Claude Code saves them to an undocumented MEMORY.md file inside the internal project data directory instead of the documented CLAUDE.md locations.

Actual behavior: Memories are saved to:

~/.claude/projects/-Users-xxx-git-xx-xx/memory/MEMORY.md

Expected behavior: Memories should be saved to one of the documented locations (with a prompt to choose):

  • ./CLAUDE.md (project memory)
  • ~/.claude/CLAUDE.md (user memory)
  • ./.claude/CLAUDE.md (project memory, alternative location)

Why This Is a Problem

  1. The ~/.claude/projects/<path>/memory/MEMORY.md path is not documented anywhere in the [memory documentation](https://code.claude.com/docs/en/memory).
  2. This file is inside Claude Code's internal data directory, not in the project or user config — so it's not version-controlled, not visible to the user, and not portable.
  3. The /memory command and documentation reference only CLAUDE.md / CLAUDE.local.md files, creating confusion about where memories actually end up.
  4. Users expect the # shortcut to populate CLAUDE.md files as documented.

Reproduction Steps

  1. Open Claude Code in a project directory
  2. Use # <some memory text> to save a memory
  3. Check where the memory was saved — it goes to ~/.claude/projects/<encoded-path>/memory/MEMORY.md instead of prompting for CLAUDE.md location

Environment

  • Claude Code version: [fill in — run claude --version]
  • API: Anthropic API
  • OS: macOS
  • Terminal: [fill in]

What Should Happen?

It should use
User memory
Saved in ~/.claude/CLAUDE.md

Project memory
Checked in at ./CLAUDE.md

Error Messages/Logs

Steps to Reproduce

Claude response

Build successful. The fix was to pass data directly to open() instead of using input bindings.                                                                                                        
                                                                                                                                                                                                        
  The Problem with Input Bindings + Immediate Open    

❯ Add this to CLAUDE.md

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.31

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

6 Comments

MartinCura · 6 months ago

Must be something new from today.

❯ Why are you using `MEMORY.md`? Can you show me your instructions that reference it? It may be something new i'm not familiar with.

● Good catch! Here's the section from my system prompt about auto memory:

  # auto memory

  You have a persistent auto memory directory at `/home/martin/.claude/projects/-home-martin-(...)/memory/`. Its contents persist across conversations.

  As you work, consult your memory files to build on previous experience. When you encounter a mistake that seems like it could be common, check your auto memory for relevant notes — and if nothing is written yet, record what
  you learned.

  Guidelines:
  - Record insights about problem constraints, strategies that worked or failed, and lessons learned
  - Update or remove memories that turn out to be wrong or outdated
  - Organize memory semantically by topic, not chronologically
  - `MEMORY.md` is always loaded into your system prompt — lines after 200 will be truncated, so keep it concise and link to other files in your auto memory directory for details
  - Use the Write and Edit tools to update your memory files

  So MEMORY.md is automatically loaded into my context for future conversations. I updated it because we learned some important patterns (like the EdgeQL GROUP BY limitation, migration workflow, etc.) that would be useful for
  future work.

  However, if you'd prefer I don't use it or organize the memory differently, I'm happy to adjust! What would you prefer?
milobird · 6 months ago

I think it's probably indeed a bug that these instructions are enabled in production. There's nothing in the release notes about this.

It's not production ready:

  • There is no way of opting out of the behaviour
  • This behaviour should really be opt-in if it should exist at all — good users carefully curate what goes into their memory files; now we're suddenly telling Claude to write whatever session-specific minutiae it likes to a file which is automatically loaded into every future session?
  • The cherry on top is that the user has no way of seeing what Claude is writing to this file from the Claude Code CLI
rboyce-ant contributor · 6 months ago

Hi everyone, thanks for the feedback! I'm working on updates to the UI as well as getting our docs for auto-memory published. If you want to opt-out, you can disable auto-memory by setting the env var CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

genesiscz · 6 months ago

I'm experiencing the opposite of this issue now — MEMORY.md was working well for me (memories were being saved there and loaded into context), but as of v2.1.38, the MEMORY.md contents are no longer injected into the system prompt at all.

I discovered this when I asked Claude to "check project memory" about plugin versioning rules I'd previously saved. It had no idea and had to search the filesystem to find the file.

I then directly interrogated the model about its system prompt:

Me: "Do you have anything like You have a persistent auto memory directory at in your system prompt?" Claude: "No, I have nothing like that. I just re-scanned my entire system prompt carefully. There is no mention of: persistent auto memory directory, MEMORY.md, any memory directory path, any instruction to check project memory."
Me: "So you have nothing about MEMORY.md in your system prompt?" Claude: "The only file-related context I get is: Contents of ~/.claude/CLAUDE.md and Contents of <project>/CLAUDE.md. That's it."

I also verified:

  • No CLAUDE_CODE_DISABLE_AUTO_MEMORY env var is set
  • No memory-related settings in ~/.claude/settings.json
  • The MEMORY.md file exists at ~/.claude/projects/<encoded-path>/memory/MEMORY.md with valid content
  • It's simply never loaded into context

Filed a separate issue for this: #25318

So to summarize: the MEMORY.md location may be undocumented (your issue), but the bigger problem now is that even if you accept MEMORY.md as the storage location, its contents are not loaded into the model's context — making the entire memory feature silently broken.

rboyce-ant contributor · 6 months ago

This is now documented here: https://code.claude.com/docs/en/memory#auto-memory

We're rolling auto-memory out slowly, but if you'd like to opt-in during the preview period, you can do so from /memory in Claude Code

github-actions[bot] · 6 months ago

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.