Global memory store is never loaded, and the model is not told it exists

## Summary

There are two on-disk memory stores, and only one of them is ever loaded:

| Store | Path | Injected at session start? |
|---|---|---|
| Project-scoped | `.claude/projects//memory/MEMORY.md` | **Yes** |
| Global | `.claude/memory/MEMORY.md` | **No** |

The system instructions the model receives describe **only** the project-scoped one ("You have a persistent file-based memory at `.../projects//memory/`"). The global store is **never mentioned**, so the model does not know it exists and never reads it.

On my machine the global store holds ~41 notes — exactly the cross-project knowledge memory is for: how to reach internal services, environment access, build gotchas.

## Why this is worse than a missing file

1. **The model re-derives what is already written down, and often gets it wrong.** Real case: a full session spent establishing how to read a ticket from a self-hosted Jira Server, concluding that a CLI had to be installed. A global note written and verified eleven days earlier said it is readable over REST with a token already in the environment — no VPN, no CLI.

2. **The model writes project-scoped notes that contradict global ones.** Not knowing the global store exists, it wrote an access note that said the opposite of the global one. From then on the wrong copy wins, because it is the only one injected.

3. **The user's correction loop cannot work — and this is what makes the bug expensive.** The user says "fix your memory"; the model fixes the *project* store, which is not where the truth lives; the next session repeats the same mistake identically. Both sides believe it has been fixed. The failure is silent, and it makes the whole memory feature untrustworthy: the user stops believing corrections stick, because they observably don't.

## Suggested fixes, in order of effectiveness

- **Inject the global `MEMORY.md` too**, alongside the project one.
- If injecting it is too costly for context, **at least name it in the instructions**: tell the model that it exists, where it is, and that it should be consulted. Today it is not mentioned at all.
- **Tell the model which store to write to.** With no rule, everything lands in the project store — including knowledge that applies everywhere. That is how divergent copies are born.
- **Surface conflicts**: two notes on the same subject in the two stores should be flagged rather than left to contradict each other silently.

## Steps to reproduce

1. Write a note in the global memory store (e.g. how to reach some service).
2. Open a new session in any project and ask for something that note covers.
3. The model does not read it, reconstructs the procedure from scratch, and frequently gets it wrong.
4. Correct it — the correction is written to the **project** store, creating a second, divergent version. Repeats indefinitely.

## Note

A model can partially mitigate this by writing a line at the top of the project index saying "a global memory store also exists, read it". That works, but only for a project where it happened to write that line once; in a new project the bug reappears intact.

## Environment

Claude Code desktop app, Windows.

Start by locating the code that loads `.claude/projects//memory/MEMORY.md` and assembles the session system instructions. Trace how `.claude/memory/MEMORY.md` is handled, then verify that the global store is available to the model and that the instructions identify both stores and their intended use.

Written by the indexing model from the issue text.