Indexing could not be completed

[developer-final]

Version

codebase-memory-mcp 0.10.8

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Indexing could not be completed.

Step 1: Download zip OpenClaw
https://github.com/openclaw/openclaw/archive/refs/heads/main.zip

Step 2: Index

codebase-memory-mcp cli index_repository --repo-path "C:/Users/xxx/Desktop/Working/openclaw"
Preparing one-shot local CBM command...
level=warn msg=mem.allocator.preloading_completed still_preloading=false detail=allocator_was_still_preloading,_so_arena_creation_and_purging_were_disabled;_process_init_completed_explicitly
level=info msg=mem.allocator.owned classes=all
level=info msg=mem.init budget_mb=4079 total_ram_mb=16319 source=ram_fraction
Running index_repository locally...
^C

This process could not be completed and caused an out-of-memory error, leading to the unexpected and abrupt termination of other programs.

Reproduction

https://github.com/openclaw/openclaw

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.

[a380467214-art]

I hit the same Pipeline failed on 0.10.8 / Windows x64 and managed to isolate two independent root causes. Posting in case it helps isolating yours.

RC1 — a reserved device-name file anywhere in the tree crashes the indexer.

My repo root contained a file literally named nul (a stray 92-byte file produced by a botched tasklist ... > nul redirect under Git Bash; untracked in git). The indexer crashes before extraction with:

ValueError: path is on mount '\\.\nul', start on mount 'C:'

Cause: on Windows a nul path resolves to the device path \\.\nul, so any mount/relpath-style check on it throws. Note this is not coverable by .gitignore/.cbmignore — the file is skipped by neither (mine was untracked and still crashed the pipeline).

Strong tell for this class of bug: copying the exact same code tree to a different directory makes indexing succeed, which is what pointed me here.

RC2 — real indexable-file count, not repo size, decides whether the worker OOMs.

Same repo, indexable files (after gitignore), before vs after an .cbmignore:

	indexable files	extract memory peak	result
before	12,573	11.3 GB (budget 8.2 GB)	Pipeline failed
after	~1,800	fits	indexed, 20,629 nodes / 58,189 edges

Worker log for the failing run:

parallel.extract.mem rss_mb=10754 peak_mb=11339 budget_mb=8176
parallel.extract.done nodes=847649 errors=8
pass.timing pass=parallel_extract elapsed_ms=46750
parallel.registry.done files=8109 entries=827414

The bulk was non-source: an unpacked 3rd-party app (5,583 .js), tmp/ (3,317), a docs dir (893). Adding a .cbmignore for those dropped the pipeline into the normal range. Suggestion: the error hint could report candidate/parsed file counts and the memory budget instead of only Check repo_path exists and contains source files — right now both failure modes above are indistinguishable from a typo'd path.

Adjacent finding (may be a different bug): index_repository over MCP has a hard 60s envelope.

On this repo the MCP call returns Request timed out at exactly 60s and the supervisor then kills the forked worker:

warn  mcp.request method=tools/call tool=index_repository status=error duration_ms=60009
info  index.supervisor.reap outcome=killed exit_code=-1
error index.supervisor.containment_failed outcome=killed

So any repo that needs >60s must be indexed via cli (which worked fine for me). If intentional, it may be worth documenting; if not, either raising the envelope or making the MCP tool async would help.