Repository navigation
v0.9.0: persistence:true never creates the artifact for newly indexed projects (existing projects keep updating) #1502
Description
Summary
On v0.9.0 (macOS arm64), index_repository with "persistence": true never writes .codebase-memory/graph.db.zst / artifact.json for a project indexed for the first time. Projects whose artifact was established under an earlier release continue to update normally — this looks like a create-vs-update regression in the persistence path.
Environment
- codebase-memory-mcp 0.9.0, macOS 15 (Darwin 25.6.0), arm64
- Single-user setup; same binary serves several MCP clients against the shared
~/.cache/codebase-memory-mcp/store
Reproduction
Fresh repo (never indexed before), then:
- MCP tool call:
index_repository { repo_path: "<abs path>", mode: "full", persistence: true }→ response"status": "indexed", "artifact_present": false; no files written to.codebase-memory/(the.gitattributesthe tool normally pairs with the artifact is there from an earlier run, but nograph.db.zst, noartifact.json). - Second identical run (project now registered, incremental path) → same result.
- CLI worker path:
codebase-memory-mcp cli index_repository --repo-path <abs path> --mode full --persistence true→ same result.
All three runs report "artifact_present": false while index_status shows the project ready with the expected node/edge counts. Tried on two different repos (~1.4k and ~1.7k nodes) — identical behavior.
Evidence it's create-vs-update
- A large project whose artifact was first written under an earlier release keeps refreshing normally on 0.9.0 —
artifact.json'sindexed_at/commitadvance on every incremental run. - That existing project's artifact is even refreshed as a side effect of indexing a different project in the same server session — so the persistence machinery itself is alive; the per-call
persistence: truejust never establishes the persisted state for a new project. - Hand-seeding a plausible
artifact.json(schema_version 2) into the new project's.codebase-memory/does not induce the update path either — it is left untouched, suggesting the persisted flag lives in server-side registry state that the call argument fails to set.
Expected
persistence: true on a first index writes the compressed artifact (as documented: "Write compressed artifact to .codebase-memory/graph.db.zst for team sharing").
Actual
Artifact is only ever written for projects that were already persisted before 0.9.0; new projects can never opt in.
Happy to provide logs or run a debug build against a scratch repo if useful.
Activity
adfjadfj16-a11y commentedon Aug 9, 2026
AmirF194 commentedon Aug 9, 2026
Tested this on Linux x86_64, since the two reports so far are macOS arm64 (original) and Linux main (@lukiod). Built
v0.9.0itself (tagb637e333, not main) viamake -f Makefile.cbm cbmin a cleangcc:12Docker container, then ran the exact CLI repro from the report against a fresh, never-indexed repo:Result:
"artifact_present": true, and.codebase-memory/getsgraph.db.zst+artifact.json, first run. A second run after editing a file (the incremental path) also persisted correctly.So the bug does not reproduce on
v0.9.0on Linux. That's evidence against the "same release gap as #1507" theory: a source-level gap betweenv0.9.0and main would reproduce on any platform runningv0.9.0, not just macOS arm64. Since it's clean here, whatever is happening in the original report looks more likely to be macOS/arm64-specific, or tied to something in that environment #1507 doesn't cover (the shared~/.cache/codebase-memory-mcp/store serving multiple concurrent MCP clients, mentioned in the original report).I don't have macOS arm64 hardware to test directly, so this doesn't confirm or rule out the original report, just narrows where the difference is likely to be.
github-actions commentedon Aug 10, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.DeusData commentedon Aug 10, 2026
Thank you for the report and for the additional platform checks. The evidence is currently mixed between the original macOS reproduction and successful Linux/current-main runs. Since
v0.10.0is now available, could the original reporter retest on macOS with a fresh temporaryCBM_CACHE_DIRand shareindex_statusplus whether the persistence artifact is created? I have marked this awaiting reporter and kept it high priority in the immediate bug train.github-actions commentedon Sep 1, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.DeusData commentedon Sep 3, 2026
Maintainer notice: please disregard comments from @adfjadfj16-a11y on this thread
@adfjadfj16-a11y is not a maintainer of this project and does not speak for it. That account has posted replies on 17 threads here written in the project's voice — promising merges, announcing that a case has been "escalated to the development team", asking to close issues, and in some threads replying as though it were the author of someone else's pull request. None of those were maintainer decisions, and none of them carried any weight.
@DeusData is the only account that gives a maintainer response on this repository. If a comment about the fate of your issue or pull request did not come from @DeusData, it is not a decision, however official it reads.
If you were waiting on something because of one of those comments — a promised merge, a review "immediately", a request to close your ticket — I am sorry. That was noise you had no way to identify as noise, and it should not have been on your thread. Your issue or PR is judged on its own merits, and I will answer it here myself.
Nothing in this notice reflects on your contribution. Thank you for your patience, and thank you for the work.
github-actions commentedon Sep 26, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.DeusData commentedon Oct 19, 2026
Thank you again for the macOS report and the independent Linux checks. The open question is still whether a fresh temporary cache on the original macOS environment creates the persistence artifact on the version requested above. The Linux successes do not settle that case; no additional information beyond that retest is requested here.
DeusData commentedon Oct 25, 2026
Thank you again for the macOS report. The fresh temporary-cache retest in the original environment remains the missing evidence; successful Linux checks do not establish the macOS outcome.