Repository navigation
[Bug] v0.9.0 regression: CJK repo_path still crashes despite #636 fix #973
Description
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.pyfiles (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-levelrepo_pathecho 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說明書.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 real index_repository on a CJK directory and asserts outcome=clean (end-to-end, real subprocess spawn) would catch this whole class.
Related
- Windows: tree-sitter definitions pass fails on ALL files when repo_path contains non-ASCII (CJK / Cyrillic / Arabic / accented Latin / etc.) characters #636 (closed — prior fix via fix(windows): use _wfopen for non-ASCII project paths #703/test(windows): add red regressions for platform-specific failures #639; this reopens the underlying problem for v0.9.0)
- Project name strips non-ASCII (CJK) characters from path, resulting in truncated/unrecognizable names #571 (project-name truncation for CJK paths)
Activity
SauronSkywalker commentedon Jul 9, 2026
I encountered the same problem, which is quite troublesome for Chinese users
包含中文内容经常遇到，难顶
DeusData commentedon Jul 9, 2026
Thanks for the detailed repro and for adding the continuity note on #636. I am treating this as a high-priority 0.9.1-rc regression because the shipped 0.9.0 path handling still fails for CJK repo paths on Windows. The key area to verify is the supervisor to worker root-path argv handoff, plus a shipped-binary style regression guard rather than only a unit-level path conversion check.
DeusData commentedon Jul 9, 2026
Thanks — this is an exemplary report, and the junction/
--args-fileisolation matrix saves us real time. Confirmed as a high-priority v0.9.0 regression; here's where a first code audit landed:What checks out clean (so far):
CreateProcessW, and the worker rebuilds argv viaGetCommandLineW/CommandLineToArgvW→ UTF-8. NoCreateProcessAon that path.?琿?皜祈岫is (we believe) UTF-8 bytes displayed through the console's Big5/ANSI codepage — a display artifact, not proof of internal narrowing. So the corruption point your matrix demonstrates is likely elsewhere than the argv bytes themselves.What does NOT check out: the repo-path canonicalization step runs
_access()+_fullpath()— both ANSI CRT functions — on the UTF-8 path, on both the supervisor and worker side. On a non-UTF-8 ACP those misinterpret every CJK path. That's our lead suspect, but we won't guess further: your proposed guard is exactly what we'll build — a Windows CI test that shells out to the real supervisedindex_repositoryon a CJK-named directory and assertsoutcome=clean, end-to-end with the real subprocess spawn. It should go RED on current main and pin the exact failing site (the in-process #639 guard structurally couldn't).One accelerator, if you have a minute: on a failed run v0.9.0 retains the worker's own log at
<cache_dir>/logs/.worker-<pid>.log(the path is also echoed in the supervisor's warn lineindex.supervisor.worker_failed ... log=...). The last ~20 lines of that file would tell us the worker's exact exit reason (arg-parse failure vs. discover failure vs. crash) and likely shortcut the whole hunt. No pressure — the CI guard will get us there regardless; we own the next step here.fix(win): wide-path canonicalization — drop ANSI _access/_fullpath (D…
fix(writer): open the graph DB wide-safe for non-ASCII cache paths
fix(writer): open the graph DB wide-safe for non-ASCII cache paths