[BUG] Memory directory resolves to wrong project hash

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The session's persistent memory directory (given in the system prompt's "Environment" section) resolved to a project-hash folder that did not match the actual working directory attached to the session.

The system prompt specified a memory directory whose hashed folder name correctly corresponded to the session's actual working directory (Project A). However, throughout the entire session, memory reads/writes actually went to a completely different, unrelated project's hash folder instead (Project B) -- not a slug-variant of the same path, but a different project entirely.

Confirmed mid-session by listing both directories: the correct memory folder for Project A was completely empty, while Project B's folder contained all the memory files actually being read/written by the tool (dated from a prior session, well before this one started). The content itself was legitimate/relevant to that user's other project, just filed under the wrong project-hash folder -- suggesting the client mis-resolved which project hash to associate with the memory tool for this session, rather than picking stale/random content.

This looks related to #76647 (same-path slug drift) but appears to be a distinct root cause: here the memory tool bound to an entirely unrelated project's folder, not just a differently-hashed variant of the same path.

Workaround used: manually copied the memory files from the wrong project's folder into the correct one mid-session.

What Should Happen?

The memory directory that the memory tool actually reads/writes should always match the memory directory path stated in the system prompt for that session, i.e. it should resolve consistently to the project associated with the session's working directory -- never to an unrelated project.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code in a project directory (Project A) and do some work.
2. Ask Claude to check/list its persistent memory directory (as given in the system prompt's "Environment" section) and compare it against the actual on-disk contents.
3. Observe that the memory directory named in the system prompt is empty, while another project-hash folder under ~/.claude/projects/ -- corresponding to a completely unrelated project (Project B), not a slug-variant of Project A's path -- contains memory files that are actually being read from and written to by the memory tool during this session.
4. Confirm by writing a new memory note during the session and checking which folder on disk actually received the file.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.37937.1 (edbd3c), 2026-08-25

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Possibly related to a cluster of similar memory-path-resolution issues, though none appear to be an exact match for this specific symptom (wrong project entirely, not wrong location within the right hierarchy): #76647 (same path resolves to two different slugs across sessions), #55450 (closed, memory written into the project working directory instead of the correct path -- also references #36973, #52772, #53336).