Claude Code's /memory Command Doesn't Fix the Staleness Problem

When people hear that CLAUDE.md drifts, a common response is: that is solved now — Claude Code has the /memory command and @import syntax. You can add memories on the fly and split your context into tidy included files. It is a genuine improvement. It is also an improvement to the wrong thing. Better tools for editing a static file produce a better-organized static file — not a self-updating one.

What these features actually do

It is worth being precise, because the features are useful and the confusion is understandable:

What /memory and @imports actually improve

  /memory            -> quick way to add/edit lines in CLAUDE.md
  @path/to/file.md   -> split CLAUDE.md into included sub-files
  ~/.claude memory   -> personal notes layered on project notes

  All real conveniences. All about EDITING and ORGANIZING.
  None of them re-read the codebase. None of them detect drift.
  None of them update when the code changes.

/memory makes it faster to write down a fact. @imports make it neater to organize the facts you have written. Both operate on the same artifact: a hand-authored description of the code that sits in the prompt. Neither reads the repository, compares itself to current source, or notices when a fact it holds has stopped being true.

The staleness problem is untouched

The reason CLAUDE.md drifts is not that editing it was too hard. It is that the code changes and the file does not. Making the editing easier does nothing about the part where the code changes:

Better tooling, same failure mode

  You /memory: "auth lives in app/auth/helpers.py"
    -> written as a fact, frozen at write time

  Six weeks later the auth helper is deleted in a v2 migration.
    -> the memory does not know
    -> /memory did not re-check
    -> @import pulled the same stale line into the prompt
    -> the agent confidently uses the dead path

  Organizing a wrong fact more neatly does not make it true.

This is the exact failure described in remembering wrong: a memory written as a confident fact, frozen at write time, that the model later trusts against code that has moved on. /memory made it easier to create that frozen fact. It added no mechanism to keep it true.

Easier to write means more facts to rot

There is a subtler effect. Lowering the friction of adding memories means you add more of them. Each one is another hand-authored claim with its own staleness clock, and the same asymmetry applies that drives CLAUDE.md length upward: it is easy to add, awkward to prune. So the volume of frozen assertions grows, and the share of them that is still accurate quietly falls. Convenience accelerated the very accumulation that causes the drift.

Asserted facts vs. derived facts

The distinction that matters is where the facts come from. /memory and @imports hold facts a human asserted. A semantic index holds facts derived from the code itself, and re-derived when the code changes:

Hand-authored memory vs. derived index

  /memory + @imports:
    -> humans assert facts about the code
    -> facts frozen at authoring time
    -> freshness depends on someone re-editing

  Derived semantic index:
    -> facts extracted from the code itself
    -> re-derived as the code changes
    -> freshness is a property of the system, not a chore

When grounding is derived rather than asserted, freshness stops being a discipline problem and becomes a property of the system. Nobody has to remember to run /memory after a refactor, because the representation was never a hand-written claim in the first place.

Where Kognita fits

Kognita derives its representation directly from your source and re-indexes as the codebase changes, then serves the relevant slice to the agent on demand. There is no memory to curate, no imports to keep in sync, and no frozen assertion waiting to mislead the model after the code moves. Use /memory for what it is good at — your personal preferences and genuinely stable team norms — and let a derived index carry the facts about the code, which are exactly the facts that go stale.

Final take

/memory and @imports are good ergonomics on a fundamentally static artifact. They make it easier to write and organize claims about your code; they do nothing to keep those claims true as the code changes.

Easier editing is not freshness. Facts you assert by hand freeze the moment you write them — only facts derived from the code can stay current as the code does.