The Claude Code Memory Command: Debugging Which CLAUDE.md Files Are Loaded

What the Claude Code memory command does

The Claude Code memory command, written /memory, is the diagnostic window into your configuration. When you run it inside a session, it lists every memory file Claude has actually loaded, the user CLAUDE.md, the project and directory CLAUDE.md files, any CLAUDE.local.md, and the files in .claude/rules/, and lets you open any of them directly in your editor. It also exposes a toggle for auto memory, the separate system in which Claude writes its own notes across sessions. For configuration debugging, the listing is the part that matters.

Why does a command just for listing files deserve its own knowledge point? Because the most common configuration failures are not subtle content problems; they are a file that you believe is active but that Claude never loaded. Without /memory you are reduced to guessing why behaviour seems off. With it, you replace speculation with a fact: here is precisely what Claude is reading right now. That shift, from guessing to inspecting, is the entire point of this apply-level skill.

The one question /memory answers

Strip everything else away and /memory exists to answer a single question: is the configuration I think is loaded actually loaded? That sounds modest until you realise how many problems are really this question in disguise. Claude is not following your testing rule, your indentation standard seems ignored, a teammate gets different output, in a large fraction of these cases the instruction is simply not present in the session at all.

The reasoning chain is short and reliable. Run /memory. Scan the list for the file you expected. If it is there, the file is loaded and any remaining problem is about content, the instruction is vague, or it conflicts with another file, so you work on wording. If it is not there, you have found your bug without touching a single instruction: Claude cannot follow guidance it never received. The fix then becomes a location question rather than a prompting question.

Why a file might be missing from the list

When /memory shows that an expected file is absent, there are a handful of usual explanations, and each maps cleanly back to the configuration hierarchy. The most frequent is the launch directory: because Claude loads project and directory files by walking up from where you started it, launching from the wrong folder, a parent above the repo, or a sibling, means the project CLAUDE.md is simply out of the walk and never loaded. Another is a misplaced file: an instruction sitting in a location that is not one of the recognised scopes, so it is never picked up. A third is a personal versus shared mix-up, expecting a teammate's user-level rule to be present when it lives only on their machine.

In every case the value of /memory is the same: it converts a vague feeling that 'configuration is not working' into a concrete observation about which files are and are not loaded, and that observation points straight at the cause.

Using /memory on a real inconsistency

The command earns its place the moment you stop theorising and just look. The example below is the canonical shape: identical-seeming setups behaving differently, resolved in seconds by inspection.

Common misreadings to avoid

Both errors below lead people to skip the one step that would have told them the answer.

What the listing actually tells you

It helps to know what you are looking at when the command prints its output. The listing covers the configuration files Claude has loaded for the session: your user CLAUDE.md, the project and any directory CLAUDE.md files reached by walking up from the launch directory, any CLAUDE.local.md, and the topic files under .claude/rules/. Each entry can be opened directly in your editor from the command, so you are never more than a keystroke away from confirming not just that a file loaded but what it says. Alongside the file listing, the command also exposes the auto memory toggle, which is a separate system where Claude writes its own running notes; for configuration debugging you can usually ignore that and focus on the file list.

The two failure shapes the listing distinguishes are worth naming precisely. A presence failure is when an expected file is missing from the list entirely, which means Claude never loaded it and the cause is structural: wrong location, or the session launched from a directory that does not reach the file. A content failure is when the file is present but its instruction still is not followed, which means the wording is too vague, or it conflicts with another loaded file, or it is simply not specific enough to act on. The reason /memory is so valuable is that it tells you, in seconds and without ambiguity, which of these two very different problems you actually have, so you do not spend an afternoon rewording a file that was never loaded.

When the file is loaded but behaviour is still off: /context and /doctor

The /memory command answers the presence question, but two sibling commands extend the same inspect-first habit for the harder case where a file is loaded and the problem lies elsewhere. The first is /context, which shows everything occupying the current session's context window broken down by category: system prompt, memory files, skills, MCP tools, and conversation messages. Reach for it when configuration is loaded yet Claude still seems to lose track of it, because a crowded or near-full window can crowd out instructions in a way a plain file listing would never expose.

