openclaw - 💡(How to fix) Fix memory-lancedb memory_store is registered but not exposed as callable agent tool [1 comments, 2 participants]

Summary

@openclaw/memory-lancedb declares and registers memory_store, memory_recall, and memory_forget, but the Codex/OpenClaw agent dynamic tool surface does not expose them. A real agent turn cannot call memory_store; the model sees no such tool, and no LanceDB write occurs.

Environment

• OpenClaw: 2026.5.18
• memory-lancedb: 2026.5.18-beta.1
• Agent model/runtime: openai-codex/gpt-5.5 via Codex app-server bridge
• memory slot: memory-lancedb
• dbPath: /home/openclawops/.openclaw/memory/lancedb-option-b-v2
• embedding: ollama / nomic-embed-text / 768 dimensions

Evidence

Plugin manifest declares:

"contracts": {
  "tools": ["memory_forget", "memory_recall", "memory_store"]
}

Plugin runtime source calls:

api.registerTool({ name: "memory_store", ... }, { name: "memory_store" })

A real agent turn asking to use memory_store produced:

NO_MEMORY_STORE_TOOL_EXPOSED

The corresponding Codex app-server dynamic tool fingerprint did not contain memory_store, memory_recall, or memory_forget.

Direct LanceDB insert/delete using the same live dbPath and embedding endpoint succeeds, so this is not a storage schema/write failure.

Expected

If a plugin declares and registers memory_store, an eligible agent/runtime surface should materialize it as a callable dynamic tool, or produce a clear policy/allowlist diagnostic explaining why it was excluded.

Actual

The tool is absent from the dynamic tool list. The agent cannot call it. No storage call is made, and the memory table remains empty.

Related defect family

This appears related to the broader dynamic-tool/materialization family:

• #82977
• #78907
• #77800

It may also be adjacent to #84218 in the sense that both failures involve runtime surfaces not honoring the documented/expected substrate behavior. #84218 is heartbeat context replay rather than plugin tool exposure, so this issue should remain separate.

The closures/fixes around #82864 and #83312 in 5.19-beta.1 may or may not address this specific variant. We are testing 5.19-beta.1 separately against this exact memory_store exposure path.

Why this matters

Write-capable memory workflows cannot safely use the official memory_store path. Operators are forced either to bypass the runtime and write LanceDB directly or block memory intake.

Repro shape

1. Enable memory-lancedb in the memory slot with autoCapture and autoRecall.
2. Confirm the plugin manifest declares memory_store, memory_recall, and memory_forget.
3. Run a Codex/OpenClaw agent turn asking the agent to store a synthetic memory via memory_store.
4. Inspect the dynamic tool fingerprint / session trajectory.
5. Observe that memory_store is absent and no LanceDB row is written.

Diagnostic archive

Local report path on our deployment:

governance/research/memory-store-runtime-path-diagnosis-20260519T173305Z.md