index_repository silently deletes DB on Windows when repo path is on a mapped SMB drive (drive letter)

[Azami1990]

Summary

On Windows, indexing a repository that lives on a mapped SMB network drive (e.g. Y:\ → \\server\share) appears to succeed but the database is auto-deleted immediately after writing. list_projects then returns empty. Using the UNC path directly works fine.

Environment

• codebase-memory-mcp 0.6.1 (Windows amd64 binary, installed via npm i -g codebase-memory-mcp)
• OS: Windows 10/11
• Repo location: Y:\testspiel, where Y: is mapped via net use Y: \\192.168.178.73\pihome (SMB share)
• Client: Claude Code (MCP stdio)

Steps to reproduce

1. Map an SMB share to a drive letter on Windows: net use Y: \\<host>\<share>
2. Put a repo at Y:\some_repo
3. Run either via MCP or CLI:

   codebase-memory-mcp cli index_repository '{"repo_path": "Y:/some_repo"}'

4. Run list_projects — returns {"projects":[]}

Expected behavior

Project is indexed, persisted, and visible in list_projects. Subsequent queries (search_graph, get_graph_schema, etc.) work against it.

Actual behavior

Indexing pipeline completes successfully (nodes/edges produced and dumped), but the store then flags the project's root_path as corrupt and auto-deletes the DB:

level=info msg=gbuf.dump nodes=329 edges=470
level=info msg=pass.timing pass=dump elapsed_ms=3
level=info msg=pass.timing pass=persist_hashes files=65
level=info msg=pipeline.done nodes=0 edges=470 elapsed_ms=359
ERROR store.corrupt table=projects bad_root_path=Y:/testspiel
level=error msg=store.auto_clean project=Y-testspiel path=C:/Users/---/.cache/codebase-memory-mcp/Y-testspiel.db action=deleting corrupt db — re-index required
{"project":"Y-testspiel","status":"indexed"}

After this, C:/Users/---/.cache/codebase-memory-mcp/ contains only _config.db and config.json — no project DB. list_projects returns empty.

Workaround

Use the UNC path directly:

codebase-memory-mcp cli index_repository '{"repo_path": "//192.168.178.73/pihome/testspiel"}'

This produces the expected response and the DB is retained:

{"project":"192.168.178.73-pihome-testspiel","status":"indexed","nodes":329,"edges":470,...}

list_projects then correctly returns the project.

Likely cause (hypothesis)

The store.corrupt check for root_path looks like it rejects Windows drive-letter paths in some way — possibly:

• Validating that the path is absolute using a Unix-style rule (starts with /), where Y:/... doesn't pass.
• Or doing a filepath.IsAbs / os.Stat-style check that returns inconsistent results on a mapped SMB drive letter (file is present but some attribute the validator depends on is unset).

UNC paths bypass this because they have a leading // and are treated as absolute by both Go and the validator.

A related symptom is visible earlier in the same run (probably the git-history pass) — a localized Windows error leaks to stderr:

Der angegebene Pfadname ist ungültig.
level=info msg=pass.timing pass=githistory_compute elapsed_ms=18

(German: "The specified path is invalid.") This suggests another spot where drive-letter-rooted SMB paths aren't handled cleanly.

Secondary issue: MCP wrapper masks the error

When invoked via MCP index_repository, the response is just {"project":"Y-testspiel","status":"indexed"} with no indication that the store immediately deleted the DB. The CLI mode (codebase-memory-mcp cli index_repository ...) surfaces the error in stderr, which is how this was diagnosed. It would help to:

1. Have index_repository return a non-success status (or include warnings/errors) when store.auto_clean fires.
2. Either accept drive-letter SMB paths in the root_path validator, or fail loudly before indexing rather than after.

Suggested fix

• Normalize Windows paths to UNC internally when the drive letter resolves to an SMB share (GetDriveType == DRIVE_REMOTE), or
• Loosen the root_path validator to accept <letter>:[/\\]... on Windows.

