index_repository by project name fails with 'repo_path is required' but reports 'crashed on a file'

[asemraza]

Version: 0.9.0, macOS (Darwin 25.5, arm64)

Repro:

1. Have an already-indexed project (indexed originally by path).
2. Call the MCP tool index_repository with only the project name: {"project": "<name>"} (or equivalently cli index_repository '{"project": "<name>"}').
3. Result: {"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file..."}

Actual cause (from the worker log referenced by index.supervisor.worker_failed):

repo_path is required
level=info msg=index.worker.fast_exit action=_Exit

The worker exits because it never receives repo_path when the call is made by project name - no file crash is involved.

Two issues:

1. Re-indexing an existing project by name does not resolve the stored repo path before spawning the worker (list_projects clearly knows the root_path, so resolution data exists).
2. The supervisor's generic hint ("crashed on a file... a future release isolates the culprit file") is misleading for this failure class - surfacing the worker's actual stderr line would have saved the debugging detour.

Workaround: call with the explicit path: cli index_repository --repo-path /path/to/repo - works perfectly (and the built-in exclusion list in 0.9.0 is excellent, thanks for .claude/.codex).

Great tool otherwise - we run it across a multi-repo Laravel/TS setup shared between Claude Code and Codex.

[DeusData]

Thanks for including the actual worker error. This is a 0.9.1-rc integration/diagnostic bug under #395. Re-indexing an existing named project should resolve its stored root before the worker is spawned; invalid invocation must return the specific argument error rather than the generic file-crash hint.

[xantorres]

Another instance of the same misleading-message family, different root cause.

When CBM_ALLOWED_ROOT refuses a path, the CLI reports:

{"status":"error","outcome":"exit_nonzero",
 "hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file.",
 "repo_path":"/etc"}

Nothing crashed. The worker log has the real reason:

repo_path is outside the allowed root
level=info msg=index.worker.fast_exit action=_Exit

The sandbox is behaving correctly — the reporting is what's wrong. A clean, intentional policy refusal is surfaced as a crash with a "re-run to retry" hint, and retrying can never succeed. During an evaluation this cost me a real misdiagnosis: I spent time hunting a nonexistent parser crash before finding ~/.cache/codebase-memory-mcp/logs/.worker-*.log.

Suggestion: propagate the worker's exit reason into the CLI/MCP response, and reserve the "crashed on a file" hint for actual worker faults. A refusal should be status:"error" with hint:"repo_path is outside CBM_ALLOWED_ROOT" and no retry advice.

Version 0.9.0, darwin-arm64, macOS 25.5.0, standard variant, GitHub release archive.

[AmirF194]

Heads up: my PR #1258 above only fixes the original repo_path-required/name-resolution bug this issue was filed for, it doesn't touch the CBM_ALLOWED_ROOT misreport @xantorres found. I changed the PR body to Refs instead of Fixes so merging it won't auto-close this thread out from under that report.

[DeusData]

Thanks @xantorres for isolating the second cause, and @AmirF194 for correcting the PR linkage rather than allowing an incomplete auto-close.

Current main validates repo_path and CBM_ALLOWED_ROOT in handle_index_repository (src/mcp/mcp.c:7575-7606), but once the worker exits nonzero, build_worker_failure_response selects a generic outcome hint (mcp.c:7057-7084) instead of carrying the worker's specific argument/policy error. That confirms the allowed-root refusal is a separate response-propagation bug from project-name resolution.

Keeping this issue open until both halves are covered. PR #1258 is queued only for the original name-to-root resolution half; it must not close the policy-error reporting gap. Thank you both for keeping the boundary precise.