Stale project identity in ~/.claude.json / auto-memory persists after repo relocation (related to #53734, #52772)

Summary

We independently reproduced a variant of the auto-memory path-resolution
issue reported in #53734 (closed as duplicate of #52772, both now
locked, so filing as a new issue that references both).

In our case the divergence is not a parent/child (ancestor) directory
relationship as described in #53734's Hypothesis B, but a stale
cached project identity that survives a repository relocation to a
completely unrelated absolute path — closer to #53734's Hypothesis A
("cached template ... persists" even after the underlying condition
changes).

Environment

• Claude Code: 2.1.221 (Claude Code)
• OS: macOS 26.3 (Build 25D125)
• Node.js: v25.8.2
• Setup: multiple concurrent Claude Code sessions on the same machine

running against the same git repository, checked out at two
different absolute paths at different points in time (a "legacy"
checkout path A, and a "current" checkout path B, unrelated by
ancestry — verified via git remote -v and matching root commit
hash that both are the same logical project)

Observed

1. ~/.claude/projects/<A-encoded>/memory/ and

~/.claude/projects/<B-encoded>/memory/ both exist and both
contain memory files with recent modification timestamps (147 and
~490 files respectively across two sub-paths of B), i.e. both
locations kept receiving writes concurrently well after we
stopped using path A as our primary working directory.

1. The top-level projects registry in ~/.claude.json (keyed by

absolute cwd, holding fields like lastSessionId) contains an
entry for path A that continued to be updated, but contains no
entry at all for path B or its subdirectories, despite B
being the actively used location for weeks, with hundreds of
auto-memory files and daily commits.

1. This produces the same practical symptom as #53734/#52772: the

registry / auto-memory resolver's notion of "which project this
cwd belongs to" does not track the actual cwd reliably once a
project's working copy moves. Unlike #53734's repro (sibling cwds
under a shared ancestor), our two paths share no filesystem
ancestry — the only thing that ties them together is that they are
two checkouts of the same git remote at different times. This
suggests the stale-identity behavior isn't purely a "walk up the
directory tree" algorithm (Hypothesis B) but something closer to a
cached/sticky project-identity resolution that isn't
re-derived from the live cwd (Hypothesis A), possibly keyed on
something other than the literal encoded cwd path (e.g. project
metadata cached at first registration).

Reproduction steps

1. Clone a git repo at absolute path A. Use Claude Code there enough

to populate ~/.claude/projects/<A-encoded>/memory/MEMORY.md.

1. Move/re-clone the same repo to a **different, unrelated absolute

path B** (not a parent or child of A). Use Claude Code
exclusively from B going forward, for at least several sessions
over multiple days.

1. Inspect ~/.claude.json's projects object. Compare the entry

(or lack thereof) for A vs B.

1. Inspect ~/.claude/projects/<A-encoded>/memory/ and

~/.claude/projects/<B-encoded>/memory/ for file counts and
modification timestamps. Check whether A's memory directory
keeps receiving new files after step 2's cutover.

Why this matters

We run several Claude Code sessions per day against the same
repository under a multi-agent-style workflow (distinct sessions,
sometimes distinct working subdirectories, all under one git repo).
The registry/auto-memory divergence means:

• auto-memory content silently accumulates in a location that active

sessions may never read back (their # auto memory template may
point at path B's encoded directory, or under some conditions at
a stale identity), producing exactly the "confident continuity with
the wrong lineage" risk that other reporters flagged on #53734.

• There's no user-facing signal that the registry and the actual

memory-write location have diverged; it required manual, ad hoc
inspection of ~/.claude.json and the ~/.claude/projects/
directory tree to notice.

Suggested fix (same spirit as #53734's suggestion)

• Re-derive the project identity / memory path deterministically from

the live cwd at each session start, rather than relying on any
cached identity from first registration.

• If a previously-registered path is detected to differ from the

live cwd's canonical encoding, surface this explicitly (e.g. a
one-time notice) rather than silently continuing to write to the
old location or leaving the registry stale.

References

• #53734 (closed, duplicate, locked)
• #52772 (closed, duplicate target, locked) — describes a related but

distinct symptom (system prompt path vs /memory-created path
mismatch within a single monorepo)