Bug: File parsing fails silently on Windows when project path contains accented/non-ASCII characters

[CesarBecVal]

Version

0.8.1

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

When codebase-memory-mcp indexes a repository on Windows, if the absolute path to the repository contains accented characters (e.g., C:\Users...\Proyectos De César...), the indexer correctly identifies and creates File nodes for all files in the project, but fails silently to extract any functions, classes, or AST-based nodes via tree-sitter.

The files appear in the graph (e.g. searching for label: File returns them), but searching for label: Function returns 0 results because the internal file reading/parsing phase fails.

codebase-memory-mcp should be able to open and parse the contents of files even if their absolute paths contain non-ASCII characters on Windows.

The files are registered in the index as File nodes (likely via directory traversal), but their contents are never successfully parsed by tree-sitter, leaving the knowledge graph completely devoid of semantic structural nodes (Functions, Classes, Methods, etc.) without throwing an explicit fatal error during indexing.

Because codebase-memory-mcp is a static C binary, this is likely an encoding issue with how Windows standard I/O handles file paths. Standard functions like fopen on Windows expect ANSI paths by default unless the program explicitly uses wide-character APIs (e.g., _wfopen) or the UTF-8 code page is enforced. When the C backend attempts to open the file using its UTF-8 path string, Windows fails to find the file, causing the parser to silently skip it.

Reproduction

1.- On a Windows machine, create a directory with an accented character, e.g., mkdir C:\test-césar
2.- Create a dummy Python file inside it: echo "def hello(): pass" > C:\test-césar\main.py
3.- Run the indexer on this path via the MCP tool or CLI.
4.- Query the graph for files: MATCH (n:File) RETURN n (Returns the main.py file).
5.- Query the graph for functions: MATCH (n:Function) RETURN n (Returns 0 results).
6.- Repeat the steps in a path without accents (e.g., C:\test-cesar), and the function hello is correctly extracted.

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

261 nodes / 249 edges / 232 files

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.

[github-actions]

Thanks for raising this! It looks like a duplicate of an existing issue — the canonical one is linked above. Continuing the discussion there keeps everything in one place. We leave this open for visibility; a maintainer will close it once it's fully covered.

[DeusData]

Thanks for the focused accented-path repro. I’ve triaged this as the same Windows non-ASCII path extraction class tracked in #636 and marked it as a duplicate/evidence case rather than a separate root cause. The important detail here is useful: discovery creates File nodes, but the later file-open/tree-sitter phase fails, so the fix should cover wide-character file reads (_wfopen/wide Win32 APIs or equivalent) and add a regression for an accented Latin path such as C:\test-césar.

[ShauryaaSharma]

I've put up a fix here (PR): #703

Added cbm_fopen(path, mode) to compat_fs, on Windows it converts the UTF-8 path to UTF-16LE via the existing cbm_utf8_to_wide helper and calls _wfopen, on POSIX it's a plain fopen passthrough. Replaced all 18 fopen call sites in the pipeline and discover layers that receive user project file paths.

[DeusData]

Closing as a strict duplicate/evidence case of #636.

#636 is the canonical, best-described report for Windows non-ASCII repo paths causing source-file opens/tree-sitter parsing to fail while discovery still creates File nodes. This issue is the accented-Latin reproduction of the same root cause class, so I am keeping the investigation and fix status on #636. Related implementation PRs are #637 and #703.