Project memory/session storage collides across different projects due to non-ASCII path slug encoding
Summary
Claude Code derives a project storage directory (under ~/.claude/projects/) by
converting the working-directory path into a slug. Non-ASCII characters (e.g. Korean)
appear to be collapsed into a generic - regardless of their actual content, so two
completely different folder names can produce the identical slug. When that happens,
the new project silently inherits (and can overwrite) the memory/session data of an
unrelated — even long-deleted — project.
Steps to reproduce
- Create folder A:
C:\Users\<user>\Downloads\근평 웹만들기, start a Claude Code
session there, let it save project memory (~/.claude/projects/<slugA>/memory/*.md).
- Delete folder A entirely from disk.
- Create an unrelated new folder B:
C:\Users\<user>\Downloads\비계량지표평가,
start a Claude Code session there.
- Observe: Claude Code loads memory files that were written for folder A's project
(a Supabase-based HR evaluation web app) inside folder B's session (an unrelated
HWP/PDF parsing tool), because both paths encoded to the same slug
C--Users-<user>-Downloads-------- (dash count happened to match).
Expected behavior
- The slug/identifier for a project's storage directory should be unique per real path
(e.g. via a hash of the full path, or percent-encoding non-ASCII bytes instead of
collapsing them to a fixed placeholder).
- Ideally, storage for a path that no longer exists on disk should not be silently
reused by an unrelated new path.
Actual behavior
- Multiple distinct Korean-named folders under the same parent produced slugs that
differ only in dash count, and in this case two different names collided on the
same count, merging their project memories.
- The stale project's storage was never cleaned up after its source folder was deleted,
and was silently "revived" by the new project.
Impact
- Cross-project data leakage: one project's persistent memory/context appears in an
unrelated project's session, which is confusing and could expose unrelated
business/technical details across projects.
Environment
- OS: Windows 11 Pro (10.0.26200)
- Shell: Git Bash / PowerShell
- Claude Code (desktop app, Code tab)
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Follow-up note: as a stopgap, I'm renaming my affected project folder to include an
ASCII prefix (e.g.
근평 웹만들기->eval-근평 웹만들기) so its slug no longer collapsesto an all-dash string that could collide with another folder.
This works, but it shouldn't be necessary — users shouldn't have to rename their own
project folders (which may already be referenced elsewhere, in shortcuts, docs, other
tools, etc.) just to avoid silently inheriting an unrelated project's memory/session
data. Flagging this as an additional argument for fixing the slug derivation itself
(e.g. hash the full path, or percent-encode non-ASCII bytes) rather than leaving
non-ASCII-named folders permanently at risk of collision.
Helpful repro — the lossy slug is the root, and the orphaned store is the amplifier.
A few notes that may help triage / anyone hitting this:
-throws away the only distinguishing bytes. Safer identifiers for~/.claude/projects/<id>/:Dash-count uniqueness is fragile; it only worked until two names produced the same length of collapsed dashes.
memory/*.mdaround forever means a later path that does collide (or a rename that remaps) can revive stale project memory. A cheap operator check: if the decoded/original path no longer exists on disk, mark the store orphaned (or refuse to load it without an explicit “adopt this memory?” step).~/.claude/projects/for near-identical all-dash slugs under the same parent and delete/archive the dead one. That stops silent cross-project leakage without renaming every working folder.Happy to re-test on Windows once slug derivation stops being lossy.
Independent confirmation, with a control group and a measured blast radius: same parent directory, two 3-character Korean names collide completely; a 4-character name under the same parent does not. On a working machine, 2 of 1,085 stores hold 8 different projects — one store is shared by six unrelated client projects and holds 80 auto-memory files.
The ASCII half of the same encoding (#29471, closed as
COMPLETEDby the duplicate bot) also still reproduces on 2.1.238:…\ab-cdand…\ab\cdresolve to one store.I filed the full write-up as #93960 because it covers the encoding as a whole rather than the non-ASCII case alone — maintainers should feel free to merge it here. Your report is what made me go check my own machine; thank you for filing it.