[BUG] auto-memory cache path silently stale/wrong-directory, causing a real safety rule to be missed (recurrence of #52772/#53734)

Summary

Reopening the underlying problem behind #52772 (closed stale) and its duplicate #53734 (closed as duplicate) — both closed without an upstream fix, and it caused concrete, harmful behavior today: a real user-authored safety rule in project memory was silently invisible to a session because the auto-memory system prompt block was sourced from the wrong local cache directory.

What's Wrong?

Session's cwd (both Primary working directory in the system prompt and actual shell cwd) was /home/<user>/source/soft-shop, the root of a git repo with its own populated memory/ directory. The expected auto-memory cache path for this cwd is ~/.claude/projects/-home-<user>-source-xyz/memory/.

Instead, the injected # auto memory system-prompt block came from ~/.claude/projects/-home-<user>/memory/ — the cache directory for the ancestor directory /home/<user> (not a git repo, no CLAUDE.md of its own). This matches #53734's stated mechanism exactly: the harness appears to cache the auto-memory template based on whichever project directory was created first, and doesn't re-resolve it even when the session's actual cwd/git-root is a different, more specific path.

Neither cache directory actually matched the repo's authoritative memory/ directory once diffed file-by-file — both were significantly behind (202 files missing combined across the two, not just the ancestor one), meaning the project's own "mirror memory to local cache" step had been silently failing across many sessions, invisibly, because there was no way to detect the mismatch from inside a session — the chosen cache path is never surfaced anywhere in the visible system prompt or transcript.

Concrete harm

A memory file added the previous day, instructing the assistant never to git push origin main on this repo without explicit user go-ahead, existed only in the repo's authoritative memory/ and was missing from both local caches. The session never saw it and pushed to main three times in one session before a human caught it and had to stop the assistant explicitly.

Why reopening instead of a new issue

#52772 and #53734 both describe the same resolution mechanism and were both closed without a shipped fix (one by staleness bot, one as an auto-closed duplicate) — this is a live recurrence with fresh evidence, not a new bug shape. Filing fresh in case a closed/stale issue doesn't get re-triaged.

Suggested fix

At minimum, surface which cache path was actually resolved somewhere in the system prompt or a /memory diagnostic, so a mismatch is at least detectable from inside a session instead of requiring a manual directory diff to discover by accident. Re-resolving the auto-memory path against the actual git-root (or cwd) on every session start, rather than a cached template from first-creation time, would fix the root cause per #53734's own diagnosis.

Environment

• Platform: Linux (Fedora)
• Reproduced 2026-08-29, same underlying mechanism as #52772/#53734

Local mitigation applied (workaround, not a fix)

Added a SessionStart hook step that mirrors the repo's authoritative memory/*.md into every known local cache path on every session start, so which one the harness picks is no longer consequential. This doesn't address the root cause — the resolver still silently picks an arbitrary cache path — it only neutralizes the symptom for this one repo.