-
Notifications
You must be signed in to change notification settings - Fork 133
Windows: Queries return 0 results despite successful indexing (path resolution bug) #80
Description
Description
On Windows (Git Bash), index_repository completes successfully and creates the correct DB file, but all query tools (search_graph, get_architecture, query_graph, search_code, index_status) return 0 results / no_project.
Environment
- OS: Windows 11 Home 10.0.26200
- Version: v0.5.3
- Shell: Git Bash (MSYS2)
Steps to Reproduce
# Index succeeds
codebase-memory-mcp.exe cli index_repository '{"repo_path":"C:/Users/user/Desktop/myproject"}'
# → nodes=8393, edges=14160
# list_projects sees the DB
codebase-memory-mcp.exe cli list_projects '{}'
# → {"name":"C-Users-user-Desktop-myproject","root_path":"C:/Users/user/Desktop/myproject","nodes":8393,"edges":14160}
# But every query returns empty
codebase-memory-mcp.exe cli search_graph '{"repo_path":"C:/Users/user/Desktop/myproject","name_pattern":".*","limit":3}'
# → {"total":0,"results":[],"has_more":false}
codebase-memory-mcp.exe cli index_status '{"repo_path":"C:/Users/user/Desktop/myproject"}'
# → {"status":"no_project"}
codebase-memory-mcp.exe cli get_architecture '{"repo_path":"C:/Users/user/Desktop/myproject","aspects":["summary"]}'
# → {"total_nodes":0,"total_edges":0,"node_labels":[],"edge_types":[]}Root Cause Investigation
Using Python's sqlite3 to inspect the DB directly:
import sqlite3
conn = sqlite3.connect('~/.cache/codebase-memory-mcp/C-Users-user-Desktop-myproject.db')
# Data IS there:
cursor.execute("SELECT COUNT(*) FROM nodes") # → 8393
cursor.execute("SELECT COUNT(*) FROM edges") # → 14160
cursor.execute("SELECT * FROM projects")
# → ('C-Users-user-Desktop-myproject', '2026-03-20T18:05:32Z', 'C:/Users/user/Desktop/myproject')
# Label breakdown:
# Function: 2312, Variable: 1796, Section: 1305, Module: 719, File: 720
# Interface: 466, Type: 288, Method: 280, Folder: 280, Route: 155, Class: 71, Project: 1The data is correctly indexed and stored in SQLite. The bug is in the query-side path resolution — when the query tools receive repo_path, they cannot map it back to the project name to open the correct DB.
list_projects works because it scans the cache directory for *.db files directly, bypassing the path→project_name resolution.
Workaround
Passing "project" directly instead of "repo_path" works:
# This works (returns results):
codebase-memory-mcp.exe cli search_graph '{"project":"C-Users-user-Desktop-myproject","name_pattern":".*","limit":5}'Root Cause
Traced to src/mcp/mcp.c:
-
detect_session()(~line 2056) — usesstrrchr(p, '/')to parse the CWD, but on Windowsgetcwd()returns backslashes (C:\Users\...). The forward-slash search returns NULL, sosession_projectgets set to the raw path with backslashes/colons. -
resolve_store()(~line 591) — whenprojectparam is NULL, returnssrv->store(empty in-memory store) instead of falling back tosession_project.
Suggested Fix
In detect_session(), replace the manual last-two-components parsing with cbm_project_name_from_path() which already handles backslashes, colons, and dash collapsing:
if (srv->session_root[0]) {
char *pname = cbm_project_name_from_path(srv->session_root);
if (pname) {
snprintf(srv->session_project, sizeof(srv->session_project), "%s", pname);
free(pname);
}
}In resolve_store(), add session fallback:
if (!project) {
if (srv->session_project[0]) {
project = srv->session_project;
} else {
return srv->store;
}
}Additional Note
The pipeline.done log line shows nodes=0 even though gbuf.dump shows nodes=8393:
level=info msg=gbuf.dump nodes=8393 edges=14160
level=info msg=pipeline.done nodes=0 edges=14160
This might be related (a delta count?) or might indicate the persistence step has issues.