Claude behaves differently across sessions. Sometimes conventions are followed, sometimes ignored. The first diagnostic step is not guessing, not attributing to randomness, not duplicating content. It is running /memory to see which files are actually loaded.
/memory vs MEMORY.md
/memory command — Run within a session. Shows which memory files are currently loaded. This is the ground truth of what Claude has access to.
MEMORY.md file — An index that points to memory files by path. A file listed in MEMORY.md may not be loaded if the referenced file does not exist, has malformed frontmatter, or was moved to a different path.
MEMORY.md says what should load. /memory shows what actually loaded. When they disagree, /memory is correct.
The Most Common Failure: Path Mismatch
A teammate reorganizes the memory directory structure. One developer reports Claude no longer recalls architecture context. Running /memory confirms: the architecture file is not in the loaded list, though the file still exists on disk.
The root cause: MEMORY.md still references the file at its old path. After the reorganization, the index pointer no longer matches the file’s actual location. The fix: update the path in MEMORY.md.
Frontmatter Errors Cause Silent Failures
A team migrated project context to memory files. Week 1: /memory showed all 5 files loaded in 90% of sessions, accuracy at 96%. Week 2: only 60% of sessions had all 5 files loaded, accuracy dropped to 78%. The change: a teammate updated frontmatter on 2 memory files.
The frontmatter update likely introduced formatting errors — invalid YAML, wrong indentation, missing fields — causing those 2 files to silently fail loading. /memory would have caught this immediately by showing only 3 of 5 files loaded.
Memory file loading is not probabilistic. It is not random. If /memory shows different files across sessions, there is a specific configuration cause.
Systematic Debugging Across Config Layers
When Claude’s behavior deviates from expectations with multiple config sources (CLAUDE.md, .claude/rules/, memory files):
/memoryat session start — verify all expected memory files are loaded- CLAUDE.md — check content is correct and present
.claude/rules/paths — verify glob patterns match the files being edited
Compare actual loaded configuration against expected configuration at each layer. The layer where they diverge is the source of the problem.
For CI pipelines, add a /memory check step that logs loaded files. Compare logs between consistent and inconsistent runs to identify which memory files correlate with quality differences.
Anti-Pattern: Assuming Randomness
A team has inconsistent Claude behavior across members. The response: “Claude is just non-deterministic, let’s add retry logic.”
This skips the diagnostic step. Cross-session inconsistencies almost always indicate configuration loading differences — missing files, broken paths, or formatting errors. /memory reveals these in seconds. Retry logic solves nothing when the root cause is a missing configuration file.
What Does Not Exist
claude --list-memorycommand-line flag- Settings panel with Memory tab
- Memory file priority tags in frontmatter
- Memory path caching between sessions
- Modification timestamp-based loading — timestamps do not affect loading
- Automatic relevance filtering — memory files either load or they don’t
One-liner: Run /memory to see what is actually loaded in the session — MEMORY.md is an index of what should load, not a real-time report of what did load.