task: Windows platform issues (8 bugs)

[DeusData]

Scope

Umbrella tracker for Windows-specific bugs across install, indexing, path handling, and search. The wide-char API work (PR #386) and cmd.exe-compatible pipeline syntax (PR #325) cover subsets — this task tracks the remaining gaps and serves as a place to file Windows regressions.

Sub-issues

• "install" command does not work for opencode in windows 11 #221 — "install" command does not work for opencode in windows 11 — FIXED (0485d3f: find_in_path probes PATHEXT .exe/.cmd/.bat/.ps1; verified compiling+passing in Windows CI)
• Windows: mapped drive path fails with bad_root_path/store.corrupt, local path works #227 — mapped drive path fails with bad_root_path/store.corrupt — awaiting reporter v0.7.0 retest (lowercase-drive integrity fix c1dabc9 shipped; asked for exact stored root_path)
• Directory structure is not being read correctly on Windows #266 — Directory structure not read correctly on Windows — CLOSED (fixed in v0.7.0)
• .cbmignore patterns silently ignored on Windows #274 — .cbmignore patterns silently ignored on Windows — CLOSED (fixed in v0.7.0)
• Indexing repository unexpectedly indexes C:/Users/{USERNAME} instead of selected repo path (security/privacy risk) #331 — indexes C:/Users/{USERNAME} instead of selected path (privacy) — CLOSED (fixed in v0.7.0)
• Crash when indexing a repository #347 — Crash when indexing (Windows, 0xc0000005) — CLOSED (fixed in v0.7.0)
• search_code returns 0 results on Windows post-#310: Select-String via _popen fails silently #348 — search_code 0 results on Windows post-feat(mcp): add Windows support for code search via PowerShell #310 (Select-String _popen) — CLOSED (fixed in v0.7.0)
• index_repository silently deletes DB on Windows when repo path is on a mapped SMB drive (drive letter) #367 — silently deletes DB on mapped SMB drive — awaiting reporter v0.7.0 retest (same lowercase-drive fix c1dabc9; asked for exact stored root_path)

Status (2026-05-31)

6 of 8 resolved (#221 fixed + Windows-CI-verified; #266/#274/#331/#347/#348 fixed in v0.7.0). Remaining: #227 and #367, both the mapped/SMB-drive integrity-check class — fix (lowercase drive letters, c1dabc9) shipped in v0.7.0, but neither is reproducible in CI (no SMB share / mapped drive available), so both are awaiting reporter confirmation on v0.7.0. The bug surface is addressed; closure is reporter-dependent.

Acceptance

1. CI runs Windows smoke tests for ASCII / non-ASCII paths (PR fix(windows): use wide-char API for non-ASCII path support #386), paths with spaces / & / ( / ). ✅ (mapped/UNC drives not CI-testable)
2. .cbmignore parsing matches POSIX behavior on Windows. ✅ (.cbmignore patterns silently ignored on Windows #274)
3. No crashes on Windows for repos that index on Linux/macOS. ✅ (Crash when indexing a repository #347)
4. Privacy-critical Indexing repository unexpectedly indexes C:/Users/{USERNAME} instead of selected repo path (security/privacy risk) #331 (wrong path indexed) has a defense-in-depth test. ✅

Why one task

Windows-specific bugs share infrastructure (path normalization, process spawning, wide-char API surface).

Added 2026-06-24 (triage)

• Windows stdio MCP handshake hangs — stdout only flushes on stdin EOF (v0.8.1) #513 — Windows stdio MCP handshake hangs (stdout flushes only on stdin EOF, v0.8.1) — WaitForSingleObject on anonymous pipe; overlaps bundle Bug Fixes & Improvements: Windows Stdio hangs, Cascading Gitignore, UTF-8 Snippets #530
• D:\ drive and custom path cannot be selected in server UI #548 — D:\ drive / custom path cannot be selected in server UI (drive-letter path handling)

Added 2026-06-29 (triage)

• Windows: cli index_repository fails with "repo_path is required" #680 — Windows CLI index_repository fails with repo_path is required
• [Windows] MCP stdio startup emits localized path-not-found message on stderr #654 — Windows stdio startup emits localized path-not-found message on stderr
• Windows: tree-sitter definitions pass fails on ALL files when repo_path contains non-ASCII (CJK / Cyrillic / Arabic / accented Latin / etc.) characters #636 — Windows non-ASCII paths break tree-sitter definitions pass
• Windows: MCP server hangs on initialize when launched by Hermes/AnyIO stdio client #635 — Windows MCP initialize hang with Hermes/AnyIO stdio client
• Crash when calling query_graph #627 — Windows query_graph crash
• hook_augment PreToolUse augmenter is a structural no-op on Windows (POSIX-only path guards) #618 — Windows hook_augment path guards make augmentation a no-op
• Windows: install.ps1 reports success but leaves MCP server unregistered (MotW + swallowed config errors + malformed taskkill) #697 — Windows install.ps1 reports success but leaves MCP server unregistered
• Bug: File parsing fails silently on Windows when project path contains accented/non-ASCII characters #700 — duplicate/evidence case for Windows accented/non-ASCII path parsing failure (see Windows: tree-sitter definitions pass fails on ALL files when repo_path contains non-ASCII (CJK / Cyrillic / Arabic / accented Latin / etc.) characters #636)

Added 2026-06-30 (triage)

• [Windows] --ui=true starts but HTTP server never listens on v0.8.1 #707 — Windows UI binary --ui=true --port starts but never listens
• index not working #708 — Windows index / CLI repo_path parsing reports plus D-drive UI picker evidence

Added 2026-07-09 (triage)

• codebase-memory-mcp-ui-windows-amd64 doesn't provide ui function #795 — codebase-memory-mcp-ui-windows-amd64 doesn't provide the ui function
• Standalone dashboard (--ui=true) dies silently within seconds, no stderr output #909 — standalone dashboard (--ui=true) dies silently within seconds, no stderr
• Windows v0.8.1: stale graph + Permission denied on delete_project after orphan cbm process (reconfirm #277) #914 — stale graph + Permission denied on delete_project after orphan cbm process (reconfirm New files not indexed — WAL-checkpoint blocked on successfully-indexed project (Windows, v0.6.0) #277)
• v0.9.0 Windows: search_code times out after 180s; related parallel call shows ~180s dispatch wait; diagnostics lack per-call timing #965 — v0.9.0: search_code times out after 180s; parallel dispatch wait; diagnostics lack per-call timing
• [Bug] v0.9.0 regression: CJK repo_path still crashes despite #636 fix #973 — v0.9.0 regression: CJK repo_path still crashes despite Windows: tree-sitter definitions pass fails on ALL files when repo_path contains non-ASCII (CJK / Cyrillic / Arabic / accented Latin / etc.) characters #636 fix
• Windows: get_code_snippet returns "(source not available)" and search_code returns 0 matches for projects indexed under non-ASCII (CJK) paths — indexing itself succeeds #903 — CJK paths: get_code_snippet "(source not available)" / search_code 0 matches (search_code part fixed by fix(windows): read search_code temp files as UTF-8 #956; snippet part open)
• flaky: probe_clojure_imports_edge intermittently fails on Windows (0 imports) #850 — flaky: probe_clojure_imports_edge intermittently fails on Windows (0 imports)

(#929 hook OpenWith dialog → PR #926; #950 empty /api/processes → PR #955 — tracked in their PRs.)

[DeusData]

All 8+ Windows bugs are now closed — fixed across v0.7.0: non-ASCII path support via wide-char API (#386), PATHEXT probing in find_in_path (#221), Cursor MCP registration (#222 via integration), fish PATH syntax (#319), lowercase/mapped-drive root_path integrity (#367/#227, c1dabc9), and the cmd.exe git-log history pass (df38e33). Closing the umbrella.

[bsun0000]

It is marked as closed and completed, but it still does not work for me, Windows 10.
Tested versions: v0.6.1, v0.7.0, git-latest (forked & compiled via git workflow).

Cache sits in C:\Users\BlackSun.cache\codebase-memory-mcp\ - no weird symbols in the path, no spaces.
My codebase is indexed here, stored in a .db file.

codebase-memory-mcp.exe cli list_projects - does not list anything. Even if i explicitly set the CBM_CACHE_DIR env. parameter.
{"projects":[],"hint":"No projects indexed. Call index_repository(repo_path=...) first."}

If i copy _config.db to config.db, it now shows:
{"projects":[{"name":"config","root_path":"","nodes":0,"edges":0,"size_bytes":12288}]}

So it sees the path and can read it. Same behavior with --ui=true - webui ignores the actual indexed codebase.

The web UI is still broken - "Select Repository Folder" shows folders with empty names.

The index is 4.2Gb big, memory usage spiked to almost 128GB of RAM during indexing. But there were no errors in the console.. still, could this be the issue? The codebase was simply.. too big? Around 100k files to index, 5.85Gb in total, assuming this program didn't ignore both .gitignore and .cbmignore i setup to cut some large and problematic files.

UPD: Both DB Browser and SQLite Expert fails to open the index: "database disk image is malformed". *sigh*..

[DeusData]

Hey @bsun0000 thx for reporting, will take another look. Sorry for the inconvenience. Can you give more details on what kinda project you try to index? In general a summary of your setup and indexing targets would be good. Maybe you can let your agent make a summary on this one. Need some way to reproduce this

[janmajorczyk]

Adding a second data point for the reopen — this one is a minimal, deterministic, CI-reproducible repro of the lowercase-drive root_path integrity check that c1dabc9 was supposed to fix, on a plain local NTFS path with no SMB/mapped drive. It still fails on v0.7.0.

This looks distinct from @bsun0000's case (100k files, 4.2 GB index, ~128 GB RAM, "database disk image is malformed") — that one smells like a size/OOM-driven corruption. Mine is the opposite: a normal ~1,200-file repo, no memory pressure, no crash. The only variable is the case of the drive letter, which isolates the integrity-check path cleanly.

It also directly answers the two things asked in #227/#367 — "v0.7.0 retest" and "exact stored root_path".

Environment

• codebase-memory-mcp 0.7.0 (also repro'd that uppercase works on the same build)
• Windows 11, local NTFS C: drive, cache at the default C:\Users\<user>\.cache\codebase-memory-mcp\
• No SMB / UNC / mapped / subst drive. No spaces or non-ASCII in the path.

Exact stored root_path

• Fails: c:/WEBDEV/Signalyzed_Projects/Cardio-Cloud → project key c-WEBDEV-Signalyzed_Projects-Cardio-Cloud
• Works: C:/WEBDEV/Signalyzed_Projects/Cardio-Cloud → project key C-WEBDEV-Signalyzed_Projects-Cardio-Cloud

The only difference is c: vs C:.

Minimal repro (CLI)

# lowercase drive letter -> indexes, then self-deletes
codebase-memory-mcp cli index_repository '{"repo_path":"c:/Projects/MyRepo","mode":"moderate"}'
codebase-memory-mcp cli list_projects     # -> {"projects":[]}

# identical repo, uppercase drive letter -> persists, queries work
codebase-memory-mcp cli index_repository '{"repo_path":"C:/Projects/MyRepo","mode":"moderate"}'
codebase-memory-mcp cli list_projects     # -> project present

What the lowercase run logs — the build completes, then the projects-table integrity check rejects the row, deletes the DB, and still returns "indexed":

level=info  msg=pipeline.done nodes=0 edges=15308 elapsed_ms=4947
ERROR store.corrupt table=projects bad_root_path=c:/WEBDEV/Signalyzed_Projects/Cardio-Cloud
level=error msg=store.auto_clean project=c-WEBDEV-Signalyzed_Projects-Cardio-Cloud \
            path=C:/Users/<user>/.cache/codebase-memory-mcp/c-WEBDEV-Signalyzed_Projects-Cardio-Cloud.db \
            action=deleting corrupt db — re-index required
{"project":"c-WEBDEV-Signalyzed_Projects-Cardio-Cloud","status":"indexed"}

Every later search_graph / index_status / get_architecture then returns "project not found or not indexed" — even though the response's own available_projects lists the project — because the DB was deleted right after being written.

Why this should be CI-testable (the blocker mentioned in #394): no SMB/mapped drive is involved — just a lowercase drive letter. A smoke test that indexes a fixture with repo_path starting c:/… and asserts list_projects is non-empty afterward would catch it.

Two things that may help:

1. The "indexed" response after store.auto_clean deletes the DB is the real trap — index_repository reports success while list_projects is empty, so it looks like a query bug rather than an indexing one. Surfacing the corruption as an error (or dropping nodes/edges + adding a warning) would make this self-evident.
2. This is very common with agent-driven indexing. Agents like Claude Code report the Windows CWD as lowercase c:\…, so anything that derives repo_path from the CWD hits this by default. (Workaround we're using: always pass an uppercase drive letter and set auto_index=false, since on a case-insensitive FS the c-….db and C-….db cache files collide and a lowercase auto-index clobbers a good uppercase index.)

Suggested fix: upper-case (or case-fold) the drive letter wherever separator normalization already happens (cbm_normalize_path_sep() from v0.5.7?), before the projects-table integrity check computes/compares bad_root_path — or compare case-insensitively on Windows. Since c1dabc9 shipped in v0.7.0 but this still reproduces, the normalization likely isn't applied on the integrity-check read path for plain local drives.

Happy to run a diagnostic build or grab fuller --verbose logs if useful.

[DeusData]

@bsun0000 thanks for sharing. You can take down the link. Ideally provide me with an OSS project with similar traits, not feeling so comfortable with downloading files from anonymous people (nothing against you, hope you understand it). Maybe you can ask your agent to compare your repo with public available OSS ones and get the key characteristics matched so that I can use it for reproducibility. The size I can replicate easily by just copying the repo over and over and indexing them together. That is fine for me. @janmajorczyk also thanks, will have a look as well

[FDiskas]

CPU and 32GB of ram was used at max level to index my small project and everything crashed.