Summary
v0.9.0 still crashes on non-ASCII (CJK) repo_path, despite #636 being marked fixed — this is a regression / incomplete fix. v0.9.0's release notes explicitly claim end-to-end non-ASCII path support incl. "wide-argv + CreateProcessW, escaped/NUL-terminated worker command lines", and #639 added a Windows CI regression guard — yet the crash is back in the shipped release.
Filing a fresh (open) issue because #636 is closed; the same details are also added there for continuity: #636 (comment).
Environment
codebase-memory-mcp 0.9.0, standard build (GitHub release archive), Windows 11 (build 26200) x64
Repro
- Create a dir with a CJK name, e.g.
C:\test\雷達測試\, with 2–3 .py files (ASCII filenames, UTF-8 content).
codebase-memory-mcp cli index_repository --repo-path "C:\test\雷達測試" --mode fast- →
exit 1, {"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file..."}. stderr echoes the path mojibaked: 雷達測試 → ?琿?皜祈岫.
Isolation (points at the supervisor→worker root-path argv handoff)
- Same files under an ASCII path → clean (
outcome=clean, 100 nodes / 371 edges).
- CJK file content (UTF-8 comments) → fine.
- Passing the path via
--args-file (UTF-8 JSON) makes the top-level repo_path echo correctly, but the worker still crashes → the supervisor→worker handoff re-passes the root path via (ANSI) argv and re-mojibakes it.
- Working workaround: an ASCII-named junction pointing at the CJK dir indexes cleanly (
outcome=clean, even a CJK-named file 說明書.md inside). So file enumeration (wide-char API) is fine — only the root-path argv handoff to the worker is broken.
Why this keeps regressing (CI gap)
This is the dangerous kind of regression: "marked fixed + CI green", so each release looks fixed while non-ASCII Windows users still cannot index their real directories — "just update" doesn't help because the update itself still ships the crash.
Most likely gap: tests/windows/test_non_ascii_path.py (added in #639) probably exercises the pipeline in-process and never actually spawns the real worker subprocess with a CJK root path, so it structurally cannot catch the argv handoff that breaks in production. A guard that shells out to the real index_repository on a CJK directory and asserts outcome=clean (end-to-end, real subprocess spawn) would catch this whole class.
Related
Summary
v0.9.0 still crashes on non-ASCII (CJK)
repo_path, despite #636 being marked fixed — this is a regression / incomplete fix. v0.9.0's release notes explicitly claim end-to-end non-ASCII path support incl. "wide-argv + CreateProcessW, escaped/NUL-terminated worker command lines", and #639 added a Windows CI regression guard — yet the crash is back in the shipped release.Filing a fresh (open) issue because #636 is closed; the same details are also added there for continuity: #636 (comment).
Environment
codebase-memory-mcp 0.9.0, standard build (GitHub release archive), Windows 11 (build 26200) x64Repro
C:\test\雷達測試\, with 2–3.pyfiles (ASCII filenames, UTF-8 content).codebase-memory-mcp cli index_repository --repo-path "C:\test\雷達測試" --mode fastexit 1,{"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file..."}. stderr echoes the path mojibaked:雷達測試→?琿?皜祈岫.Isolation (points at the supervisor→worker root-path argv handoff)
outcome=clean, 100 nodes / 371 edges).--args-file(UTF-8 JSON) makes the top-levelrepo_pathecho correctly, but the worker still crashes → the supervisor→worker handoff re-passes the root path via (ANSI) argv and re-mojibakes it.outcome=clean, even a CJK-named file說明書.mdinside). So file enumeration (wide-char API) is fine — only the root-path argv handoff to the worker is broken.Why this keeps regressing (CI gap)
This is the dangerous kind of regression: "marked fixed + CI green", so each release looks fixed while non-ASCII Windows users still cannot index their real directories — "just update" doesn't help because the update itself still ships the crash.
Most likely gap:
tests/windows/test_non_ascii_path.py(added in #639) probably exercises the pipeline in-process and never actually spawns the real worker subprocess with a CJK root path, so it structurally cannot catch the argv handoff that breaks in production. A guard that shells out to the realindex_repositoryon a CJK directory and assertsoutcome=clean(end-to-end, real subprocess spawn) would catch this whole class.Related