Repository navigation
Description
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
- codebase-memory-mcp cli index_repository '{"repo_path": "/path/to/repo"}'
- codebase-memory-mcp cli list_projects → correctly lists the project
- codebase-memory-mcp cli get_architecture '{"project_name": "<name from step 2>"}' → "project not found"
- 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.
Activity
DeusData commentedon Jun 27, 2026
Hey, yes we are already working on stability across all platforms. New release should come this weekend. Sorry for the experience
Merge pull request #714 from DeusData/fix/640-project-arg-alias
DeusData commentedon Jun 30, 2026
Fixed in 96a2f55 (PR #714). The query handlers now accept
project_name(andproject_id/projectName) alongside the canonicalprojectkey —list_projectssurfaces the field as "name" and the old hint said "pass the project name", soproject_namewas the natural guess. The no-store error now also distinguishes a missingprojectargument 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.fix(mcp): accept project_name alias + clearer no-store error (DeusDat…
bengtfrost commentedon Jun 30, 2026
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!