Non-ASCII (e.g. Chinese) directory paths produce an irreversible hex-encoded, non-discoverable project identifier

[greendotzf]

Version

v0.10.8

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Summary
Indexing a repository whose path contains non-ASCII characters (Chinese, etc.) succeeds, and root_path correctly preserves the original Chinese path. However, the generated project identifier hex-encodes the non-ASCII bytes of the path, producing an unreadable, non-derivable name. Every downstream tool (search_graph, trace_path, get_architecture, …) requires the exact project string, so users who reference the repo by its real (Chinese) path/name get project not found.

Steps to reproduce

bash
mkdir 中文测试仓库
printf "function greet(){return 'hi';}\n" > 中文测试仓库/hello.js

codebase-memory-mcp.exe cli index_repository --json '{"repo_path":"C:/tmp/中文测试仓库"}'
codebase-memory-mcp.exe cli list_projects '{}'

project name shows as: ...-e4b8ade69687e6b58be8af95e4bb93e5ba93

(e4b8ad=中, e69687=文, e6b58b=测, e8af95=试, e4bb93=仓, e5ba93=库)

codebase-memory-mcp.exe cli search_graph --project "C:/tmp/中文测试仓库" --query greet

-> {"error":"project not found or not indexed", ...}

codebase-memory-mcp.exe cli search_graph --project "...-e4b8ade69687e6b58be8af95e4bb93e5ba93" --query greet

-> works (returns the greet function)

Expected behavior

Either the project identifier preserves the human-readable path (e.g. C-tmp-中文测试仓库), or
a reversible/normalized scheme is used so users can derive the project name from the path, or
list_projects output makes the mapping root_path ↔ project obvious (it already returns root_path correctly, but the name is still garbage).
Actual behavior

list_projects returns name: "...-e4b8ade69687e6b58be8af95e4bb93e5ba93" with root_path: "C:/tmp/中文测试仓库" — name is not derivable from the path.
Referencing the project by its real Chinese path → project not found.
Only the hex string works, which no user can guess.
Root cause hypothesis
The project-name normalizer replaces each byte > 0x7F with its 2-digit hex (%02x) instead of preserving UTF-8 runes. On Windows, filesystem paths are UTF-16 and the C runtime receives argv as UTF-8; the normalizer should keep multi-byte UTF-8 sequences intact (or use a Punycode-like reversible encoding) rather than byte-wise hexing. Note root_path storage is correct, so path I/O itself works — only the identifier derivation is broken.

Impact

Any repo under a non-ASCII path (common for Chinese/Japanese/Korean users) becomes unreferenceable by its real name.
project not found errors that look like "indexing failed" but actually indexing succeeded.
Hard to automate (scripts can't derive the hex name without replicating the encoder).
Workaround (current)

Use only ASCII paths for repos you intend to query, or
after indexing, run list_projects and copy the exact (hex) project name for downstream calls.
Suggested fix
Normalize the project identifier using the full UTF-8 string (or a deterministic reversible transform of the UTF-8 bytes), and/or accept a user-supplied --project so the identifier is stable and human-readable regardless of path encoding.

Reproduction

1. Create a repo under a non-ASCII (Chinese) path:
   mkdir 中文测试仓库
   printf "function greet(){return 'hi';}\n" > 中文测试仓库/hello.js

2. Index it:
   codebase-memory-mcp.exe cli index_repository --json '{"repo_path":"C:/tmp/中文测试仓库"}'

3. List projects:
   codebase-memory-mcp.exe cli list_projects '{}'
   -> project name shows as "...-e4b8ade69687e6b58be8af95e4bb93e5ba93"
   (e4b8ad=中, e69687=文, e6b58b=测, e8af95=试, e4bb93=仓, e5ba93=库)

4. Query by the real Chinese path:
   codebase-memory-mcp.exe cli search_graph --project "C:/tmp/中文测试仓库" --query greet
   -> {"error":"project not found or not indexed", ...}

5. Query by the hex name instead:
   codebase-memory-mcp.exe cli search_graph --project "...-e4b8ade69687e6b58be8af95e4bb93e5ba93" --query greet
   -> works, returns the greet function

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.