Summary

openclaw memory index --verbose fails with Unknown memory embedding provider: local even when local embeddings are configured correctly, node-llama-cpp is installed, and the running gateway reports memory vector support as ready.

There also appears to be a separate native stability problem in the local node-llama-cpp / Metal path (GGML_ASSERT([rsets->data count] == 0) failed).

Environment

• OpenClaw 2026.4.22
• macOS 26.2 arm64
• Node 25.9.0
• node-llama-cpp@3.18.1 installed globally and deduped under OpenClaw

Config

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "provider": "local",
        "fallback": "none",
        "local": {
          "modelPath": "hf:ggml-org/embeddinggemma-300m-qat-q8_0-GGUF/embeddinggemma-300m-qat-Q8_0.gguf"
        }
      }
    }
  },
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true
          }
        }
      }
    }
  }
}

Repro

openclaw memory index --verbose

Actual output

Memory Index (main)
Provider: local (requested: local)
Model: local
Sources: memory (MEMORY.md + ~/.openclaw/workspace/memory/*.md)

Memory index failed (main): Unknown memory embedding provider: local

Additional evidence

• openclaw status --deep reports memory as vector ready · fts ready
• node-llama-cpp is installed and visible in npm
• ~/.openclaw/logs/gateway.err.log also contains a separate native crash:

GGML_ASSERT([rsets->data count] == 0) failed
/Users/runner/work/node-llama-cpp/node-llama-cpp/llama/llama.cpp/ggml/src/ggml-metal/ggml-metal-device.m:612

Likely diagnosis

There appear to be two distinct issues:

1. CLI provider registration gap

   • The standalone openclaw memory index CLI path appears not to register the built-in local memory embedding adapter before lookup.
   • The gateway process likely has the provider registered, which explains why status --deep can show memory/vector support as ready while the CLI index path fails with Unknown memory embedding provider: local.

2. Separate Metal/native instability

   • Once local embeddings actually run, node-llama-cpp / llama.cpp on Metal can still crash with GGML_ASSERT([rsets->data count] == 0).

Question

Why does the standalone CLI memory-index path not see/register the built-in local embedding provider while the running gateway path does?

Workaround

As a temporary workaround, disabling Metal (GGML_METAL_DISABLE=1) appears to be the safest direction for local embeddings until both the registration bug and the native crash are resolved.