Windows: mapped drive path fails with bad_root_path/store.corrupt, local path works

[memniko]

Environment

• OS: Windows 11
• MCP client: OpenCode
• codebase-memory-mcp version: 0.6.0
• Binary used: codebase-memory-mcp-ui-windows-amd64

Summary

On Windows, indexing works when the repository is on a local path like:

• C:\Users\<redacted>\Downloads\Planning

But indexing fails for the same repository when accessed through a mapped drive like:

• W:\GIT\Planning

Reproduction

Mapped drive path -> fails

& "D:\MCP\codebase-memory-mcp-ui-windows-amd64\codebase-memory-mcp.exe" --% cli index_repository "{\"repo_path\":\"W:\\GIT\\Planning\"}"

Relevant output:

ERROR store.corrupt table=projects bad_root_path=W:/GIT/Planning
level=error msg=store.auto_clean project=W-GIT-Planning path=... action=deleting corrupt db — re-index required
{"content":[{"type":"text","text":"{\"project\":\"W-GIT-Planning\",\"status\":\"indexed\"}"}]}

Local path -> works

& "D:\MCP\codebase-memory-mcp-ui-windows-amd64\codebase-memory-mcp.exe" --% cli index_repository "{\"repo_path\":\"C:\\Users\\<redacted>\\Downloads\\Planning\"}"

Relevant output:

{"content":[{"type":"text","text":"{\"project\":\"C-Users-REDACTED-Downloads-Planning\",\"status\":\"indexed\",\"nodes\":2845,\"edges\":5405}"}]}

Notes

• cli list_projects works normally.
• The same repository indexes successfully after copying it from W:\GIT\Planning to a local path.
• The issue is reproducible outside OpenCode using the CLI directly.
• In the failing case, the DB is deleted after store.corrupt, but the response still reports status:"indexed".

Expected behavior

• A mapped drive path like W:\GIT\Planning should either index successfully or fail clearly.
• The tool should not return status:"indexed" if the DB was classified as corrupt and deleted.

Question

Is this a known limitation with mapped/network/subst drives on Windows, or is this a path normalization / validation bug?

[DeusData]

Hey, thanks for noticing, will tackle this ASAP when I am back after the 15th :)