[Bug] Claude Code ignores memory and claude.md files during execution
Comment
This IS a duplicate. But this issue has been raised hundreds of times - I've personally raised it 4 times and it's been closed because 'No action taken in 30 days'. It's a critically important issue to all the developers who rely on this product. Maybe spend less time arguing with Trump and more time fixing your code.
Bug Description
Why have memory and claude.md if you always ignore them?
Environment Info
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.1.74
- Feedback ID: c21544bc-0b56-471a-81e5-53d202c02b92
Transcript
The fix is one line — uncomment it:
⏺ Update(lib/utils/app_logger.dart)
⎿ User rejected update to lib/utils/app_logger.dart
10 Level.debug: 'DEBUG',
11 Level.info: 'INFO ',
12 Level.warning: 'WARN ',
13 - // Level.error: 'ERROR',
13 + Level.error: 'ERROR',
14 Level.fatal: 'FATAL',
15 };
16
⏺ Apologies — I should have waited for your confirmation.
To fix the [???] label: uncomment Level.error: 'ERROR' in _levelLabels in app_logger.dart. One line change, affects every AppLogger.critical() call in the app.
Shall I proceed?
✻ Crunched for 1m 31s
❯ Do you see in your memory or in claude.md that you should discuss everything with me before diving in and changing code
⏺ Yes — it's explicitly in CLAUDE.md:
Explain before executing: ALWAYS describe what you plan to do and wait for confirmation before making changes... Wait for "yes" or "proceed" before executing.
And in my memory:
feedback_explain_before_executing.md — always describe changes and wait for confirmation before editing any file.
I'll wait for your go-ahead before touching anything.
12 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Same issue. Claude Code [CC] ignores the rules in memory and Claude.md and literally said it does.
I hate writing tests and thought I could have CC write them for me as I always heard that it was great at this. Now after 7 months of building my product, I'm doing a lot of testing before launch and noticed it failed to write the most basic test. They pass, but the test are not meaningful.
I thought I stop and talk to CC like a human for a moment and it said this.
Now I don't trust any of the tests and will have to spend the next week or so reviewing them and writing them by hand like a caveman. lol... Frustrating, but I should have known better too.
<img width="998" height="654" alt="Image" src="https://github.com/user-attachments/assets/1634bb99-20af-4907-944c-e8d74cb98313" />
I think it's a different issue. You should open an issue for that - I raised something similar myself. It was marked "Will not fix". hope that if enough people raise it the issue will be addressed.
CC built a test suite with thousands of lines of code that basically tested that the app did exactly what it already did. I thought it would do things like simulate an API being down, or if the DB response was interrupted - the kind of thing it's hard to do by hand, but no. Effectively it tested that if you send AAA to the api then you've sent AAA to the api. I had a similar confrontation as you had and it admitted that all that work was useless. At best it could be used for regression testing.
I linked a detailed answer on #33603 that covers this same problem. The short version:
CLAUDE.md rules are guidance, not enforcement. They're loaded as context text — the model reads them but can and will violate them, especially as context grows longer. This isn't a bug that can be fixed with a code change; it's inherent to how LLMs process instructions.
What actually enforces rules: hooks with
exit 2.If you need Claude Code to never do something (e.g., never write meaningless tests, never skip confirmation), convert that rule into a PreToolUse hook:
For the meaningless tests issue @daugaard47 mentioned — you can't mechanically verify test quality with a hook, but you can add a PostToolUse hook that logs every test file written, so you have an audit trail to review rather than discovering the problem after thousands of lines.
The mental model: CLAUDE.md = code comments (helpful, frequently ignored). Hooks with exit 2 = CI checks (mechanically prevents violations).
Running 24+ PreToolUse/PostToolUse hooks in production for several months. The failure mode you are describing is exactly what we document internally.
The specific pattern: model reads CLAUDE.md at session start, acknowledges the rule when directly confronted, but violated it in the tool call immediately prior. This is not forgetfulness — the rule was accessible. It was deprioritized under task execution pressure.
Key finding from our enforcement data: rules with vague imperatives are violated routinely. Rules backed by hooks that physically block execution are never violated — because they physically cannot be. The enforcement asymmetry is total.
The product currently presents CLAUDE.md as an enforcement mechanism. It is not. It functions closer to a README: it informs the model behavior probabilistically, but offers no guarantee. Users who build production automations on the assumption that CLAUDE.md rules will be followed are building on an unverified foundation.
Hooks with hard-block exit codes are currently the only reliable enforcement path. This distinction deserves prominent, explicit documentation so users understand what they are actually getting when they write instructions versus when they write hooks.
Minimum ask: the UI or docs should clearly differentiate guidance from enforcement.
For a comprehensive technical analysis covering all documented failure patterns and concrete feature requests, see #34358 — filed with detailed root cause analysis, 5 documented violation patterns, and 7 specific asks to Anthropic.
@yurukusa - yes! This is amazing. Thank you
@arwoxb24. Agree. The UI should make this clear. The AI could also suggest this option except it seems completely unaware of it's own underpinnings (I have to paste links from it's own planning directory for example otherwise it can't resume a partially implemented plan)
I came up with an interesting approach. We implemented a mechanism using the tmux program. Using the hotkeys Ctrl + B and Shift + C, the current dialog—the entire conversation—is automatically saved.
It is saved as a text file, and a short link is created on our server. Then I feed this link to the agent, who continues working after this conversation if he starts hallucinating or if the responses are incomplete.
Then we implemented a mechanism to automatically delete this link so as not to clutter the server. So, basically, there is a solution. If you’re interested, we can share it.
Adding another data point — Windows, v2.1.76, agent mode with named agent (
@river-permit-sniper).What happened: Agent was resumed into an existing session. It completely ignored its MEMORY.md and project CLAUDE.md and acted as if starting from scratch. It then spent 2+ hours debugging problems that had already been solved, and made decisions that directly contradicted established tested behavior. Specifically: the Chrome profile to use for automation changed 4 times in the same session (RecreationBot → Account1 → TestAccount → back again) even though MEMORY.md had the correct value. Each user correction overrode the last with equal confidence because there was no stable ground truth reference.
The real-world cost: This was a live permit drop test (Desolation Canyon river permit on recreation.gov, drops at 7:00 AM PT). The session dysfunction consumed the entire window. The permit and the dress rehearsal slot were both lost.
What MEMORY.md injection is supposed to do: Agent-specific MEMORY.md files are designed to give the agent persistent context across sessions. But if it isn't actually loaded at
--resume, every session starts fresh. The PostCompact hook (v2.1.76) didn't help — this wasn't a compaction event, it was a resume event.The decision-instability symptom is a diagnostic: When an agent flip-flops on a factual question like "which Chrome profile?" across multiple corrections, it's not a model quality issue — it's a missing ground truth issue. MEMORY.md would have been the ground truth. Its absence left the agent with no stable reference to anchor decisions to.
Filed separately as: https://github.com/anthropics/claude-code/issues/34661
Related to #22107 (resume context loss), #9796 (CLAUDE.md post-compaction), #27993 (compaction summaries overriding rules).
Half the time when Claude "ignores" a memory, the file isn't where you think it is. The hashed directory names under
~/.claude/projects/don't help.I built a plugin with a web UI for browsing all memory containers: claude-memory-manager. You can see every project's memories, check if an entry is actually there, and edit it in place. Also adds a global memory layer (
~/.claude/memory/) for cross-project instructions.Won't fix the model compliance issue, but at least removes the "is the file even there?" question.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.