Repository navigation
cursor | vscode : persistence= true is silently ignored on first artifact creation #434
Description
persistence: true is silently ignored on first artifact creation
Summary
index_repository(persistence=true) only writes .codebase-memory/graph.db.zst when an artifact already exists beside the repo. After the local cache ~/.cache/codebase-memory-mcp/<project>.db is populated by an earlier call, every subsequent index_repository runs through the incremental pipeline, which silently ignores the persistence flag. As a result, a repo that has never been persisted before never gets its first artifact — even though the user explicitly asked for one.
The MCP response also gives no hint that the flag was a no-op:
- Returns
"status":"indexed"(no error) - Returns
"artifact_present":false(truthful, but easily misread as "indexing went fine, just no artifact yet") - Omits the usual
artifact_hint: "Persistent artifact written to .codebase-memory/graph.db.zst..."field
Reproduction
# Clean slate
rm -rf ~/.cache/codebase-memory-mcp
rm -rf /path/to/repo/.codebase-memory
# Call 1 — full pipeline runs (persistence:false here for clarity)
index_repository(repo_path="/path/to/repo", mode="full", persistence=false)
# → ~/.cache/codebase-memory-mcp/<project>.db is created
# → no artifact (correct, persistence wasn't requested)
# Call 2 — incremental pipeline runs (BUG: persistence:true ignored)
index_repository(repo_path="/path/to/repo", mode="full", persistence=true)
# Response:
# "status":"indexed", "artifact_present":false ← no artifact_hint
# Disk:
# /path/to/repo/.codebase-memory/ ← still does not existExpected: .codebase-memory/graph.db.zst is written because persistence=true was passed.
Actual: the flag is dropped on the floor; no artifact is created.
Real-world impact
I hit this while indexing 6 sibling repos in one chat session. First call per repo had persistence=false (default). On the follow-up "let's persist them all" pass with persistence=true, only the one repo that already had an artifact from a previous session got refreshed; the other 5 silently produced nothing. The only workaround I found was delete_project followed by index_repository(persistence=true) per repo — which forces the full pipeline and works correctly.
Root cause
src/pipeline/pipeline_incremental.c::dump_and_persist():
/* Auto-update artifact if one already exists (persistence was enabled previously) */
if (repo_path && cbm_artifact_exists(repo_path)) {
cbm_artifact_export(db_path, repo_path, project, CBM_ARTIFACT_FAST);
}The function does not take a persistence parameter and the caller (cbm_pipeline_run_incremental, line ~657) doesn't pass one. So the incremental path can only refresh an artifact that already exists — it can never create the first one.
The full-pipeline path in src/pipeline/pipeline.c::dump_and_persist_hashes() does honor it:
/* Export persistent artifact if enabled */
if (p->persistence) {
cbm_artifact_export(db_path, p->repo_path, p->project_name, CBM_ARTIFACT_BEST);
}This asymmetry between the full and incremental paths is the bug.
Activity
[-]persistence: true is silently ignored on first artifact creation[/-][+]cursor | vscode : persistence= true is silently ignored on first artifact creation[/+]DeusData commentedon Jun 10, 2026
Hey, thanks for reporting, will take a look once my current batch is through
test(repro): more install/UX + persistence reproductions for #607, #403…
DeusData commentedon Jun 28, 2026
This issue now has a first-class, durable reproduction in the cumulative bug-reproduction suite landing in #667 — a test that pins the exact failing behaviour, so it's tracked and guarded against silent regression. Where #667 also lands the root-cause fix, that's called out in the PR; otherwise the reproduction makes the eventual fix straightforward and verifiable.
The reproduction goes live once #667 merges. (Posted from the release branch's QA pass.)
c4shdev commentedon Jul 17, 2026
Same bug on macOS Intel, no editor involved this time (plain CLI):
Env
standardvariant, installed viacurl | shupdate --standard -yconfirms it's already latest (0.9.0)Repro
(also tried
--persistence 1and--persistence yes, same result)Result: JSON response says
"status":"indexed","artifact_present":false, and.codebase-memory/only has the auto-generated.gitattributesstub. No errors in stderr, justmem.initandindex.supervisor.reap outcome=clean.Expected: should produce
graph.db.zst+artifact.json(~990KB), like it did on another repo of mine indexed ~2 weeks ago, before this regression showed up.Not sure if it's relevant, but project is PHP 8.4 + vanilla ES modules, ~120 files, 1301 nodes / 3240 edges in full mode — doesn't seem like a scale issue.
DeusData commentedon Jul 18, 2026
Thanks for confirming the same persistence failure on a clean macOS CLI path. PR #1163 now carries the focused RED cases for both changed-file and no-op incremental runs and a candidate fix that creates the first requested artifact instead of reporting success with
artifact_present:false. The issue remains open until that exact fix is reviewed and lands.DeusData commentedon Aug 21, 2026
Thank you for the precise two-call reproduction, and thanks as well for the independent macOS confirmation.
Current main now runs the artifact-export policy at the outer staged-publish boundary after every successful pipeline result, including an unchanged incremental no-op. I verified the exact reported transition twice: first index with persistence disabled, then repeat the unchanged repository with persistence enabled. Both runs created the first persistent artifact as expected.
I am closing this as fixed. If a current build still returns success without creating the artifact for that sequence, please reopen with the version and platform and we will investigate further.