Repository navigation
index_repository by project name fails with 'repo_path is required' but reports 'crashed on a file' #1211
Description
Version: 0.9.0, macOS (Darwin 25.5, arm64)
Repro:
- Have an already-indexed project (indexed originally by path).
- Call the MCP tool index_repository with only the project name:
{"project": "<name>"}(or equivalentlycli index_repository '{"project": "<name>"}'). - 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:
- 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).
- 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.
Activity
DeusData commentedon Jul 22, 2026
Thanks for including the actual worker error. This is a
0.9.1-rcintegration/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 commentedon Jul 28, 2026
Another instance of the same misleading-message family, different root cause.
When
CBM_ALLOWED_ROOTrefuses 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:
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"withhint:"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 commentedon Jul 28, 2026
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 commentedon Jul 28, 2026
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.
fix(mcp): resolve index_repository's repo_path from a known project name
DeusData commentedon Aug 4, 2026
Follow-up: the second half of this report — the supervisor replacing a validly delivered tool error with a generic "crashed on a file" diagnosis — is now fixed on main by #1369 (merged as 6a5f850, thanks @WarGloom): a supervised worker that writes a complete MCP response exits clean, so the parent surfaces the real error. Complements the project-name resolution fix from #1258 that closed this issue.