Skip to content

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

@MIKALUXE

Description

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions