Summary
After upgrading to OpenClaw 2026.4.27, builtin memory/vector search can fail because the plugin runtime dependency snapshot under ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-*/node_modules does not contain sqlite-vec, even though the main global OpenClaw install does.
This breaks memory startup/search with:
[memory] sqlite-vec unavailable: Cannot find package 'sqlite-vec' imported from /Users/.../.openclaw/plugin-runtime-deps/openclaw-2026.4.27-.../dist/engine-storage-....js
Did you mean to import "sqlite-vec/index.cjs"?
Environment
- OpenClaw:
2026.4.27
- Host: macOS arm64
- Install path:
/opt/homebrew/lib/node_modules/openclaw
- Runtime deps path:
~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-*/
- Memory backend: builtin
What I observed
The main OpenClaw install contains:
/opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec
/opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64
But the generated plugin runtime deps snapshot for 2026.4.27 did not contain those packages under:
~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-*/node_modules
That caused builtin memory/vector search to fail until the missing packages were manually linked into the runtime-deps snapshot.
Repro
- Upgrade to
2026.4.27
- Use builtin memory with vector search enabled
- Run memory startup/status/search
- Observe runtime error above
- Check runtime deps dir and note that
sqlite-vec is missing there, while present in the main install
Expected
sqlite-vec should resolve correctly from the plugin runtime used by builtin memory on macOS arm64.
Actual
The runtime snapshot used by memory cannot import sqlite-vec and vector memory initialization/search fails.
Local workaround
I restored memory by manually linking the missing packages into the plugin runtime deps snapshot:
BASE="$HOME/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-da6bdffc3d96/node_modules"
mkdir -p "$BASE"
ln -s /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec "$BASE/sqlite-vec"
ln -s /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64 "$BASE/sqlite-vec-darwin-arm64"
After that, openclaw memory status reported vector search as ready again:
Vector: ready
Vector dims: 2560
Vector path: /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64/vec0.dylib
Extra note
In my case I also hit a separate local config/model-name mismatch at the same time (memorySearch.model still pointed at an old embedding model id while my embeddings server only exposed a new served model name), but that was independent of this sqlite-vec runtime packaging/resolution failure.
Summary
After upgrading to
OpenClaw 2026.4.27, builtin memory/vector search can fail because the plugin runtime dependency snapshot under~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-*/node_modulesdoes not containsqlite-vec, even though the main global OpenClaw install does.This breaks memory startup/search with:
Environment
2026.4.27/opt/homebrew/lib/node_modules/openclaw~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-*/What I observed
The main OpenClaw install contains:
/opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec/opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64But the generated plugin runtime deps snapshot for
2026.4.27did not contain those packages under:~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-*/node_modulesThat caused builtin memory/vector search to fail until the missing packages were manually linked into the runtime-deps snapshot.
Repro
2026.4.27sqlite-vecis missing there, while present in the main installExpected
sqlite-vecshould resolve correctly from the plugin runtime used by builtin memory on macOS arm64.Actual
The runtime snapshot used by memory cannot import
sqlite-vecand vector memory initialization/search fails.Local workaround
I restored memory by manually linking the missing packages into the plugin runtime deps snapshot:
After that,
openclaw memory statusreported vector search as ready again:Extra note
In my case I also hit a separate local config/model-name mismatch at the same time (
memorySearch.modelstill pointed at an old embedding model id while my embeddings server only exposed a new served model name), but that was independent of thissqlite-vecruntime packaging/resolution failure.