The second is /doctor, which validates your configuration files and surfaces invalid keys or schema errors. A CLAUDE.md can appear correctly in /memory while a neighbouring settings.json carries a mistyped key that silently breaks behaviour, and /doctor catches exactly the syntactic faults a file list cannot. When even that comes back clean, the documented way to isolate a stubborn problem is to strip configuration back to nothing: point CLAUDE_CONFIG_DIR at an empty directory and launch from a folder with no .claude directory, .mcp.json, or CLAUDE.md, then reintroduce each layer until the behaviour reappears.

Together these form a short diagnostic ladder. Use /memory to confirm what loaded, /context to see how it fits within the window, and /doctor to catch malformed settings, and you have ruled out the structural causes before you ever touch the wording of an instruction.

Building the inspect-first habit

The deeper skill this knowledge point teaches is a disposition, not a command: when configuration behaves unexpectedly, gather a fact before forming a theory. It is genuinely tempting to skip straight to a fix, to assume the rule needs strengthening, the model needs constraining, or the whole setup needs rebuilding, because acting feels like progress. But every one of those moves is a bet placed before the evidence is in, and when the real problem is a file that never loaded, each bet is wasted effort that leaves the actual cause untouched.

Inspecting first inverts that. Running /memory costs almost nothing and routinely collapses a vague, frustrating problem into a precise one: either the file is there, so work on its content, or it is absent, so work on its location. Architects who build this habit debug configuration in minutes; those who guess can spend hours rewording instructions that Claude was never going to see. The certification treats this as a hallmark of competence, which is why questions in this area so often reduce to one decision, do you inspect, or do you guess, and reward the candidate who reaches for the evidence the tool is designed to provide.

For configuration that loads conditionally, the same inspect-first instinct still applies, just with one extra wrinkle: a path-scoped rule or a nested subdirectory file may only appear once Claude has actually touched a matching file, so confirm you are in the right context before concluding a rule is missing. The principle is unchanged, look at what is loaded rather than theorise about it, but the timing of when a file shows up can itself be the clue that explains the behaviour.

A two-minute routine you can reuse

Make the command part of a fixed routine and configuration problems stop eating your time. The moment something seems off, run /memory, scan for the file you expected, and let its presence or absence decide your next move. If the file is missing, check where you launched Claude and whether the file sits in a recognised scope; if it is present, open it and look for vague wording or a conflicting instruction in another loaded file. The whole loop takes a couple of minutes and replaces an open-ended hunt with a definite answer you can act on.

What makes the routine reliable is that it never assumes; it observes. Configuration is one of the few places in agent work where you can see your inputs directly, and this command is the window onto them. Use it early and you rarely guess wrong; skip it and you can spend far longer fixing a problem you never correctly identified, because every fix you try is aimed at a cause you only assumed.

How this shows up on the exam

Domain 3 is worth 20 percent of the exam, and this apply-level knowledge point is tested as a methodology question: faced with inconsistent or surprising Claude Code behaviour, what is the correct first action? The answer the examiners are looking for is to inspect, run /memory to verify which configuration is actually loaded, rather than to immediately rewrite prompts, lower a model setting, or assume the assistant is simply unreliable. Carrying that instinct is also exactly what you need for the next knowledge point, where you use this same inspection to diagnose why two developers on one team behave differently.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

Official · Anthropic AcademyOpen full lesson in Academy

Troubleshooting skills

Why watch: Verifying what configuration is actually loaded with /memory is a key step in diagnosing skill problems.

More videos for this concept

Troubleshooting skills

Introduction to Agent Skills

Claude Code's Memory System: The Full Guide (Most Developers Miss 90% of This)

DIY Smart Code

The CLAUDE.md file

Claude

Master ALL 7 Levels of Claude Code Memory

Mark Kashef

MEMORY vs CLAUDE Files (What's the Difference?!)

Samuel Gregory