Proper location of MEMORY.md?

[stephtara]

Is .claude/projects/[working-folder-path]/memory/ where PAI should be keeping MEMORY.md, tons of feedback files and other assorted "memories"?
MEMORYSYSTEM.md describes a memory structure in ~/.claude/MEMORY/ which doesn't seem to be used much. Anybody know what's going on?

[wojteksbt]

Two different systems, and the collision is the whole story.

.claude/projects/[session-path]/memory/ — Claude Code's native auto-memory (Anthropic's, not PAI's). The model writes free-form feedback_*.md / project_*.md files there whenever it decides something is worth persisting, following instructions Claude Code injects at session start.

~/.claude/MEMORY/ — PAI's structured operational memory: WORK/ (Algorithm PRDs), LEARNING/SIGNALS/ (ratings), LEARNING/SYNTHESIS/ (harvested patterns), STATE/ (runtime). It's actively used — just not as a drop-zone for ad-hoc "memories".

The fundamental issue: PAI doesn't acknowledge that auto-memory exists. MEMORYSYSTEM.md predates the Anthropic feature, so the architecture still assumes PAI is the only memory layer — no suppression, no integration. At session start the model gets two independent "save your memories here" protocols, and since Anthropic's is much more prescriptive about when to save, it wins. That's why projects/.../memory/ fills up and ~/.claude/MEMORY/ looks unused for free-form stuff.

Architecturally they're opposites: PAI wants preferences derived from signals (ratings, harvested corrections) via SessionHarvester / LearningPatternSynthesis. Auto-memory is model-driven ad-hoc writes. They clash exactly in the "remember user preferences" zone.

My guess is v5 will close this — either suppress Anthropic's protocol and route everything through PAI's hooks, or have synthesis emit derived preferences loaded at session start. Speculation, but the gap is real.

[stephtara]

So that means that when my DA is explaining to me it's creating a feedback file memory for xyz, that's not "PAI talking" but Claude Code?

Do we have a timeline regarding v5.0? I'm guessing that in the meantime the best thing to do is let things be and sit tight...

[acq23]

Malheureusement il n'y en a pas.
Look here...#1096

[Drizzt321]

So there is capture happening, but "closing the loop" hasn't been fully implemented. There are a few different discussions around that that you can find. Hopefully we'll have at least a partially better solution in forthcoming v5.0.

Something that might be of related interest, if you've added to the steering rules, to help keep it knowing those rules and keeping them in mind, I've found they really need to be pulled in to CLAUDE.md, rather than loaded in via session start hook like they are now. I have a discussion & gist describing the reasoning and how to do it #1060. It's been a HUGE change for me.

Used to be despite me keeping on saying "don't just jump and start changing stuff, we're still discussing". Now it very, very rarely happens. It keeps those sort of steering rules in place, and says "as per the rule, I haven't do anything yet, want me to go do it now?"

[danielmiessler]

Hey @stephtara, thanks for raising this, and sorry it sat for a while.

We're changing how LifeOS ships. Instead of cloning a full ~/.claude directory and running it as a complete system, LifeOS is becoming a skill you install through an agentic installer. The installer hands integration to your own AI, which reads your actual machine (your OS, your paths, your harness) and wires the hooks and system prompt in where they belong.

That's aimed right at what you hit here. The old "one directory, one layout, hope it matches your setup" approach is exactly what broke for so many people, and the new model should handle it far better because your AI does the integration per machine instead of us guessing.

So we're closing this in prep for that release. If it still bites you once the skill-based version is out, reopen or file a fresh one and we'll jump on it. Appreciate you taking the time.