Project name strips non-ASCII (CJK) characters from path, resulting in truncated/unrecognizable names

[XX888QM]

Bug Description

When indexing a project with a path containing non-ASCII characters (e.g. Chinese/CJK), the generated project name strips all non-ASCII characters and only retains the ASCII portions of the path.

Steps to Reproduce

1. Have a project at a path containing Chinese characters, e.g.:
   /Users/yunxin/Desktop/开发/后端/信租风控通后端
2. Run index_repository on this path
3. The generated project name becomes Users-yunxin-Desktop — all Chinese segments are silently dropped

Expected Behavior

The project name should either:

• Preserve Unicode characters as-is: Users-yunxin-Desktop-开发-后端-信租风控通后端
• Or percent-encode them: Users-yunxin-Desktop-%E5%BC%80%E5%8F%91-...
• Or allow users to provide a custom name parameter in index_repository to override the auto-generated name

Actual Behavior

All non-ASCII path segments are stripped. For the path above, the result is just Users-yunxin-Desktop, losing all meaningful project identification.

Impact

• Duplicate entries in the UI when the same project is indexed via both its real path and a symlink with an ASCII name
• Project names are meaningless for users with non-ASCII (Chinese, Japanese, Korean, etc.) directory structures
• No way to distinguish between multiple projects under the same ASCII-only parent path

Environment

• codebase-memory-mcp v0.8.1
• macOS (Apple Silicon)
• Project path with Chinese characters

[DeusData]

Confirmed bug — the project-name slug shouldn't be dropping non-ASCII path segments; for a path like yours that erases all meaningful identification and collides with a symlinked ASCII path. Labeling bug / ux/behavior.

Two parts to the fix: preserve Unicode (or percent-encode) in the auto-generated slug, and — independently useful — honor an explicit name override in index_repository so users can pin a readable name. Thanks for the clear repro.

[mvanhorn]

Implemented in #624

[DeusData]

This issue now has a first-class, durable reproduction in the cumulative bug-reproduction suite landing in #667 — a test that pins the exact failing behaviour, so it's tracked and guarded against silent regression. Where #667 also lands the root-cause fix, that's called out in the PR; otherwise the reproduction makes the eventual fix straightforward and verifiable.

The reproduction goes live once #667 merges. (Posted from the release branch's QA pass.)

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

[DeusData]

v0.9.0 includes non-ASCII path and project-name support. Could you retest the CJK project-name case on v0.9.0 and confirm whether the project identity is now preserved correctly? Marking awaiting-reporter.

[github-actions]

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will be closed in 14 days if there's no update — just add a comment to keep it open. We're happy to pick it back up the moment we can reproduce it.