Index repository failed #2088

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?

On Windows 10 (19045), index_repository fails with:

index worker ended with exit_nonzero (exit=1, signal=0); inspect log: .../logs/.worker-log-aXXXXX

The failure is probabilistic and scales with the amount of work: repositories of a few hundred files index fine, ~450 files fail most of the time, ~900 files almost never succeed, and a 16.5k-file repository failed 48 out of 48 attempts (including 40 consecutive automated retries in mode: "fast").

Every process the tool starts — daemon, CLI client, and index worker alike — logs this at startup, which looks like the root cause:

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

If arena creation really is disabled for the lifetime of the process, the worker can only ever live inside its initial arena, which would explain both the randomness and the correlation with workload size.

There are no entries in the Windows Application event log for these exits, so this is a controlled exit(1) from an internal guard, not an access violation.

Environment

Measured failure rates

Each row is repeated runs of the same target. Synthetic targets are flat directories of .cs files copied out of the same project, so content is held constant and only file count varies.

0.10.6 looked noticeably more stable than 0.10.8 in the 450-file band (3/3 vs 1/7), which suggests a regression somewhere between the two native runtimes — but 0.10.6 still cannot index the full repository.

What the logs show

The worker log ends immediately after initialization, before any pipeline stage is recorded:

{"level":"control","event":"index.worker.start","version":"0.10.8","build":"b4b403b1...","pid":"344208","repo_path":"C:/.../clients-git", ...}
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.budget.worker_cap cap_bytes=2989006899
level=info msg=mem.init budget_mb=2850 total_ram_mb=32577 source=daemon_worker_cap
warning: passing raw JSON to 'cli index_repository' is deprecated ...

That truncation appears to be log buffering rather than an early crash: on a run that succeeded, the same log contained the full pass-by-pass trace and ended with index.worker.fast_exit action=_Exit. So the buffer is flushed on the normal _Exit path but lost when the worker aborts — which is exactly the case where the log matters. Making the worker log line-flushed (or flushed on the abort path) would make this class of failure diagnosable.

Corresponding daemon-side lines:

level=warn msg=mcp.request protocol=jsonrpc method=tools/call tool=index_repository status=error duration_ms=2027
level=info msg=index.supervisor.reap outcome=killed exit_code=1 signal=0
level=warn msg=index.supervisor.worker_cancelled outcome=killed log=.../.worker-log-a93792

Ruled out

I checked these before filing, all with the same result:

• Not the MCP transport. Identical failure through Claude Code's native MCP client, through a hand-written stdio JSON-RPC driver, and through cli index_repository.
• Not the mode. full, moderate, fast behave the same.
• Not memory budget. CBM_MEM_BUDGET_MB at 512 / 2048 / 4096 / 16384 / 28000 — no effect on the outcome. One success at 4096 on the 892-file target did not reproduce (0 of 4 immediately after).
• Not thread count. CBM_WORKERS=1, CBM_WORKERS=2, CBM_INDEX_SINGLE_THREAD=1 — no effect.
• Not source retention. CBM_RETAIN_TOTAL_MB=128, CBM_RETAIN_PER_FILE_MB=4 — no effect.
• Not a timeout. CBM_INDEX_WORKER_TIMEOUT_S=3600 (set on the daemon process) — no effect.
• Not node_modules / ignored dirs. Subprojects containing no node_modules fail at the same file counts.
• Not path length or non-ASCII paths. Longest path is 115 chars; a Cyrillic-named file was indexed successfully in a passing run.
• Not folder redirection. %LOCALAPPDATA% is a real local directory on C:, not a reparse point, despite the machine being domain-joined with HOMEDRIVE=Z:.
• Not process sandboxing. Same behaviour with the calling shell's sandbox disabled.
• Not repo size in bytes alone. Trimming non-code files would only cut the set from 16,509 to 13,363, still far above the ~500-file band where failures start.

Secondary issues found along the way

1. The real error is hidden at the default log level. cli index_repository exits 1 and prints nothing; index worker ended with exit_nonzero (...) only surfaces with CBM_LOG_LEVEL=debug. That message should be printed unconditionally.

2. Worker log is lost precisely on failure. See above — buffered output is dropped when the worker aborts.

3. Deprecation warning fires when flags are used. Running cli index_repository --repo-path ... --name ... still logs warning: passing raw JSON to 'cli index_repository' is deprecated ... use flags, presumably because the client converts flags to JSON internally before dispatch. Confusing when you are already on the recommended path.

4. codebase-memory-mcp install fails to register some hooks on first run. On a clean install:

   error: agent_config agent=Claude Code op=hook_register path=C:/Users/<user>/.claude/settings.json (target: regular file, 1742 bytes)
   error: agent_config agent=Claude Code op=hook_register path=C:/Users/<user>/.claude/settings.json (target: regular file, 2615 bytes)
   error: one or more agent configurations failed
   

   The reported file size differs between the two errors, which looks like a read-modify-write race between successive hook registrations against the same settings.json. Re-running install completed the remaining hooks and produced no duplicates, so it is recoverable — but the first run exits non-zero with a partially configured agent.

Happy to help

I can rerun any instrumented build or diagnostic command on this machine — the failure reproduces within seconds, and a build with a line-flushed worker log would probably pinpoint it immediately.

Reproduction

codebase-memory-mcp cli index_repository --repo-path "C:/path/to/repo" --name myrepo

Note: at the default log level the CLI prints nothing at all and just exits 1. The actual message (index worker ended with exit_nonzero) only appears with CBM_LOG_LEVEL=debug. See "Secondary issues" below.

Measured failure rates

Each row is repeated runs of the same target. Synthetic targets are flat directories of .cs files copied out of the same project, so content is held constant and only file count varies.

0.10.6 looked noticeably more stable than 0.10.8 in the 450-file band (3/3 vs 1/7), which suggests a regression somewhere between the two native runtimes — but 0.10.6 still cannot index the full repository.

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.