Read-only repository cannot be indexed on 0.10.5 (0.9.0 succeeds), and the error blames repo_path

[DeusData]

Version

0.10.5 (regression against 0.9.0)

Platform

Linux (arm64, container); path is platform-independent

What happens

Indexing a read-only repository with --persistence true fails outright on 0.10.5, where 0.9.0 completes. The error names the wrong cause and gives the user nothing to act on:

{"project":"…","status":"error","hint":"Pipeline failed. Check repo_path exists and contains source files. Try mode='fast' for a quicker diagnostic run."}

The repo path exists and is full of source files. CBM_LOG_LEVEL=debug adds no further detail, and no pipeline.err line reaches the user-visible output.

Reproduction

Identical mount, identical project directory, only the version differs:

docker run --rm -v /path/to/corpora:/corpus:ro -v /path/to/bins:/bins ubuntu:24.04 bash -c '
  for v in v090 v0105; do
    D=/tmp/$v; mkdir -p $D
    env HOME=$D CBM_CACHE_DIR=$D/.cache /bins/$v/codebase-memory-mcp cli index_repository \
      --repo-path /corpus/django --mode full --name ro-$v --persistence true
    echo "$v rc=$?"
  done'

Result:

	--persistence true	--persistence false
0.9.0	rc=0, "status":"indexed"	rc=0
0.10.5	rc=1, "status":"error"	rc=0

--persistence false succeeding on 0.10.5 isolates this to the artifact-export path (.codebase-memory/graph.db.zst is written inside the repo, which a read-only checkout cannot accept).

What I verified vs. inferred

Verified: the version difference, the --persistence split, and that a writable copy of the same tree indexes fine on 0.10.5 (rc=0, 55368 nodes).

Inferred, not yet proven: the failing-run policy itself is not new — v0.9.0's pipeline.c carries the same intent (/* A failed persistence export intentionally fails the run */ return arc;). What appears to differ is recovery: the 0.9.0 run logs a worker exiting non-zero followed by a retry that succeeds, whereas 0.10.5 stops. In a related capped-memory run 0.10.5 ended with daemon.index.recovery_unattributable action=stop. So the regression may live in supervisor recovery rather than in the artifact code. Worth confirming before fixing.

Why it matters

Read-only checkouts are ordinary: CI workspaces, read-only bind mounts, network shares, and any policy-hardened build agent. On 0.10.5 those cannot be indexed with persistence at all, and the message sends the user to check a path that is perfectly fine.

Suggested direction (for discussion)

1. Degrade rather than fail: the SQLite generation is already the commit point and is usable — a failed artifact export could be a warning plus "status":"indexed","artifact_present":false, keeping --persistence true meaningful where the repo is writable.
2. Failing that, name the real cause: report the export error and the unwritable path, not "check repo_path exists".
3. Either way, detect the unwritable repo before doing the full index, so the user is not told after the work is done.

Related: #1620 reports the same unactionable Pipeline failed text from a different underlying cause, which suggests the generic hint is swallowing distinct failures.