A session cannot determine whether its auto-memory index loaded whole, truncated, or not at all

Environment

• Claude Code CLI v2.1.220
• macOS (Darwin 25.5.0)
• Main loop: Opus 5 (claude-opus-5[1m]). Subagents: Fable 5.
• Auto-memory at ~/.claude/projects/<project>/memory/, index MEMORY.md plus per-fact topic files.

The request

Expose, in-session, what auto-memory actually loaded, so a partial load is detectable when it happens rather than inferred later from behavior.

Why

Auto-memory can fail in three ways that are indistinguishable from inside a session:

1. The index exceeded its read limit and was truncated.
2. The index was not read.
3. The fact was written into a different project store.

In all three the observable result is the same: the session proceeds as though no such rule exists. It cannot flag "a rule may be missing", because it has no way to know a read was incomplete, so it states the negative with confidence.

That is what turns a capacity limit into a correctness problem. A store that fails partially and silently produces false negatives that read as ordinary answers.

Concrete instance

After a memory write, PostToolUse emitted this into the model's context:

The memory index at MEMORY.md is 161 lines, approaching the 200-line read limit. Compact it to under 140 lines now.

Two observations:

• It goes to the model, not the user. Nothing appeared in the CLI. I learned of it only because the assistant mentioned it in conversation.
• It fires only on write. A session that reads memory and never writes gets no equivalent signal, and that is most sessions.

State at time of filing: MEMORY.md at 161 lines against the 200 ceiling, indexing 131 topic files. It had been approaching the ceiling for an unknown period with nothing user-visible.

Related: write scope is not surfaced

Auto-memory is keyed to the Claude Code project directory. A fact can be written from a session whose project path differs from the tree the work runs in. The write succeeds, the index line appears, and the fact is unreachable from the sessions that need it. Nothing indicates this at write time or read time.

This asks only that the current keying be visible, not that it change.

What it cost in practice

A process ruling was saved to auto-memory the day it was given, and not also into the working tree's own operating documents. That tree resolved to a different project path, so later sessions never saw it.

Those sessions ran on hand-written prompts that restated the process from recollection. Over seven days it drifted three times, including two conventions that contradicted the written process inside the same file that referenced it. A decision ledger stopped updating while automated passes continued, and one expected output file was never created.

The project had no version control, so the drift could not be diffed. Reconstructing it took a dedicated audit pass of roughly 118k subagent tokens and produced no product output.

No individual write failed. Every component behaved as designed.

Steps to reproduce

A. No load verification

1. Start a session in a project with a populated memory store.
2. Attempt to determine whether the index loaded whole. There is no available check, in-session or via a CLI flag.

B. Warning is model-facing and write-only

1. Grow MEMORY.md past roughly 160 lines.
2. Trigger a memory write. The size warning arrives as a PostToolUse note in the model's context. Nothing surfaces in the CLI.
3. Start a session that only reads memory. Observe no equivalent signal.

C. Write scope is invisible

1. From a session whose project path is A, record a fact concerning work that runs in tree B.
2. The write succeeds with no scope indication.
3. Start a session in tree B. The fact is absent, with no indication it exists elsewhere.

Proposed behavior

Any one of these would close the gap, listed cheapest first.

1. A one-line load receipt in-session: index lines read, whether truncated, topic file count, resolved store path. Enough for a session to say "my memory may be incomplete" instead of asserting a negative.
2. Surface truncation to the user in the CLI, on read and not only on write.
3. A claude memory status style command: store path, index size against limit, whether the last session read it whole.
4. Show the resolved store path at write time, and flag when the fact concerns a tree outside that store.

Related issues

Listed to save triage time, not as duplicates.

• #79217 asks for the 200 line / 25KB limit to be configurable. This issue is not about the size of the limit.
• #77647 asks for the read-limit error to be documented. This is about a runtime signal rather than docs.
• #75334, #76408, #81833 report that memory is not reliably read or applied. Item 1 above would make reports of that shape diagnosable rather than anecdotal.
• #76647, #72049, #81391, #81808 concern how the store is keyed. This issue asks only that the existing keying be visible.

Current workaround

Durable state moved onto mechanisms that do not depend on the memory read succeeding: SessionStart hooks that print the operative document, version control so drift appears as a diff, and rules written into the documents the work itself opens. Memory is used as an index only.