Bug: Claude Code Adds Memory To Wrong Section

Nov 3, 2025 by SLV Team 46 views

Hey guys, have you noticed Claude Code acting a little wonky when it comes to storing project memories? It seems like there's a bug where the #memory entries are being added to the wrong sections in the CLAUDE.md file. Let's dive into what's happening, why it's a problem, and how we can hopefully get it fixed.

Preflight Checklist

[x] I've made sure to search through the existing issues, and it looks like this hasn't been reported yet. Gotta keep things organized, right?
[x] This is just a single bug report – no mixing and matching different issues here!
[x] I'm rocking the latest version of Claude Code, so we're working with the most up-to-date stuff.

What's Wrong?

Description

The main issue we're seeing is that when you use #memory to store important project-specific details, Claude Code isn't placing these entries where they should go. Instead of putting them in a logical section or even a dedicated "Project Memories" area, it's just tacking them onto the last section of the CLAUDE.md file. This is super problematic because it messes with the context and makes things confusing for everyone involved.

When dealing with project-specific information, clarity is key. The #memory function in Claude Code is designed to help us store and recall important details, ensuring that our projects stay on track. But when these memory entries are placed in the wrong sections of the CLAUDE.md file, it creates a cascade of issues. Misleading context can lead to misunderstandings among team members, and crucial information might be overlooked if it's buried in an irrelevant section. The goal is to make sure that these memories are easily accessible and logically organized, so everyone can quickly grasp the essential details without having to sift through unrelated content. A dedicated "Project Memories" or "Project Context" section would be ideal, providing a clear and consistent location for all project-specific information. This not only improves readability but also enhances the overall efficiency of project management.

Impact

Misleading Context: Imagine someone new joining the project and trying to understand the CLAUDE.md file. If memories are scattered in random sections, it's going to create a lot of confusion.
Semantic Association Issues: Memories are showing up as if they're related to completely unrelated sections. This can lead to misunderstandings and misinterpretations of the project's context.
Claude Confusion: If the memories are in the wrong place, Claude itself might get confused about the context of the instructions. We definitely don't want that!

What Should Happen?

Expected Behavior

Ideally, the memory entry should be:

Dedicated Section: Added to a special "Project Memories" or "Project Context" section. This keeps things nice and organized.
Logical General Section: If not a dedicated section, then at least appended to a relevant general section.
NOT Unrelated Sections: Definitely shouldn't be thrown into unrelated sections like "Commit message format."

When we talk about the expected behavior of the #memory function, we're really focusing on how to optimize the workflow and maintain clarity within the project. A dedicated "Project Memories" or "Project Context" section would act as a central repository for all crucial project-specific information. This approach ensures that anyone working on the project can quickly find the details they need without having to search through the entire document. Alternatively, if a dedicated section isn't feasible, appending the memory entries to a logical general section would still be a significant improvement over the current behavior. The key is to ensure that the memories are placed in a contextually relevant location, making it easier for both humans and Claude to understand the information. Ultimately, the goal is to prevent the current situation where memory entries are inserted into unrelated sections, which not only creates confusion but also undermines the purpose of the #memory function itself. By implementing a consistent and logical placement strategy, we can enhance the overall usability and effectiveness of Claude Code in managing project information.

Error Messages/Logs

(No error messages or logs to report here, just the incorrect placement issue.)

Steps to Reproduce

Okay, so if you want to see this bug in action, here’s how you can do it:

Initialize a New Project: Use the /init command. This will create the CLAUDE.md file.
Work on the Project: Just do your thing, work on the project for a bit.
Add a Memory: Use #memory to add a project memory. For example, try something like: Don't ask me permission to run sed, awk commands in this project.
Check the CLAUDE.md File: Open it up and see where your memory entry landed.

To fully grasp the steps to reproduce this bug, it’s essential to understand the workflow that leads to the incorrect placement of memory entries. Starting with the initialization of a new project using the /init command ensures that we have a fresh CLAUDE.md file to work with. This file serves as the primary document for Claude Code to store and retrieve information about the project. Working on the project for a while, adding code, making changes, and encountering various scenarios is a crucial step because it simulates a real-world development environment. This is where the need for storing project-specific memories becomes apparent. When you use the #memory command to add a memory, such as Don't ask me permission to run sed, awk commands in this project, you are essentially telling Claude Code to remember this instruction for future reference. The key step, however, is checking the CLAUDE.md file afterward. By opening the file and examining where the memory entry has been placed, you can directly observe the bug in action. This hands-on approach not only confirms the issue but also helps in understanding the specific conditions under which it occurs, making it easier to communicate the problem to the developers and potentially contribute to finding a solution. The goal here is to create a clear, repeatable process that anyone can follow to verify the bug.

Actual Behavior

What’s actually happening is that the memory entry gets tacked onto whatever section happens to be last in the file. In my case, it ended up in the "Commit message format" section, which makes absolutely no sense:

Commit message format:

Use conventional commits (feat:, fix:, docs:, etc.)
Keep first line concise (50 chars max)
Include detailed explanation in body if needed
Don't ask me permission to run sed, awk commands in this project (Wait, what? This doesn't belong here!)

The actual behavior of Claude Code, where memory entries are appended to the last section of the CLAUDE.md file, highlights a significant flaw in the system's logic. The example provided, where the instruction Don't ask me permission to run sed, awk commands in this project ends up in the "Commit message format" section, perfectly illustrates the problem. This misplacement not only disrupts the logical flow of the document but also creates confusion and potential misunderstandings. The "Commit message format" section is specifically intended to outline the guidelines for writing commit messages, covering aspects such as the use of conventional commits, the conciseness of the first line, and the inclusion of detailed explanations in the body when needed. Inserting a memory entry about command permissions into this context is entirely out of place and makes it harder for anyone reading the file to quickly grasp the relevant information. This behavior underscores the need for a more sophisticated mechanism for placing memory entries, one that takes into account the context and content of the memory and ensures it is stored in a logically appropriate location. The goal is to maintain the clarity and coherence of the CLAUDE.md file, so it can effectively serve as a reliable source of project information. By addressing this issue, we can significantly improve the usability and value of Claude Code in managing project details.

Claude Model

(Not really related to the Claude model itself, so none here.)

Is this a regression?

I'm not sure if this is a new issue or if it's been around for a while. 🤔

Last Working Version

(No idea on this one.)

Claude Code Version

I'm running version 2.0.31.

Platform

Other

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

(Nothing else to add for now.)

So yeah, that's the bug! Hopefully, this gets sorted out soon. It's a bit of a pain when project memories end up in the wrong place. Let me know if you guys have seen this too, or if you have any other insights! ✌️