index_repository --name is silently ignored when the repo sits outside the server's allowed root — project gets a path-derived name

[xantorres]

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

Repos 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

1. Set CBM_ALLOWED_ROOT to some directory A.
2. cli index_repository --repo-path <repo outside A> --name shortname, overriding CBM_ALLOWED_ROOT on the command so the path is permitted.
3. cli index_status --project shortname → reports not indexed.
4. 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.

[DeusData]

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.