Repository navigation
index_repository with relative repo_path (".") corrupts and auto-deletes the project DB every run #794
Description
Summary
Calling index_repository with a relative repo_path of "." reliably corrupts the store and triggers auto-deletion of the whole project DB on every run. 100% reproducible (tested 3x back-to-back). The tool still returns "status":"indexed" in the same response, which masks the fact that the database was just deleted.
Steps to reproduce
cd /some/large/repo
codebase-memory-mcp cli index_repository '{"repo_path": "."}'Observed
Indexing runs to completion (in my case: 128,696 nodes, ~485K edges, 6,920 files), then immediately after the dump phase:
level=info msg=pipeline.done nodes=0 edges=485295 ...
ERROR store.corrupt table=projects bad_root_path=.
level=error msg=store.auto_clean project=root path=~/.cache/codebase-memory-mcp/root.db action=deleting corrupt db — re-index required
{"project":"root","status":"indexed", ...}
So the DB is deleted, yet the JSON response reports "status":"indexed" with a full node/edge count — misleading.
Reproduced identically twice more with a fresh rm -f ~/.cache/codebase-memory-mcp/root.db between runs. Always fails the same way when repo_path is ".".
Workaround (confirmed)
Passing an absolute path for the same directory works perfectly:
codebase-memory-mcp cli index_repository '{"repo_path": "/Users/me/some/large/repo"}'This indexed the identical directory cleanly (128,696 nodes / 485,363 edges), the DB persisted (<project>.db, 376 MB on disk), and subsequent search_graph queries returned correct results with accurate file:line locations. The only difference is relative . vs the resolved absolute path.
Suspected cause
The root_path for the projects table appears to be stored verbatim as . rather than resolved to an absolute path first. The post-write integrity check then sees bad_root_path=., flags the store corrupt, and the auto-clean recovery path deletes the entire DB instead of normalizing the path.
Suggested fix
Resolve repo_path to an absolute canonical path (e.g. realpath / abspath) at the entry point of index_repository, before it flows into the pipeline or the projects table — so no relative path (., ./, ../foo, ~/...) can ever reach the corruption-detection logic. Bonus: don't return "status":"indexed" on a run that ended in store.auto_clean deletion.
Environment
- codebase-memory-mcp 0.8.1 (standard variant, no
--ui) - macOS (Darwin), arm64
- Installed via
install.sh
Activity
DeusData commentedon Jul 3, 2026
Thanks for the clean relative-path repro. Triage: this is high-priority data-loss/corruption behavior under #391 and #396.
repo_path:"."must canonicalize before project naming/store validation, and the response must not reportstatus:"indexed"after the backing DB has been auto-deleted. The regression should prove relative and absolute paths resolve to the same durable project identity and that corrupt-store cleanup cannot masquerade as success.DeusData commentedon Jul 4, 2026
This should be fixed on current main via #780 (merge 09148ab): repo_path is now canonicalized at index time, project args at query time, and — decisively — inside the name derivation itself, so a relative "." and the absolute path derive the same project name and the DB no longer appears foreign/corrupt on the next run. Could you retest on a build from main (or the next release)? If the auto-delete still reproduces, the store-integrity log lines (store.schema / dump.verify) from a run would help pin what's left.
github-actions commentedon Jul 4, 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.fix(test): realpath fortify abort + Windows compile in repo-path guard
Merge pull request #987 from DeusData/fix/relative-repopath-guard
test(mcp): regression guard for relative repo_path canonicalization