index_repository name override can silently clobber a different project's index

[phaedrus1992]

Summary

index_repository's name parameter overrides the derived project key, but
nothing checks whether that name is already bound to a different repo
root. Calling index_repository(repo_path: <some-repo>, name: "<existing-project>")
silently deletes and recreates <existing-project>'s index with data from
the wrong repo — no error, no prompt.

Details

cbm_validate_project_name (src/foundation/str_util.c) only checks the
name for path-traversal characters — it doesn't look up whether the name is
already registered to a different repo_path. handle_index_repository
(src/mcp/mcp.c) calls cbm_pipeline_set_project_name(p, name_override),
and the resulting pipeline unlinks and recreates the .db file at
<CBM_CACHE_DIR>/<name>.db (src/pipeline/pipeline.c) regardless of
whether that file already belongs to an unrelated project.

Any MCP client that shares one CBM_CACHE_DIR across multiple projects (a
reasonable, even encouraged, setup for a single cache directory) is exposed:
a name typo, or a client-side auto-fill that guesses the wrong project
name, replaces someone else's index with no confirmation.

Mitigating factor: an index is derived data, so the fix is "re-index the
correct repo" rather than data loss — but a full reindex runs
capture_existing_adr before unlinking, so at least the ADR document itself
survives the collision.

Suggested fix

index_repository should refuse a name override that already resolves to
an existing project whose recorded repo_path differs from the one supplied
in the call — return an error (e.g. "name '' is already bound to
; use --force to override" or similar) instead of silently
overwriting. This keeps the common case (first-time indexing, or re-indexing
the same repo under the same name) unprompted, while catching the
cross-project collision.

Found via

Downstream client integration (llmenv) — see llmenv issue
phaedrus1992/llmenv#1331 for the client-side
analysis that surfaced this.

[DeusData]

@phaedrus1992, thank you for tracing this through the full mutation path. Confirmed against current main.

cbm_validate_project_name() checks only traversal, separators, and filename safety. cbm_pipeline_set_project_name() then replaces the derived key without consulting an existing store. The DB path is constructed directly as <cache>/<project_name>.db, and handle_index_repository() explicitly closes the cached store before the pipeline recreates that path. There is no check that an existing project's recorded repository root matches the requested repo_path.

So the collision is real and fail-open today. I have labeled this a priority/high bug because a typo can silently replace another project's derived index and make subsequent graph answers refer to the wrong repository. No further reporter information is needed. The smallest safe contract is a deterministic cross-root collision test and a refusal before any existing DB is mutated. Thank you for catching it through the downstream integration.