openclaw - 💡(How to fix) Fix memory-core plugin runtime deps (chokidar, sqlite-vec, node-llama-cpp) get pruned by the auto-managed runtime-deps tree [1 comments, 2 participants]

Affected version

[email protected] (cli build da6bdffc3d96).

Summary

The bundled memory-core plugin uses chokidar (file watcher), sqlite-vec (vector index), and node-llama-cpp (local-provider embeddings). On every gateway boot, these are detected and installed into ~/.openclaw/plugin-runtime-deps/<build>/node_modules/ (visible in the gateway log as: staging bundled runtime deps before gateway startup (3 missing, 17 install specs): chokidar@^5.0.0, [email protected], sqlite-vec@^0.1.6). Within a few minutes of boot — long before the gateway has finished warm-up — they disappear from disk. Subsequent dynamic import("sqlite-vec") from engine-storage-…/dist/engine-storage-*.js fails with Cannot find package 'sqlite-vec' imported from …, surfaces in memory.err.log as [memory] sqlite-vec unavailable, and the manager logs chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. Memory search still returns results because the manager has a JS-side cosine fallback (searchChunksByEmbedding), but vector recall is degraded and brute-forced — performance falls off linearly as the corpus grows.

Root cause (suspected)

The plugin install pipeline at dist/bundled-runtime-root-*.js does the following per plugin:

1. Reads the plugin's package.json (dist/extensions/memory-core/package.json).
2. Computes dependencySpecs from those deps + alreadyStagedSpecs.
3. Computes installSpecs = retainSpecs ∪ retainedManifestSpecs(filtered) ∪ alreadyStagedSpecs ∪ dependencySpecs.
4. After install, calls pruneRetainedRuntimeDepsManifestSpecs(previousSpecs=retainedManifestSpecs, nextSpecs=installSpecs) — anything in previous but not in next gets removeRuntimeDepPackageDir'd.
5. Writes the new manifest.

When the lifecycle calls this once per plugin, and the boot processes plugins in some order, only the plugin currently being processed contributes its deps to dependencySpecs. alreadyStagedSpecs is supposed to keep already-staged deps from being pruned — but it relies on a sentinel file inside the install root, which the prune from a sibling plugin invocation can race against. The result is that memory-core's deps get installed during memory-core's pass and pruned during another plugin's pass, in the same boot cycle.

Steps to reproduce

1. Configure agents.defaults.memorySearch.provider: "ollama" and model: "nomic-embed-text".
2. Restart the gateway.
3. Watch ~/.openclaw/plugin-runtime-deps/<build>/node_modules/sqlite-vec come and go within a 2–4 minute window.
4. After it disappears, issue a memory_search call. Inspect ~/.openclaw/logs/gateway.err.log for sqlite-vec unavailable: Cannot find package 'sqlite-vec'.

Concretely on the affected machine:

2026-05-05T11:45:39 [gateway] staging bundled runtime deps … (3 missing, 17 install specs): chokidar@^5.0.0, [email protected], sqlite-vec@^0.1.6
2026-05-05T11:45:43 [gateway] installed bundled runtime deps … in 3249ms
2026-05-05T11:48:16 [memory] sqlite-vec unavailable: Cannot find package 'sqlite-vec' imported from …/dist/engine-storage-CO3qFXo7.js

Ten subsequent boots show the same pattern.

What we want

memory-core declares these deps in its own package.json dependencies. Either:

(a) Treat that declaration as authoritative — keep them retained across the entire boot cycle regardless of which plugin's install pass is running, OR

(b) Make provider: "ollama" (or any HTTP-only embedding provider) NOT require node-llama-cpp at all — that dep is only needed for provider: "local" and is ~200 MB of binary weight that everyone pays for.

(c) At minimum: surface the prune-after-install pattern as a visible gateway-startup error rather than only in memory.err.log. Today the gateway boots cleanly, the memory search appears to work (because of the JS-side fallback), and the user has no signal that vector indexing is degraded.

Workaround we're using

Patched dist/extensions/memory-core/package.json to declare sqlite-vec, node-llama-cpp, and chokidar as deps. This makes the dep show up in installSpecs on each boot and the gateway re-installs it, but the prune still wins after a few minutes. Net effect: the gateway holds these in memory after the first import (so live searches succeed), but any cold-import after the prune fails. CLI subcommands (openclaw memory status, openclaw memory search) cold-import and consequently always fail with ERR_MODULE_NOT_FOUND.

The patch will be wiped on every OpenClaw upgrade.

Related — openclaw memory <subcommand> CLI prunes its own runtime-deps tree at process-exit

Because the CLI subcommand spawns a fresh Node process, evaluates memory-core's deps, runs the install (or sees them as already-staged), then on exit calls cleanup that re-runs pruneRetainedRuntimeDepsManifestSpecs — but the manifest at that point has only the CLI's chosen specs, so anything not in the CLI's input gets pruned. Subsequent gateway-side imports then fail.

This makes openclaw memory status itself a footgun: every time a user runs it to debug memory-search behavior, it makes the situation worse.