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.