Environment
Summary
With current main, indexing a repository whose path contains non-ASCII (CJK) characters now works:
index_repository spawns workers cleanly, symbols (Class/Method/Function) are fully extracted, and
the project name encodes non-ASCII bytes as UTF-8 hex.
However, the tools that re-read files from disk at query time still fail for such projects:
| Tool |
Result on CJK-path project |
Result on same repo via ASCII junction |
index_repository (full) |
✅ nodes/edges identical to junction |
✅ |
search_graph / query_graph |
✅ symbols, signatures, complexity all present |
✅ |
get_code_snippet |
⚠️ metadata OK (start/end line, signature), but "source": "(source not available)" |
✅ full source returned |
search_code |
❌ 0 matches for any pattern |
✅ matches returned |
So extraction-time file reads work, but the query-time read path (snippet source load, grep) apparently
still goes through a narrow-char API and fails on CJK paths.
Repro
mkdir C:\tmp\repro-日本語
@'
def multiply(a, b):
return a * b
class Calculator:
def square(self, x):
return multiply(x, x)
'@ | Set-Content C:\tmp\repro-日本語\util.py -Encoding utf8
codebase-memory-mcp cli index_repository --repo-path "C:/tmp/repro-日本語" --mode fast
# -> status:"indexed", project "C-tmp-repro-e697a5e69cace8aa9e", symbols present:
codebase-memory-mcp cli query_graph --args-file <(echo '{"query":"MATCH (c:Class) RETURN c.name","project":"C-tmp-repro-e697a5e69cace8aa9e"}')
# -> Calculator ... (extraction works)
codebase-memory-mcp cli get_code_snippet --qualified-name Calculator --project C-tmp-repro-e697a5e69cace8aa9e
# -> "source": "(source not available)" <-- BUG (line range + signature are correct)
codebase-memory-mcp cli search_code --pattern multiply --project C-tmp-repro-e697a5e69cace8aa9e
# -> 0 matches <-- BUG
Create an ASCII junction to the same directory (New-Item -ItemType Junction), index via the junction
path: both get_code_snippet source and search_code work, on identical file content.
Verified on a real C# repo as well (56 classes / 280 methods extracted from the CJK path — identical
counts to the junction index — yet snippet source and search_code only work on the junction project).
Expected
get_code_snippet returns the source text and search_code returns matches for projects indexed
under non-ASCII paths, same as for ASCII paths.
Notes / suspected cause
Workaround
Index through an ASCII junction/symlink to the repo; all tools work via the aliased path.
Environment
main-zip-2026-07-06(includes the fix(win): escape spawned command-line args so the index worker gets valid argv #881 worker-spawn quoting fix and the earlier_wfopen/ wide-argv fixes fix: use _wfopen on Windows to support non-ASCII (CJK/U...) file paths #637 / fix(windows): use _wfopen for non-ASCII project paths #703 / fix(win): deliver non-ASCII CLI paths end-to-end (wide argv + CreateProcessW) #891)Summary
With current main, indexing a repository whose path contains non-ASCII (CJK) characters now works:
index_repositoryspawns workers cleanly, symbols (Class/Method/Function) are fully extracted, andthe project name encodes non-ASCII bytes as UTF-8 hex.
However, the tools that re-read files from disk at query time still fail for such projects:
index_repository(full)search_graph/query_graphget_code_snippet"source": "(source not available)"search_codeSo extraction-time file reads work, but the query-time read path (snippet source load, grep) apparently
still goes through a narrow-char API and fails on CJK paths.
Repro
Create an ASCII junction to the same directory (
New-Item -ItemType Junction), index via the junctionpath: both
get_code_snippetsource andsearch_codework, on identical file content.Verified on a real C# repo as well (56 classes / 280 methods extracted from the CJK path — identical
counts to the junction index — yet snippet source and search_code only work on the junction project).
Expected
get_code_snippetreturns the source text andsearch_codereturns matches for projects indexedunder non-ASCII paths, same as for ASCII paths.
Notes / suspected cause
file_pathon nodes is absolute and contains the CJK segment(e.g.
C:/Users/.../プロジェクト/.../Foo.cs), and line ranges are correct — only the file-contentread fails. Looks like one or more remaining
fopen/narrow-path call sites on the query-time path(snippet source loader, search_code grep), i.e. the same class of problem previously fixed for other
call sites in fix: use _wfopen on Windows to support non-ASCII (CJK/U...) file paths #637 / fix(windows): use _wfopen for non-ASCII project paths #703 / fix(win): deliver non-ASCII CLI paths end-to-end (wide argv + CreateProcessW) #891. On this machine the ANSI code page is 932, so any
UTF-8 → ANSI narrow conversion of the path cannot round-trip.
search_code returns 0 matches for all patterns on macOS arm64 v0.8.1 (graph index healthy) #670 (search_code 0 matches, macOS arm64).
Workaround
Index through an ASCII junction/symlink to the repo; all tools work via the aliased path.