Happy to test a pre-release build against this setup.

[DeusData]

Progress: I fixed a concrete cause of the store.corrupt → DB deleted behavior — the project root_path integrity check rejected lowercase drive letters (only A-Z were accepted), so a path like c:/... was flagged corrupt and the DB auto-deleted (commit on main). I also verified in Windows CI that indexing a repo at a local C:\ drive-letter path now persists the DB (1.7 MB, root_path: C:/cbmrepo, survives) — see run.

Your case is specifically a mapped SMB network drive (net use Y: \\\\server\\share), which I can't mount in CI, so please retest on v0.7.0: does Y:\repo now persist? If it still auto-deletes, the ls -l of the cache dir + the exact store.corrupt log line right after indexing would pin down whether it's still a root_path-validation reject or something SMB-specific (e.g. WAL on a network share). Keeping open pending that. 🙏

[DeusData]

Thanks for the detailed report and logs — the `store.corrupt ... bad_root_path=...` → `auto_clean ... deleting corrupt db` sequence is exactly the smoking gun.

Root cause (we believe): the startup integrity check validated that a project's `root_path` begins with `/` or a drive letter, but it only accepted uppercase drive letters (`A`–`Z`). On Windows, mapped / SMB network drives (mounted via `net use`) are frequently reported back with a lowercase drive letter, whereas local drives come back uppercase — which is why a local `C:\…` path worked but a mapped `w:\…` / `y:\…` path was flagged corrupt and the freshly-written DB was deleted.

Fixed in commit c1dabc9 (shipped in v0.7.0): the integrity check now accepts upper- and lower-case drive letters, so a mapped-drive `root_path` no longer trips the corruption heuristic.

Could you retest on v0.7.0 and confirm? Index the repo on the mapped drive, then run `list_projects` — the project should persist. If it still gets deleted, please paste:

1. The exact `root_path` as stored — run `list_projects` (or copy the precise string from the `bad_root_path=` log line, preserving its exact case), and
2. The full `net use` mapping you used.

That tells me the precise first byte the check is seeing. Keeping this open until you can confirm on v0.7.0 — thanks again for the thorough repro steps!

[Azami1990]

Confirmed fixed on v0.7.0 on the mapped-SMB-drive case. Thanks for the quick turnaround!

Test setup:

• Drive mapping: net use Y: \\192.168.178.73\pihome (still the same as before)
• Indexed Y:\testspiel via MCP index_repository

Result:

{
  "projects": [
    {
      "name": "Y-testspiel",
      "root_path": "Y:/testspiel",
      "nodes": 487,
      "edges": 770,
      "size_bytes": 2686976
    }
  ]
}

DB persists in C:/Users/xxx/.cache/codebase-memory-mcp/Y-testspiel.db (2.6 MB), no store.corrupt / store.auto_clean log lines.

One small note on the case-hypothesis: on my system the stored root_path is uppercase Y:/testspiel (and the bad_root_path= from the old logs was also uppercase Y:/testspiel). So in my specific repro the trigger wasn't a lowercase drive letter — but since the fix now accepts both cases, the SMB path passes either way. Possibly there's also a broader path-validation branch that was tightened, or my Windows reports the drive letter uppercase while other mapped-drive setups report it lowercase. Either way, working now. 👍

Issue can be closed from my side. Thanks again!

[DeusData]

Confirmed fixed on your mapped-SMB-drive setup — closing. Thanks for the clean retest, @Azami1990. 🙏

Good catch on the nuance: since your stored root_path was uppercase Y:/testspiel, the lowercase-drive-letter case wasn't the exact trigger on your machine. The c1dabc9 fix (accept upper- and lower-case drive letters) is what makes the SMB path pass regardless — and v0.7.0 also tightened/relocated the broader root_path integrity validation, so the corrupt-DB auto-delete no longer fires for mapped-drive paths in general. Net: persists correctly (487 nodes, no store.corrupt/auto_clean). Reopen if it ever recurs with a different mapping.