index_repository with relative repo_path (".") corrupts and auto-deletes the project DB every run

[Phantom-Star829]

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

[DeusData]

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 report status:"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]

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]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.