Repository navigation
index_repository --name is silently ignored when the repo sits outside the server's allowed root — project gets a path-derived name #1317
Description
Version
0.9.0
Platform
macOS (Apple Silicon) — macOS 25.5.0, darwin-arm64
Install channel
GitHub release archive
Binary variant
standard
What happened, and what did you expect?
The MCP server is configured with CBM_ALLOWED_ROOT=/Users/xtorres/projects. Indexing a repo outside that root, with the env var overridden per-command, succeeds — but --name is discarded and the project is registered under a slugified absolute path instead.
$ CBM_ALLOWED_ROOT=/Users/xtorres codebase-memory-mcp cli index_repository \
--repo-path /Users/xtorres/dev/orkestra --name orkestra
{"nodes":5324,"edges":12841,"status":"indexed"}
$ codebase-memory-mcp cli index_status --project orkestra
# -> reports not indexed
$ ls ~/.cache/codebase-memory-mcp/
Users-xtorres-dev-orkestra.db # <- not orkestra.dbRepos inside the allowed root honour --name correctly, so this appears specific to the outside-root path.
Persistence: survives a full delete_project + fresh index with --name orkestra, and also survives re-running with CBM_ALLOWED_ROOT=/Users/xtorres/dev (a root that does contain the repo). The derived name is sticky.
Why it matters: no error, no warning. The obvious follow-up call — index_status --project orkestra — reports the project as not indexed, which reads as a failed or lost index rather than a renamed one. An agent driving this over MCP has no way to learn the real name except by listing the cache directory or calling list_projects (which has its own hang, #1195).
Expected: either honour --name regardless of root, or fail loudly with the reason and the name that will actually be used.
Reproduction
- Set
CBM_ALLOWED_ROOTto some directoryA. cli index_repository --repo-path <repo outside A> --name shortname, overridingCBM_ALLOWED_ROOTon the command so the path is permitted.cli index_status --project shortname→ reports not indexed.ls $CBM_CACHE_DIR→ the db is named after the slugified absolute path.
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 Jul 28, 2026
Thanks for the precise allowed-root reproduction and for calling out the sticky-name behavior.
I checked current main at 0802689. handle_index_repository reads name before the root check (src/mcp/mcp.c:7575-7606), preserves it in the supervised request, and applies it to the pipeline at src/mcp/mcp.c:7714-7725. There is also supervised-name regression coverage from 6908ea5, but that test uses a virgin cache and does not cover the existing path-derived database plus changed allowed-root sequence reported here.
That leaves a real uncovered state transition rather than a generic “name is unsupported” case. I have routed this to 0.9.1-rc at priority/high. The delete/re-index persistence detail is especially useful; thank you.
DeusData commentedon Sep 26, 2026
Thank you for the precise allowed-root sequence, including the way the path-derived name kept coming back!
We re-ran it on current main. A repo first indexed under its path-derived name and then re-indexed with
--name orkestracomes out asorkestraevery time. That held inside and outside a narrowerCBM_ALLOWED_ROOTand afterdelete_project, andindex_status --project orkestrafinds it.Could you confirm on v0.11.0? If you still get the path-derived name, please send the exact commands, your
CBM_ALLOWED_ROOTvalues and the resulting cache listing.github-actions commentedon Sep 26, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.DeusData commentedon Oct 19, 2026
Thank you again for the allowed-root/name sequence. The last response reported the maintainer retest and asked whether your v0.11.0 run still returns the derived name. That environment-specific confirmation is still outstanding; I have no new outcome to add.
DeusData commentedon Oct 25, 2026
Thank you again for the naming sequence. Could you confirm whether the requested newer-version run still returns the derived name? If it does, the exact commands and allowed-root values will distinguish your case.