Repository navigation
Pipeline fails during 'dump' phase if UserProfile path contains non-ASCII characters #996
Description
Version
codebase-memory-mcp --0.9.0
Platform
Windows (x64)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
Describe the bug
When running index_repository on Windows, the pipeline consistently fails during the dump phase. This happens because my Windows user profile path contains non-ASCII characters (for example: C:\Users\Kovács János).
The SQLite/storage engine seems to fail when attempting to write the graph.db artifact to ~/.codebase-memory due to character encoding issues with accented letters in the path.
Expected behavior
The server should properly handle UTF-8/non-ASCII characters in Windows file paths when resolving the cache or storage directories.
Reproduction
-
Use a Windows machine where the
USERPROFILEpath contains non-ASCII characters (e.g.C:\Users\Kovács János). -
Install the MCP server using the official PowerShell installer.
-
Run the
index_repositoryMCP tool on any project. -
The extraction and resolution phases complete successfully.
-
It crashes exactly at the end with
level=error msg=pipeline.err phase=dump. -
The code being indexed:
This is not related to the codebase itself. Any standard project (e.g. an empty Laravel or Node.js project) will trigger this if the WindowsUSERPROFILEpath contains non-ASCII characters (e.g.C:\Users\Kovács János). -
The exact command or MCP tool call:
Via MCP tool call (index_repository):
{
"repo_path": "c:\\xampp\\htdocs\\myproject",
"mode": "fast"
}
### Logs
```text
level=error msg=pipeline.err phase=dump
{"project":"C-xampp-htdocs-myproject","status":"error","hint":"Pipeline failed. Check repo_path exists and contains source files. Try mode='fast' for a quicker diagnostic run."}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.
Activity
DeusData commentedon Jul 10, 2026
Thanks for reporting this. I have triaged it into 0.9.1-rc as a high-priority Windows/non-ASCII path stability issue. It looks related to the broader non-ASCII path class, but I am keeping this issue separate until the exact failing path is confirmed. If you have the full stderr or pipeline dump failure line, that would help us verify the fix against the right layer.
fix(platform): read environment variables wide on Windows
DeusData commentedon Jul 12, 2026
Fixed on main by d9adfeb + faf5160 (merged in 8f3ee08, PR #1058), shipping in v0.9.1 — and it took two layers, which the new Windows guard proved empirically:
cbm_writer_open) used a raw ANSI-code-pagefopen— the one file-creating call on the dump chain without UTF-8→wide conversion (the hand-rolled SQLite writer bypasses SQLite's own filename handling). That alone produced your exactpipeline.err phase=dump: extract/resolve fine,mkdir(already wide) fine, thengraph.dbcreation fails under the profile-derived cache dir._environholds ANSI-code-page bytes, a non-ASCIIUSERPROFILE(orCBM_CACHE_DIR) arrives mojibake'd or with unrepresentable characters replaced by?, which is invalid in Windows paths, so every downstream wide-safe file API fails no matter how correct it is.cbm_safe_getenvnow reads values viaGetEnvironmentVariableWand converts to genuine UTF-8.The regression guard (
test_non_ascii_cache_dump.py) indexes into a mixed Latin-1/Greek/CJK cache dir and requires a real query readback from the reopened DB — it now runs green on the Windows CI leg, which is as close to yourC:\Users\Kovács Jánossetup as CI gets. A retest on v0.9.1 with your actual profile would still be welcome confirmation.fix(writer): open the graph DB wide-safe for non-ASCII cache paths
fix(review): keep vendored scanners byte-identical; wide-safe XML sniff
fix(writer): open the graph DB wide-safe for non-ASCII cache paths
fix(platform): read environment variables wide on Windows
fix(review): keep vendored scanners byte-identical; wide-safe XML sniff