Windows: Queries return 0 results despite successful indexing (path resolution bug)

[MIKALUXE]

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: 1

The 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:

1. detect_session() (~line 2056) — uses strrchr(p, '/') to parse the CWD, but on Windows getcwd() returns backslashes (C:\Users\...). The forward-slash search returns NULL, so session_project gets set to the raw path with backslashes/colons.

2. resolve_store() (~line 591) — when project param is NULL, returns srv->store (empty in-memory store) instead of falling back to session_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.