Repository navigation
index_repository crashes at dump phase — all modes affected #1379
Description
Version
codebase-memory-mcp 0.9.0
Platform
macOS (Apple Silicon)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
Bug Report: index_repository crashes at dump phase — all modes affected
Repository: DeusData/codebase-memory-mcp
Environment
| Item | Value |
|---|---|
| OS | macOS 15.6.1 (24G90), Apple Silicon (arm64) |
| Version | codebase-memory-mcp 0.9.0 |
| Shell | zsh |
| Disk space | 124 GiB available |
| Cache dir | ~/.cache/codebase-memory-mcp/ (only _config.db, no logs/ subdirectory) |
Expected Behavior
Index completes successfully and list_projects shows the indexed project.
Actual Behavior
All pipeline phases run to completion successfully, then crash at the final dump phase:
level=info msg=pass.complexity functions=220
level=info msg=pass.timing pass=complexity elapsed_ms=0
level=error msg=pipeline.err phase=dump
Final output:
{
"project": "test-project",
"status": "error",
"hint": "Pipeline failed. Check repo_path exists and contains source files. Try mode='fast' for a quicker diagnostic run."
}Worker exits with code 1:
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 ...
After failure, list_projects returns {"projects":[],...} — no partial index is retained.
Pipeline Statistics (all successful before dump crash)
| Phase | Result |
|---|---|
| structure | 122 nodes, 121 edges |
| parallel_extract | 750 nodes, 0 errors (118 files) |
| registry_build | 254 entries, 750 defines, 409 imports |
| parallel_resolve | 699 calls, 8 usages |
| complexity | 220 functions |
| dump | crash |
Additional Observations
- The referenced worker log file (
~/.cache/codebase-memory-mcp/logs/.worker-*.log) does not exist. Thelogs/directory is never created, suggesting the dump crash happens before any log file is opened. - All three modes (
full,moderate,fast) fail identically at dump. --persistence trueand--persistence falseboth fail identically.- The project used for testing contains 116 source files (HTML, JS, CSS, Markdown), but the failure is believed to be path-independent — it occurs before any on-disk state is written.
codebase-memory-mcp updateconfirms 0.9.0 is latest.
Suggested Investigation
The dump phase appears to be the serialization/persistence step. Possible causes:
- Missing target directory: if dump tries to write to
~/.cache/codebase-memory-mcp/or a project subdirectory that doesn't exist and fails to create it silently. - Nil pointer / unhandled edge case: the pipeline produces valid data (750 nodes) but the serializer encounters a nil or unexpected value.
- File permission error swallowed: on macOS, sandboxing or permission restrictions may prevent writing to the cache path without surfacing a clear error message.
A panic stack trace or more verbose dump-phase logging would help narrow this down significantly.
Reproduction
Reproduction
# Step 1: index any project
codebase-memory-mcp cli index_repository \
--repo-path "/path/to/any/project" \
--mode fast \
--name test-project
# Step 2: verify — always empty
codebase-memory-mcp cli list_projects
# Output: {"projects":[]}All pipeline phases complete (750 nodes extracted, 220 functions), but list_projects never shows the project. Reproduced with all three modes (full, moderate, fast) and both --persistence true / false.
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
github-actions commentedon Aug 3, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.DeusData commentedon Aug 3, 2026
Thank you for reporting that all indexing modes reach the same dump-phase crash. Because this is from 0.9.0 and the pipeline/daemon path changed substantially in the RC, could you retest with
0.9.1-rc.1or current main and attach the local crash report plus the last log events before termination? Please omit proprietary paths if necessary. I have kept this high priority in0.9.1-rcand marked it awaiting that discriminator.DeusData commentedon Aug 14, 2026
@xx235300 — your phase table is the most useful part of this report: every pass green through
complexityat 220 functions, thenpipeline.err phase=dump, with nologs/directory ever created and both persistence settings failing identically. That narrows it to the serialization step rather than parsing, and it means the index you waited for is never written andlist_projectsstays empty.Asking you to retest an RC before we had dug into it was not a fair response, and the
awaiting-reporterlabel makes it look like we are blocked on you. We are not — please do not read it that way.No root cause to report honestly yet. Tonight's v0.10.5 is being cut for the issues that make cbm impossible to operate, and "indexing completes and then persists nothing" is squarely in that set. Sorry for the wait.
DeusData commentedon Oct 19, 2026
Thank you again for the phase-by-phase report. The last maintainer response correctly put the next action on our side, and I have no new root cause or verified fix to share. No repeat run or extra reporter information is requested by this follow-up.
DeusData commentedon Oct 25, 2026
Thank you for the phase-by-phase evidence. The dump failure remains a maintainer investigation; no repeat run or extra information is needed from you now. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.