Repository navigation
Description
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
- 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) .cbmignoreparsing matches POSIX behavior on Windows. ✅ (.cbmignore patterns silently ignored on Windows #274)- No crashes on Windows for repos that index on Linux/macOS. ✅ (Crash when indexing a repository #347)
- 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) —
WaitForSingleObjecton 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_repositoryfails withrepo_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_graphcrash - hook_augment PreToolUse augmenter is a structural no-op on Windows (POSIX-only path guards) #618 — Windows
hook_augmentpath 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.ps1reports 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 --portstarts but never listens - index not working #708 — Windows
index/ CLIrepo_pathparsing 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.)
Added 2026-08-03 (triage)
- Windows: install/uninstall/doctor all fail with "active CBM sessions and operations could not be stopped safely" #1416 — Windows install/uninstall/doctor cannot stop active sessions and recover
- Windows x64: v0.9.1-rc.1 daemon leaves existing cache files unreadable (empty ACL) #1351 — RC daemon leaves existing cache files unreadable with an empty ACL
Activity
ci(temp): Windows repro harness for #394 group
ci: remove temporary Windows repro harness
DeusData commentedon Jun 1, 2026
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 commentedon Jun 2, 2026
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 commentedon Jun 2, 2026
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 commentedon Jun 2, 2026
Adding a second data point for the reopen — this one is a minimal, deterministic, CI-reproducible repro of the lowercase-drive
root_pathintegrity check thatc1dabc9was 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)C:drive, cache at the defaultC:\Users\<user>\.cache\codebase-memory-mcp\substdrive. No spaces or non-ASCII in the path.Exact stored root_path
c:/WEBDEV/Signalyzed_Projects/Cardio-Cloud→ project keyc-WEBDEV-Signalyzed_Projects-Cardio-CloudC:/WEBDEV/Signalyzed_Projects/Cardio-Cloud→ project keyC-WEBDEV-Signalyzed_Projects-Cardio-CloudThe only difference is
c:vsC:.Minimal repro (CLI)
What the lowercase run logs — the build completes, then the projects-table integrity check rejects the row, deletes the DB, and still returns
"indexed":Every later
search_graph/index_status/get_architecturethen returns"project not found or not indexed"— even though the response's ownavailable_projectslists 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_pathstartingc:/…and assertslist_projectsis non-empty afterward would catch it.Two things that may help:
"indexed"response afterstore.auto_cleandeletes the DB is the real trap —index_repositoryreports success whilelist_projectsis empty, so it looks like a query bug rather than an indexing one. Surfacing the corruption as an error (or droppingnodes/edges+ adding awarning) would make this self-evident.c:\…, so anything that derivesrepo_pathfrom the CWD hits this by default. (Workaround we're using: always pass an uppercase drive letter and setauto_index=false, since on a case-insensitive FS thec-….dbandC-….dbcache 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 theprojects-table integrity check computes/comparesbad_root_path— or compare case-insensitively on Windows. Sincec1dabc9shipped 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
--verboselogs if useful.DeusData commentedon Jun 2, 2026
@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
feat(graph): queryable computation-bottleneck metrics + indexing perf…
FDiskas commentedon Jun 2, 2026
CPU and 32GB of ram was used at max level to index my small project and everything crashed.
lichaoren commentedon Jun 4, 2026
I still experience (not so) random crash on indexing my large C++ codebase. As pointed out in another closed issue, running in a single thread delays the crash, and parses 99% of the files.
Single thread was in an ubuntu WSL, the other variable is smaller RAM size there, FYI
9 remaining items
test(windows): note umbrella tracker DeusData#394 in red-test analysis
DeusData commentedon Oct 25, 2026
Thank you to everyone who supplied the Windows retests and workarounds. The later comments show why the original completed checklist cannot represent the whole umbrella: installer registration, UI indexing, and path/CLI behavior have separate follow-ups. I have no new blanket resolution to report, and the supplied examples do not need repeating. Sorry for the delay—this is waiting on maintainer follow-up, and I’ll follow up soon.