Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix sqlite-vec unavailable on Windows — vector embeddings not generated (v4.11+) [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#68892•Fetched 2026-04-19 15:06:34
View on GitHub
Comments
1
Participants
1
Timeline
1
Reactions
0
Author
jujitaojujitao
Participants
jujitaojujitao
Timeline (top)
commented ×1

Fix Action

Fixed

PR fix notes

PR #69059: fix: retry sqlite-vec load without .dll suffix on Windows

Description (problem / solution / changelog)

Summary

Fixes #68892.

On Windows, node:sqlite's DatabaseSync.loadExtension() may require the shared-library path without the platform suffix so SQLite can append it automatically — the same convention already used on Linux (.so) and macOS (.dylib). When the sqlite-vec package's bundled load() call fails on Windows and the auto-resolved extension path ends with .dll, the loader now retries by stripping the suffix before calling db.loadExtension() directly.

Root cause

sqlite-vec.load(db) resolves the bundled vec0.dll path via getLoadablePath() and passes it to db.loadExtension(). On some Windows Node.js builds, loadExtension('path/to/vec0.dll') fails because SQLite tries to open vec0.dll as-is; passing 'path/to/vec0' (no suffix) allows SQLite to append .dll itself, matching its normal extension-loading convention.

Change

// Before — no fallback when sqliteVec.load(db) fails on Windows
sqliteVec.load(params.db);

// After — retry without .dll suffix on Windows if the first attempt fails
try {
  sqliteVec.load(params.db);
} catch (firstErr) {
  if (process.platform === "win32" && extensionPath.toLowerCase().endsWith(".dll")) {
    params.db.loadExtension(extensionPath.slice(0, -4));
  } else {
    throw firstErr;
  }
}

Applied to both src/memory-host-sdk/host/sqlite-vec.ts and packages/memory-host-sdk/src/host/sqlite-vec.ts.

User-supplied extensionPath overrides are passed through unchanged — callers who already pin a working path are unaffected.

Test plan

  • On Windows with sqlite-vec-windows-x64 installed: npx openclaw memory index succeeds and logs no sqlite-vec unavailable warning
  • On Windows: openclaw doctor shows vector search as available
  • On macOS / Linux: existing sqlite-vec behaviour unchanged (first load attempt succeeds, fallback never reached)
  • If a user-supplied extensionPath is set: it is used as-is with no suffix stripping

Made with Cursor

Changed files

  • packages/memory-host-sdk/src/host/sqlite-vec.ts (modified, +31/-2)
  • src/memory-host-sdk/host/sqlite-vec.ts (modified, +31/-2)
RAW_BUFFERClick to expand / collapse

Problem

On Windows, memory-core plugin fails to load sqlite-vec extension, causing vector embeddings to not be generated. All memory writes show:

[memory] chunks written for ... without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.

Environment

  • OpenClaw: 2026.4.15
  • OS: Windows (Windows_NT 10.0.26200)
  • Node.js: v22.22.2
  • sqlite-vec: installed at ode_modules/sqlite-vec-windows-x64/vec0.dll
  • Ollama: installed and running with mxbai-embed-large model available

Expected behavior

sqlite-vec extension should be loaded successfully, enabling vector embedding generation for semantic memory search.

Actual behavior

  • sqlite-vec-windows-x64 is installed (vec0.dll exists)
  • Ollama with mxbai-embed-large is installed and responding
  • But memory-core cannot load the sqlite-vec extension
  • All memory writes fall back to FTS (keyword search only)

Diagnosis

The plugin SDK exports openMemoryDatabaseAtPath(dbPath, allowExtension) which accepts an llowExtension parameter, but this is not exposed in the user configuration. The memory-core plugin appears to call this without the extension loading flag, or the Windows path resolution for vec0.dll fails.

What I tried

  1. Ollama installed + mxbai-embed-large model pulled — working (verified via curl to localhost:11434)
  2. sqlite-vec-windows-x64 package installed via npm — vec0.dll present
  3. Config schema lookup shows no user-facing memorysearch or llowExtension configuration path

px openclaw memory index still fails with sqlite-vec unavailable

Feature Request

Either:

  1. Expose llowExtension: true in memory-core config so users can enable it
  2. Or ensure sqlite-vec loads automatically when the extension file is present
  3. Or document the proper way to enable vector embeddings on Windows

Impact

  • Vector recall degraded (semantic search broken)
  • Dream/REM features may be impacted
  • Users on Windows cannot use full memory capabilities even with Ollama installed

extent analysis

TL;DR

The memory-core plugin fails to load the sqlite-vec extension on Windows, causing degraded vector recall, and a potential solution involves exposing the allowExtension parameter in the user configuration or ensuring sqlite-vec loads automatically.

Guidance

  • Verify that the vec0.dll file is correctly installed and accessible in the node_modules/sqlite-vec-windows-x64 directory.
  • Check the plugin SDK documentation to see if there are any specific requirements or configurations needed for loading extensions on Windows.
  • Consider modifying the memory-core plugin to expose the allowExtension parameter in the user configuration, allowing users to enable the sqlite-vec extension manually.
  • Test the Ollama installation and mxbai-embed-large model separately to ensure they are working correctly and responding as expected.

Example

No code snippet is provided as the issue does not imply a specific code change, but rather a configuration or exposure of an existing parameter.

Notes

The issue seems to be specific to the Windows environment and the memory-core plugin's interaction with the sqlite-vec extension. The solution may involve changes to the plugin or its configuration, rather than a straightforward code fix.

Recommendation

Apply a workaround by modifying the memory-core plugin to expose the allowExtension parameter, allowing users to enable the sqlite-vec extension manually, as this seems to be the most direct way to address the issue without waiting for a potential fix in a future version.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

sqlite-vec extension should be loaded successfully, enabling vector embedding generation for semantic memory search.

#embedding generation#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix sqlite-vec unavailable on Windows — vector embeddings not generated (v4.11+) [1 pull requests, 1 comments, 1 participants]