Repository navigation
Indexing could not be completed #2184
Description
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
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.
Activity
a380467214-art commentedon Sep 12, 2026
I hit the same
Pipeline failedon 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 botchedtasklist ... > nulredirect under Git Bash; untracked in git). The indexer crashes before extraction with:Cause: on Windows a
nulpath resolves to the device path\\.\nul, so anymount/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:Pipeline failedWorker log for the failing run:
The bulk was non-source: an unpacked 3rd-party app (5,583
.js),tmp/(3,317), a docs dir (893). Adding a.cbmignorefor those dropped the pipeline into the normal range. Suggestion: the error hint could report candidate/parsed file counts and the memory budget instead of onlyCheck 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_repositoryover MCP has a hard 60s envelope.On this repo the MCP call returns
Request timed outat exactly 60s and the supervisor then kills the forked worker: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.DeusData commentedon Sep 25, 2026
Thank you @developer-final for the clear report and the public reproduction, and @a380467214-art for the detailed worker-log breakdown. The candidate/parsed-file and budget numbers are exactly what we needed.
Where things stand: v0.11.0 changed a lot here. On Windows the indexing worker now runs inside a Job Object with a hard memory cap (1.5× the budget), so it can no longer take memory from other programs the way 0.10.8 did. Extraction also spills parsed results to disk under the budget, and a run that cannot fit stops with a clear
over_memory_budgeterror and a concreteCBM_MEM_BUDGET_MBretry value instead of the generic "check repo_path" hint.We re-ran your exact case (openclaw main, budget 4079 MB) on current main. With many worker threads it indexes cleanly under the budget (about 650k nodes / 3.5M edges in ~80 s). With fewer threads we found a real remaining gap: extraction can finish just under the point where spilling kicks in, and the later resolve/semantic passes then go past the budget. On Windows that is likely to hit the new hard cap, and the error would then say "worker crashed on a file", which is misleading because it is really memory. We're fixing both: making those later passes respect the budget, and reporting the memory evidence when the cap is hit.
Could you help us confirm on your machine?
CBM_MEM_BUDGET_MB=6000(if you have the RAM),CBM_WORKERS=a higher value, or a.cbmignorefor large non-source trees should let it complete.Thanks again, this repro is exactly the kind of real-world case that keeps the memory work honest.
DeusData commentedon Sep 28, 2026
The post-extraction budget fix is up for review in #2394. Thanks again, @developer-final and @a380467214-art!
test(parallel): rename the `near` graph buffer for MinGW
Merge pull request #2394 from DeusData/fix/issue-2184-post-extraction…
fix(pipeline): spill before the post-extraction phases when they woul…
DeusData commentedon Sep 30, 2026
Thank you again, @developer-final! #2394 is now merged to
mainas d0ec231 and covers part of this issue. We're keeping the issue open for the remaining work and will post here as it lands.DeusData commentedon Oct 19, 2026
Thank you again for the public case and worker evidence. The September 30 update recorded a partial fix in #2394, and I have no new verified result for the remaining work. Please do not repeat an uncontained OOM just to update this thread.
DeusData commentedon Oct 25, 2026
Thank you again for the public case and worker evidence. The remaining memory-budget work after the recorded partial fix still needs maintainer follow-up. Sorry for the delay; I’ll follow up soon; please do not repeat an uncontained OOM to update the thread.