get_architecture and query tools always return "project not found" on Linux — store never opened (strace confirms no .db openat)

[bengtfrost]

Version

codebase-memory-mcp dev and Release version (binary)

Platform

Linux (x64)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

What happened:
get_architecture (and all other query tools) always return "project not found or not indexed" even though list_projects correctly lists the project. strace confirms that query tools never call openat on any .db file — they open the cache directory, build the available_projects list from filenames, then immediately return the error without ever attempting to open a project database.
index_repository also never creates a central codebase-memory.db registry file. The cache directory after indexing contains only the per-project .db files and _config.db.

What I expected:
get_architecture '{"project_name": "home-username-Utveckling-Rust-Repo-goose-core"}' to return architecture data for the indexed project.
Reproduction steps:

Reproduction

1. codebase-memory-mcp cli index_repository '{"repo_path": "/path/to/repo"}'
2. codebase-memory-mcp cli list_projects → correctly lists the project
3. codebase-memory-mcp cli get_architecture '{"project_name": "<name from step 2>"}' → "project not found"
4. strace -e trace=openat codebase-memory-mcp cli get_architecture '...' → no openat on any .db file, only on the cache directory

Same result via MCP JSON-RPC over stdio. Both release and self-compiled dev build affected.

Environment:

Fedora 44, x86_64
codebase-memory-mcp dev (also reproduced on latest release)
auto_index=false, local embedding server configured in _config.db

Key observation:
list_projects opens each per-project .db file directly via directory scan and works correctly. Query tools (get_architecture, presumably search_graph etc.) appear to use a different code path to resolve the project — one that never reaches openat on the .db file. The two code paths diverge somewhere after the directory scan that populates available_projects.

Logs

❯ codebase-memory-mcp cli index_repository '{"repo_path": "/home/username/Utveckling/Rust/Repo/goose-core"}'
level=info msg=mem.init budget_mb=7877 total_ram_mb=15754
level=info msg=pipeline.discover files=612 elapsed_ms=6
level=info msg=pipeline.route path=incremental stored_hashes=612
level=info msg=incremental.classify changed=0 unchanged=612 deleted=0 mode_skipped=0
level=info msg=incremental.noop reason=no_changes
{"project":"home-username-Utveckling-Rust-Repo-goose-core",...,"status":"indexed"}

❯ ls -lh ~/.cache/codebase-memory-mcp
# codebase-memory.db is never created by index_repository
-rw-r--r--. 1 username username  12K _config.db
-rw-r--r--. 1 username username 6,8M home-username-.code-aichat.db
-rw-r--r--. 1 username username 169M home-username-Utveckling-Rust-Repo-goose-core.db

❯ codebase-memory-mcp cli list_projects
# Works — lists both projects with full git info, nodes, edges

❯ codebase-memory-mcp cli get_architecture '{"project_name": "home-username-Utveckling-Rust-Repo-goose-core"}'
level=info msg=mem.init budget_mb=7877 total_ram_mb=15754
{"error":"project not found or not indexed","hint":"Use list_projects to see all indexed projects, then pass the project name.","available_projects":["home-username-.code-aichat","home-username-Utveckling-Rust-Repo-goose-core"],"count":2}

❯ strace -e trace=openat codebase-memory-mcp cli get_architecture \
  '{"project_name": "home-username-Utveckling-Rust-Repo-goose-core"}' 2>&1 | grep -v "^openat.*= 3"
openat(AT_FDCWD, "/sys/fs/cgroup/cpu.max", O_RDONLY|O_CLOEXEC) = -1 ENOENT
openat(AT_FDCWD, "/sys/fs/cgroup/cpu/cpu.cfs_quota_us", O_RDONLY|O_CLOEXEC) = -1 ENOENT
openat(AT_FDCWD, "/sys/fs/cgroup/memory.max", O_RDONLY|O_CLOEXEC) = -1 ENOENT
openat(AT_FDCWD, "/sys/fs/cgroup/memory/memory.limit_in_bytes", O_RDONLY|O_CLOEXEC) = -1 ENOENT
openat(AT_FDCWD, "/home/username/.cache/codebase-memory-mcp", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
# Never attempts openat on any .db file — exits immediately after directory scan
{"error":"project not found or not indexed",...}
+++ exited with 1 +++

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Hey, yes we are already working on stability across all platforms. New release should come this weekend. Sorry for the experience

[DeusData]

Fixed in 96a2f55 (PR #714). The query handlers now accept project_name (and project_id/projectName) alongside the canonical project key — list_projects surfaces the field as "name" and the old hint said "pass the project name", so project_name was the natural guess. The no-store error now also distinguishes a missing project argument from an unknown project. Reproduced on macOS (not Linux-specific) and guarded by a reproduce-first test. Ships in the next release — thanks for the detailed report and the strace.

[bengtfrost]

Thanks for the fast turnaround and for digging into the root cause properly (reproduce-first test, distinguishing missing argument from unknown project). Works great! Keep up the good job!