name parameter on index_repository is parsed but has no effect via cli mode

[mentallabyrinth]

Version

codebase-memory-mcp 0.8.1

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

index_repository accepts a name argument, and handle_index_repository clearly parses and applies it (cbm_mcp_get_string_arg(args, "name") --> cbm_pipeline_set_project_name(p, name_override), called before project_name is read back from the pipeline). However, when invoked through codebase-memory-mcp cli index_repository, passing name has no observable effect. The response's project field is always the path-derived name, never the requested one, and no error is returned.

This may be the same class of bug described in the https://github.com/DeusData/codebase-memory-mcp/releases#release-0.6.0 ("6 previously-ignored params wired up: min_degree, max_degree, exclude_entry_points, include_connected, aspects filter, since for detect_changes") -- i.e. an argument that's parsed by the handler but not actually forwarded/applied somewhere in the call path, possibly specific to cli mode rather than live MCP JSON-RPC sessions (guessing).

Reproduction

codebase-memory-mcp cli index_repository '{"repo_path": "/absolute/path/to/some/repo", "name": "my-custom-name"}'

Response: { "architecture": { "project": "my-custom-name", ... }}

Actual result

Response: { "architecture": { "project": "absolute-path-to-some-repo", ... }}

Logs

Diagnostics trajectory (memory / performance / leak issues)

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]

Thanks for the focused CLI repro. Triage: UX/API contract bug.

If index_repository accepts name, CLI mode should either honor it consistently with MCP mode or reject it clearly. Silent no-op parameters are exactly the kind of thing that makes project identity hard to reason about, so the fix should add a CLI regression for repo_path + name and verify the response/store identity matches the requested behavior.