Skip to content

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

Closed as not planned

Description

@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.

Activity

  1. added
    windowsWindows-specific issues
    parsing/qualityGraph extraction bugs, false positives, missing edges
    duplicateThis issue or pull request already exists
    on Jun 29, 2026
  2. github-actions commented on Jun 29, 2026

    @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.

  3. DeusData commented on Jun 29, 2026

    @DeusData
    Owner

    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.

  4. ShauryaaSharma commented on Jun 29, 2026

    @ShauryaaSharma
    Contributor

    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.

  5. added
    priority/backlogValuable contribution, lower scheduling urgency; review when maintainer capacity opens.
    on Jun 30, 2026
  6. DeusData commented on Jul 1, 2026

    @DeusData
    Owner

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingduplicateThis issue or pull request already existsparsing/qualityGraph extraction bugs, false positives, missing edgespriority/backlogValuable contribution, lower scheduling urgency; review when maintainer capacity opens.windowsWindows-specific issues

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions