Problem
When plugins.slots.memory is switched from OpenClaw's default memory-core to memory-lancedb-pro, some agents/surfaces lose direct access to the expected memory tools even though the plugin is globally enabled and loaded.
In practice:
memory-lancedb-pro is loaded successfully- memory injection / recall / smart extraction still work
- but some tool profiles (notably
coding) still expect the default OpenClaw memory tool names:
Current memory-lancedb-pro tool names are:
memory_recallmemory_storememory_forgetmemory_updatememory_statsmemory_list
This creates a compatibility gap:
- the plugin is active,
- but some agents do not see usable direct memory tools,
- and gateway logs emit warnings about unknown allowlist entries like
memory_search / memory_get.
Why this matters
This weakens the adoption story for memory-lancedb-pro as a drop-in / low-friction replacement for the default memory layer.
If switching the active memory plugin causes existing profiles and agent workflows to lose their expected memory tool names, then the plugin is harder to adopt safely in real deployments.
This is especially relevant when the goal is non-destructive / reversible adoption.
Short-term PR goal
Add compatibility aliases inside memory-lancedb-pro so older/default OpenClaw expectations continue to work:
memory_search -> alias to memory_recallmemory_get -> alias to a compatible read / retrieval path (or a best-effort compatibility shim)
The short-term objective is not to redesign the whole memory tool surface. It is simply to make plugin activation less disruptive for existing OpenClaw tool profiles and agents.
Benefits
- reduces breakage when switching from
memory-core to memory-lancedb-pro
- makes existing
coding profile expectations less brittle
- improves backward compatibility for older sessions / prompts / allowlists
- supports the broader goal of non-destructive plugin adoption
Longer-term follow-up (optional)
A separate follow-up could clarify the preferred canonical tool names and update OpenClaw-side profiles accordingly. But the short-term fix should prioritize compatibility.
Problem
When
plugins.slots.memoryis switched from OpenClaw's defaultmemory-coretomemory-lancedb-pro, some agents/surfaces lose direct access to the expected memory tools even though the plugin is globally enabled and loaded.In practice:
memory-lancedb-prois loaded successfullycoding) still expect the default OpenClaw memory tool names:memory_searchmemory_getCurrent
memory-lancedb-protool names are:memory_recallmemory_storememory_forgetmemory_updatememory_statsmemory_listThis creates a compatibility gap:
memory_search/memory_get.Why this matters
This weakens the adoption story for
memory-lancedb-proas a drop-in / low-friction replacement for the default memory layer.If switching the active memory plugin causes existing profiles and agent workflows to lose their expected memory tool names, then the plugin is harder to adopt safely in real deployments.
This is especially relevant when the goal is non-destructive / reversible adoption.
Short-term PR goal
Add compatibility aliases inside
memory-lancedb-proso older/default OpenClaw expectations continue to work:memory_search-> alias tomemory_recallmemory_get-> alias to a compatible read / retrieval path (or a best-effort compatibility shim)The short-term objective is not to redesign the whole memory tool surface. It is simply to make plugin activation less disruptive for existing OpenClaw tool profiles and agents.
Benefits
memory-coretomemory-lancedb-procodingprofile expectations less brittleLonger-term follow-up (optional)
A separate follow-up could clarify the preferred canonical tool names and update OpenClaw-side profiles accordingly. But the short-term fix should prioritize compatibility.