Local Memory Embedding Issue

[tepid scarab]

Hey @elfin nymph Windows 11 user, Node 24.13.1, RTX 4080, just upgraded from 2026.4.23 to 2026.4.25.

On 4.23, memorySearch.provider: "local" was crashing with Error: Unknown memory embedding provider: local — the local provider string didn't exist in getAdapter(). Worked around it by switching to provider: "none" and waiting for the Windows/Jiti ESM fix to ship (which it did in 4.25 via #71749, thanks).

Setup details:

• Model file: embeddinggemma-300m-qat-Q8_0.gguf (320MB) at the configured models path
• node-llama-cpp installed globally via npm
• Previously had CUDA issues with the embedding model initializing on every bootstrap — resolved that by setting gpuLayers: 0 to force CPU, but then hit the provider string crash before that fix could even be tested
• Running self-hosted single-user gateway via Telegram, memory-core plugin enabled, dreaming active

Now on 4.25 — does provider: "local" actually work on Windows now, or is there a separate fix still pending? About to test openclaw memory status but wanted to check if there's a known state before I dig in.

[elfin nymph]

Short version: yes, provider: "local" should be real in 2026.4.25. In the 4.25 source, memory-core declares memoryEmbeddingProviders: ["local"], and the built-in adapter is id: "local" with transport: "local". So if you still get Unknown memory embedding provider: local, I’d treat that as registry/plugin loading still broken, not “local is unsupported.” (raw.githubusercontent.com)

The #71749 fix did land in 4.25: release notes say Windows bundled-plugin Jiti loaders were kept off the native import path to avoid ERR_UNSUPPORTED_ESM_URL_SCHEME on C:\... paths. That should remove the Windows/Jiti blocker you were waiting on. (api.github.com)

Things that can still fail after that:

• node-llama-cpp missing / wrong prefix / failed native build. 4.25’s local setup error expects node-llama-cpp@3.18.1 installed next to OpenClaw, and recommends Node 24. (raw.githubusercontent.com)
• local auto-select only happens when memorySearch.local.modelPath points at an existing local file. Explicit provider: "local" is fine, but your model path still has to resolve correctly. (docs.openclaw.ai)
• GPU/CUDA init can still be a separate node-llama-cpp/model-load issue, so keeping gpuLayers: 0 is sensible for this test.

I’d test in this order:

openclaw --version
openclaw memory status --deep --agent main
openclaw memory index --force --agent main