Auto memory: months-old MEMORY.md silently loads into every session — no freshness indication, no expiry

Environment

• Claude Code v2.1.222 (also observed on v2.1.219 / v2.1.221)
• Claude Desktop (Code tab), Windows 11 Pro (build 26200)

Summary

Auto memory (~/.claude/projects/<project>/memory/MEMORY.md) loads at the start of every session (first 200 lines / 25KB), but nothing tells the user how old that memory is.

We found a MEMORY.md whose index was last written ~3 months ago (topic files 3–5 months old). Its top-level description of the repository — the first thing every session would read — described a project that no longer exists in that form; the workspace had since grown into something entirely different. Every new session would have been primed with a stale world-model.

We only avoided impact because autoMemoryEnabled: false had been set explicitly. Auto memory is on by default, so a settings reset, reinstall, or new machine profile would silently re-enable loading of the stale memory into every session.

Why this matters

1. Default-on + silent load: the user gets no signal that months-old notes are being injected.
2. Repo-scoped sharing: memory is keyed to the git repository. In a monorepo-style workspace with many parallel workstreams, one stale or wrong learning propagates to all of them.
3. No freshness surface: neither session start nor /context shows when MEMORY.md was last modified. Users only discover staleness if they happen to open /memory.

Suggestions

• Warn at session start (or in /context) when MEMORY.md has not been modified for N days.
• Surface the modified frontmatter timestamp (v2.1.214+) for the loaded index.
• Optionally: skip auto-load (or ask for confirmation) for memory untouched for a long period.

Notes

• Searched existing issues for auto-memory staleness (e.g. "auto memory stale"); found none addressing this. Related open auto-memory issues (#77261, #79217, #83114, #81833) cover injection control, size limits, scale, and worktree consistency — not freshness.