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

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

Map an SMB share to a drive letter on Windows: net use Y: \\<host>\<share>
Put a repo at Y:\some_repo

Run either via MCP or CLI:

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

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:

Have index_repository return a non-success status (or include warnings/errors) when store.auto_clean fires.
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.

fix(store): accept lowercase drive letters in root_path integrity check

ci(temp): Windows repro harness for #394 group

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. 🙏

ci: remove temporary Windows repro harness

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:

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
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!

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!

fix(store): accept lowercase drive letters in root_path integrity check

@Azami1990

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.

feat(graph): queryable computation-bottleneck metrics + indexing perf…

test(windows): add red regressions for hook augmenter and UI drive pi…

test(windows): note umbrella tracker DeusData#394 in red-test analysis

test(windows): add red regressions for hook augmenter and UI drive pi…

test(windows): note umbrella tracker DeusData#394 in red-test analysis

Navigation Menu

Repository navigation

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

Summary

Environment

Steps to reproduce

Expected behavior

Actual behavior

Workaround

Likely cause (hypothesis)

Secondary issue: MCP wrapper masks the error

Suggested fix

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Steps to reproduce

Expected behavior

Actual behavior

Workaround

Likely cause (hypothesis)

Secondary issue: MCP wrapper masks the error

Suggested fix

Activity

DeusData commented on May 31, 2026

DeusData commented on May 31, 2026

Azami1990 commented on May 31, 2026

DeusData commented on Jun 1, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions