Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Non-ASCII project path encoding causes memory directory collisions for CJK users [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46071•Fetched 2026-04-11 06:29:44
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
TonyPositiveTonyPositive
Participants
TonyPositiveTonyPositive
Timeline (top)
labeled ×4unlabeled ×1

Error Message

Error Messages/Logs

No error messages — Claude silently uses the wrong memory directory without any warning.

Root Cause

Because all three company names are 4 Chinese characters → ----. The directories are identical, and Claude mixes up memories between completely different projects.

Code Example

No error messages — Claude silently uses the wrong memory directory without any warning.

---

1. On Windows (or any OS), create two project folders with different CJK names of the same character count, e.g.:
   - D:\Projects\大明科技\
   - D:\Projects\大華實業\
2. Run `claude` in the first folder, let it save some memories
3. Run `claude` in the second folder
4. Check ~/.claude/projects/ — both folders map to the same directory
5. Memories from the first project appear in the second project's context

---

This was previously reported in #19972 but was auto-closed by a bot due to inactivity before being addressed. The underlying bug still exists.

The current dash-replacement approach is fundamentally broken for any non-ASCII locale. Even if two paths have different CJK characters, as long as the character count and ASCII prefix match, they collide. This is a data isolation / security concern, not just a cosmetic issue.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

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

What's Wrong?

Claude Code encodes project paths by replacing all non-ASCII characters with - when creating the ~/.claude/projects/ directory structure.

For CJK users, this causes real directory collisions. Example — three different project folders:

D:\Projects\大明科技
D:\Projects\大華實業
D:\Projects\天成企業\

All become the same memory path:

~/.claude/projects/D--Projects-----/memory/

Because all three company names are 4 Chinese characters → ----. The directories are identical, and Claude mixes up memories between completely different projects.

In my case, confidential data (credentials, network configs) from Project A leaked into Project B's memory. I had to manually audit and clean every memory file.

Taiwan alone has over 1.6 million registered companies, most with 2–4 character names. This is not a theoretical risk — collisions happen constantly in real CJK workflows.

What Should Happen?

Claude Code encodes project paths by replacing all non-ASCII characters with - when creating the ~/.claude/projects/ directory structure.

For CJK users, this causes real directory collisions. Example — three different project folders:

D:\Projects\大明科技
D:\Projects\大華實業
D:\Projects\天成企業\

All become the same memory path:

~/.claude/projects/D--Projects-----/memory/

Because all three company names are 4 Chinese characters → ----. The directories are identical, and Claude mixes up memories between completely different projects.

In my case, confidential data (credentials, network configs) from Project A leaked into Project B's memory. I had to manually audit and clean every memory file.

Taiwan alone has over 1.6 million registered companies, most with 2–4 character names. This is not a theoretical risk — collisions happen constantly in real CJK workflows.

Error Messages/Logs

No error messages — Claude silently uses the wrong memory directory without any warning.

Steps to Reproduce

1. On Windows (or any OS), create two project folders with different CJK names of the same character count, e.g.:
   - D:\Projects\大明科技\
   - D:\Projects\大華實業\
2. Run `claude` in the first folder, let it save some memories
3. Run `claude` in the second folder
4. Check ~/.claude/projects/ — both folders map to the same directory
5. Memories from the first project appear in the second project's context

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.98 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This was previously reported in #19972 but was auto-closed by a bot due to inactivity before being addressed. The underlying bug still exists.

The current dash-replacement approach is fundamentally broken for any non-ASCII locale. Even if two paths have different CJK characters, as long as the character count and ASCII prefix match, they collide. This is a data isolation / security concern, not just a cosmetic issue.

extent analysis

TL;DR

The most likely fix is to modify the path encoding mechanism in Claude Code to handle non-ASCII characters in a way that prevents directory collisions.

Guidance

  • Investigate alternative encoding schemes, such as URL encoding or Base64 encoding, that can uniquely represent non-ASCII characters in project paths.
  • Consider adding a unique identifier to each project's directory path to prevent collisions, even if the encoded project names are the same.
  • Review the current implementation of the ~/.claude/projects/ directory structure and consider revising it to accommodate non-ASCII characters in a more robust way.
  • Test the modified encoding scheme with various CJK character sets to ensure it can handle different character counts and combinations.

Example

import urllib.parse

# Example of using URL encoding to encode non-ASCII characters
def encode_project_path(project_path):
    encoded_path = urllib.parse.quote(project_path)
    return encoded_path

# Test the encoding function with a CJK project path
project_path = "D:\\Projects\\大明科技\\"
encoded_path = encode_project_path(project_path)
print(encoded_path)

Notes

The current dash-replacement approach is indeed fundamentally broken for non-ASCII locales, and a more robust encoding scheme is needed to prevent directory collisions and ensure data isolation.

Recommendation

Apply a workaround by modifying the path encoding mechanism to use a more robust encoding scheme, such as URL encoding or Base64 encoding, to prevent directory collisions and ensure data isolation. This is necessary to address the security concern and prevent confidential data from being leaked between projects.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#batch processing#GPU compatibility#latency issue#model loading

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING