Windows-Indexing worker crashed on a file

[wgy000]

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?

I am running codebase-memory-mcp on Windows 10 (version 10.0.26200.8875) with the latest version (v0.9.0). The command codebase-memory-mcp cli index_repository always fails with the error index.worker_failed and the hint:
"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file."

However, the worker log file mentioned (.worker-*.log) is completely empty (0 KB), so I cannot identify which file caused the crash.

I have tried the following without success:

Running the command as Administrator (my account is in the Administrators group and UAC is disabled).

Giving Everyone full control to the repository folder.

Using different path formats.

Testing on another small repository – the same error occurs.

My repository is very small (only about 30+ MB total size). The issue is reproducible 100% of the time.

Reproduction

D:\home\adop-main>codebase-memory-mcp cli index_repository
level=info msg=mem.init budget_mb=4041 total_ram_mb=16167
level=info msg=index.supervisor.reap outcome=exit_nonzero exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=exit_nonzero exit_code=1 log=C:/Users/wgyworkbook/.cache/codebase-memory-mcp/logs/.worker-14220.log
level=info msg=index.supervisor.reap outcome=exit_nonzero exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=exit_nonzero exit_code=1 log=C:/Users/wgyworkbook/.cache/codebase-memory-mcp/logs/.worker-14220.log
{"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file."}

Logs

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.

[DeusData]

Thanks for the concrete Windows reproduction. This is now a high-priority 0.9.1-rc stability issue under #390. It is not being collapsed into #1132: the zero-byte worker log overlaps that incident, but a deterministic exit-code-1 failure across multiple small repositories is a separate failure mode. The RED case should use a bounded synthetic Windows repository and preserve the worker’s actual failure reason before any retry or fallback.