OpenClaw Isolates Curated Memory by Project Instead of Sharing Neighbouring Entries
A merged Memory Core change closes cross-project recall leakage in curated files, while a separate fallback keeps keyword recall available when embeddings cannot start.
OpenClaw has merged a Memory Core change that isolates curated MEMORY.md and USER.md entries by project. Before the fix, entries from different projects could be indexed in one shared chunk: a valid trigger could then inject a neighbouring entry belonging to another project, while the defensive all-project check could suppress memories that were actually valid.
This is a privacy and correctness boundary, not a cosmetic search improvement. Operators using one installation across clients, repositories or confidential workstreams should treat a containing release as a memory-isolation upgrade and test it with deliberately conflicting fixtures before trusting project recall.
A separate merged fix keeps memory usable when an embedding provider cannot start by degrading to keyword-only search and returning to semantic mode only after recovery is confirmed. The two changes belong together operationally: recall should remain available during provider failure without widening the project boundary.
The operator decision
| Deployment | Response |
|---|---|
| One personal project with no curated cross-project entries | Low immediate exposure, but verify the containing release before relying on the new behaviour |
| Several projects share one OpenClaw profile | Prioritize a containing build and run an explicit negative-recall test for every sensitive boundary |
| Client or regulated data is separated only by project annotations | Treat annotations as retrieval policy, not an access-control substitute; use separate profiles or stronger isolation where disclosure would be unacceptable |
| Embeddings are unavailable or intermittent | Expect keyword-only degraded mode on a containing build; confirm status and recovery rather than assuming semantic recall is active |
You build from main |
Pin an exact revision containing commits d41a56f and 5922dd4, then preserve that SHA in deployment evidence |
Both fixes merged after 2026.7.2-beta.5 was published. Their presence on main does not prove that beta.5—or any installed package—contains them.
What changed in curated memory
PR #115438 changes curated-file indexing and promotion rather than adding a late filter to an unchanged shared chunk. The merged record says the implementation now:
- chunks curated files per top-level entry;
- preserves project scope when an entry is promoted;
- limits recall to active projects while retaining valid global entries;
- excludes annotations from concept tags;
- preserves project-path casing; and
- tightens project-isolation checks around bootstrap and retrieval.
That placement matters. If two entries with different scopes are embedded as one retrievable unit, filtering after retrieval is too late: the returned text already contains both entries. Per-entry chunking makes the unit selected by retrieval match the unit carrying the scope.
Interpretation: project scope is now part of memory identity rather than merely a hint attached to a larger text block. That is the right model, but it still should not be mistaken for a complete tenant-security boundary.
Keyword fallback fails more usefully
PR #115397 addresses a different failure mode. When embeddings cannot initialize, Memory Core now falls back to keyword search, projects that degraded state into diagnostics, and keeps synchronization keyword-only until the embedding provider has genuinely recovered.
That avoids two bad outcomes: losing all recall because a semantic dependency is down, or claiming semantic readiness before the provider can actually serve it. It also means retrieval quality can change during an incident. Operators should monitor the reported mode and avoid comparing degraded keyword results with normal semantic recall as though they were equivalent.
Project filtering must survive both paths. An embedding outage should reduce ranking capability, not relax which project’s entries may be returned.
A safe acceptance test
Use synthetic entries, not production secrets:
- Create two projects with similar trigger phrases and unmistakably different harmless marker values.
- Add one global marker and one project-scoped marker to each curated file.
- From each project, query broad terms likely to match both projects and confirm only the global plus active-project markers appear.
- Repeat with path casing that matches the real deployment filesystem.
- Disable or misconfigure the test embedding provider so Memory Core enters keyword-only mode.
- Repeat the negative-recall checks while degraded.
- Restore the provider and confirm diagnostics report semantic readiness only after a successful recovery check.
- Restart the Gateway and repeat the test so promotion, indexing and persisted scope are covered.
Do not seed a test with real client names, credentials or private text. A negative test is useful only if its evidence can be retained safely.
Evidence and limits
OpenClaw Academy reviewed the official merged pull-request and commit records supplied by the OpenClaw repository collector. The upstream record describes additional boundary, casing, promotion and recovery tests, but we did not execute Memory Core against a multi-project production profile or independently reproduce the embedding outage.
The merged work is on main; no supplied release record establishes a packaged containing version. Project scoping improves retrieval isolation, but operators requiring hard separation should still use distinct profiles, storage and credentials rather than relying on recall filtering alone.
Bottom line
Shared memory must not turn “relevant to this project” into “adjacent to something relevant.” OpenClaw now chunks and scopes curated entries at the right boundary, while preserving keyword recall when embeddings fail.
If one profile spans sensitive projects, track a release containing PRs #115438 and #115397, test both semantic and degraded retrieval with cross-project decoys, and keep stronger isolation for data that must never cross a project boundary.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF