Windows-Indexing worker crashed on a file

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.

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.

Possible false-positive source for this signature, worth ruling out before hunting for a culprit file.

On Windows 11 (v0.9.0) I reproduced the exact symptoms of this report — index.supervisor.worker_failed, exit_code=1, signal=0, and a 0-byte worker log — and the root cause turned out to be an invalid argument, not a file the parser choked on.

I was calling index_repository with {"path": "..."} instead of {"repo_path": "..."}. The parent process accepts the call, spawns the worker, and the worker exits immediately. Because it dies before emitting any log line, the log file is created and stays empty, and the user-facing hint says the worker "crashed on a file".

Running the worker command by hand surfaces the real error instantly:

codebase-memory-mcp cli --index-worker index_repository '{"path":"..."}' --response-out out.json
-> repo_path is required

With the correct key it indexes cleanly: a 264-file Python repo in 6.6s, outcome=clean exit_code=0.

Two suggestions:

Validate required args in the parent, before spawning. A missing repo_path should return a validation error, not a spawned worker that dies silently.
Soften the hint. "Indexing worker crashed on a file" asserts a cause the supervisor cannot know. When the log is 0 bytes, nothing was parsed, so the failure is at or before worker startup. Something like "worker exited before producing output — check arguments" would have saved me several hours.

This may or may not be what the original reporter hit — I can't tell without their exact arguments. But given the identical signature, it seems worth confirming first.

Possible false-positive source for this signature, worth ruling out before hunting for a culprit file.

On Windows 11 (v0.9.0) I reproduced the exact symptoms of this report — index.supervisor.worker_failed, exit_code=1, signal=0, and a 0-byte worker log — and the root cause turned out to be an invalid argument, not a file the parser choked on.

I was calling index_repository with {"path": "..."} instead of {"repo_path": "..."}. The parent process accepts the call, spawns the worker, and the worker exits immediately. Because it dies before emitting any log line, the log file is created and stays empty, and the user-facing hint says the worker "crashed on a file".

Running the worker command by hand surfaces the real error instantly:

codebase-memory-mcp cli --index-worker index_repository '{"path":"..."}' --response-out out.json
-> repo_path is required

With the correct key it indexes cleanly: a 264-file Python repo in 6.6s, outcome=clean exit_code=0.

Two suggestions:

Validate required args in the parent, before spawning. A missing repo_path should return a validation error, not a spawned worker that dies silently.
Soften the hint. "Indexing worker crashed on a file" asserts a cause the supervisor cannot know. When the log is 0 bytes, nothing was parsed, so the failure is at or before worker startup. Something like "worker exited before producing output — check arguments" would have saved me several hours.

This may or may not be what the original reporter hit — I can't tell without their exact arguments. But given the identical signature, it seems worth confirming first.

@wgy000

Thanks for isolating the missing repo_path failure mode. That exact parent-validation and misleading-diagnostic bug is now tracked separately in #1211. It does not yet prove that the original report had the same cause. @wgy000, please share the exact index_repository argument object or command used for one failing run, with the repository path redacted if necessary. I set awaiting-reporter for that invocation so we can distinguish an argument-validation failure from a genuine worker crash.

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

the codebase-memory-mcp --version you're on
the exact steps or command you ran
a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

@DeusData

Please take a look at the attached screenshot. It shows the results of my tests using
"codebase-memory-mcp cli index_repository --repo-path "D:\home\adop-auto",
codebase-memory-mcp cli index_repository,
and codebase-memory-mcp cli index_repository --repo-path "D://home//adop-auto" "respectively. "D:\home\adop-auto" is the path to my project directory, yet the worker.log file remains completely empty with no content whatsoever. @DeusData

Thanks for returning with the exact commands and screenshot. The invocation with --repo-path D:\\home\\adop-auto is sufficient to move this back to maintainer action, and I removed awaiting-reporter. The empty worker log remains important: it means this path is not giving us the file-level evidence needed to distinguish the crash from #1211, even when the argument is present. No further reporter action is needed right now.

@SOTO729

Thanks @SOTO729 for the independent Windows reproduction and the content-independent two-file fixture.

This strengthens the worker-launch diagnosis: the process dies before the log handle produces a byte across cmd.exe and MSYS, with no Defender event and no dependence on repository size or language mix. That separates it from parser crashes and from the file-specific quarantine path.

The issue remains priority/high in 0.9.1-rc. PR #1207 is the queued candidate for the Windows worker-log handle boundary, but triage is not pre-approving it; review must bind it to this zero-byte pre-index failure on real Windows. Thank you for offering a diagnostic run.

Just tried v0.9.1-rc.1 and it's still producing empty logs with the Indexing worker crashed on a file. error.

Another Windows 0.9.0 reproduction, with one data point I don't see covered yet in this thread: the failure is not specific to the CLI entry point — it reproduces over the MCP JSON-RPC transport as well.

Every report above invokes codebase-memory-mcp cli index_repository. I drove the actual protocol over stdio instead:

-> {"jsonrpc":"2.0","id":1,"method":"initialize", ...}
<- {"jsonrpc":"2.0","id":1,"result":{"serverInfo":{"name":"codebase-memory-mcp","version":"0.9.0"}, ...}}

-> {"jsonrpc":"2.0","id":2,"method":"tools/call",
    "params":{"name":"index_repository","arguments":{"path":"<project root>"}}}
<- {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":
     "{\"status\":\"error\",\"outcome\":\"exit_nonzero\",\"hint\":\"Indexing worker crashed on a file...\"}"}],
    "isError":true}}

Identical exit_nonzero, identical 0-byte worker log. So cli is not a separate broken path — it and the MCP tool call both funnel into the same supervisor/worker boundary, which I think supports the worker-launch diagnosis rather than anything in argument parsing or the CLI shim.

Supervisor stderr for the failing call:

level=info msg=index.worker.fast_exit         action=_Exit
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=...\logs\.worker-24436.log

Environment: Windows 11 Pro 10.0.26200 (x64), codebase-memory-mcp 0.9.0, npm install channel, standard variant.

Consistent with the reports above: reproduces on a two-line a.py in an otherwise empty directory, and on a real repository; all five .worker-*.log files in the cache dir are 0 bytes. The server itself is healthy throughout — initialize, list_projects, search_code, detect_changes and config list all answer correctly, and queries against a previously-built graph still work. It is specifically the worker that dies before producing a byte.

Happy to run a diagnostic build against the MCP path if that's a useful variable to have covered.

Reproduced independently on Windows 11 x64, build 10.0.26200 — the same build family as the original report — with codebase-memory-mcp 0.9.0, standard variant.

Adding what I was able to rule out, since it narrows the surface a fair bit.

Minimal reproduction. A two-file repository is enough:

C:\tmp\p\package.json
C:\tmp\p\src\a.js     (one exported function)
C:\tmp\p\src\b.js     (imports a.js, one exported function)

codebase-memory-mcp cli index_repository {"path":"C:/tmp/p","incremental":false}
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=...\logs\.worker-47240.log
{"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file..."}

Deterministic, every run.

Ruled out, each by test rather than inspection:

Path length / MAX_PATH (index_repository: deterministic contained worker crash (0-byte log) when cache dir + derived project name exceed Windows MAX_PATH #1450) — C:\tmp\p is about as short as a Windows path gets, and the derived project name is correspondingly short. Still crashes.
Spaces or non-ASCII in the path — the failing path above has neither. A longer path with spaces fails identically.
A specific source file — bisected down a real repository to a four-file directory, which still crashes. The two-file repo above shares no files with it.
Corrupt vector store — deleted the project via delete_project, moved lancedb/ and .codebase-memory/ aside, indexed from scratch. Unchanged. The lancedb/ directory left behind held only a manifest named 18446744073709551614.manifest (2^64-2) and no data, which may be a separate symptom worth a look.
Stale or damaged binary — ran update -y, which reinstalled 0.9.0. v0.9.0 is the latest release, so there is no newer build to move to.

On the missing log. In my case .worker-<pid>.log is not merely empty — it is never created. The path in the warning does not exist afterwards, so there is nothing to attach.

Two smaller things noticed while updating, both on Windows:

update -y stops at an interactive prompt asking for the binary variant (Which binary variant do you want? 1) standard 2) ui) and exits with error: failed to read input. With -y given, that prompt is unexpected; it also means the update cannot complete unattended. Piping 1 works around it.
That failure happened after the updater had already deleted every existing project index. An interrupted update therefore leaves the caches gone and the binary unchanged.

Happy to run any instrumented build or set any env var that would produce a usable log.

@wgy000

@wgy000 — you came back with the exact commands and a screenshot when we asked, the awaiting-reporter label came off then, and nothing has been waiting on you since. Sorry that the wait has been on our side instead.

Between your runs, @jennifertq isolating the missing-repo_path false positive, @SOTO729's content-independent two-file fixture reproducing across cmd.exe and MSYS with no Defender event, and @MrLyric showing the same failure over the MCP transport rather than just the CLI, this is well characterised: the worker dies before its log handle produces a single byte, so the hint claiming it "crashed on a file" is asserting something the supervisor cannot possibly know.

What I cannot say is that it is root-caused, because it is not. Tonight's v0.10.5 is being prepared for the issues that make cbm impossible to operate, and "indexing fails every time and tells you nothing" is squarely one of them. Thank you all for the persistence — several of you have tested this more thoroughly than a bug report requires.

fix(index): make a crashed worker's log survive and name the run

@wgy000

Thank you, @wgy000, and everyone who narrowed this down! The two-file fixture, the cmd/MSYS and MCP-transport checks, and the missing-repo_path false positive (now #1211) all helped.

Since v0.10.5, the worker's log is durable and begins with a header written before anything else, so a worker that dies at startup now leaves a readable reason instead of 0 bytes. A Windows fix for the private cache directory's permissions also landed in v0.10.3 and may be the actual cause. Could one of you run the two-file repro on v0.11.0 and share either "works" or the contents of the worker log it names?

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

the codebase-memory-mcp --version you're on
the exact steps or command you ran
a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.

Thank you to everyone who isolated the two-file failure across CLI and MCP. Following the diagnostic changes reported above, the remaining check is that same small fixture on v0.11.0 or newer, with either success or the named worker log if it fails. The original commands and repository-size controls are already sufficient.

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.

Navigation Menu

Repository navigation

Windows-Indexing worker crashed on a file #1145

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

1 remaining item

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Windows-Indexing worker crashed on a file #1145

Description

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Activity

DeusData commented on Jul 18, 2026

jennifertq commented on Jul 21, 2026

jennifertq commented on Jul 21, 2026

DeusData commented on Jul 22, 2026

github-actions commented on Jul 22, 2026

wgy000 commented on Jul 24, 2026

DeusData commented on Jul 24, 2026

1 remaining item

DeusData commented on Jul 28, 2026

towfiqi commented on Aug 2, 2026

MrLyric commented on Aug 2, 2026

wamedo-netizen commented on Aug 6, 2026

DeusData commented on Aug 14, 2026

DeusData commented on Sep 26, 2026

github-actions commented on Sep 26, 2026

github-actions commented on Oct 19, 2026

DeusData commented on Oct 19, 2026

github-actions commented on Nov 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions