[Bug] Windows memory indexing falls back to FTS-only in 2026.4.14 even though direct node:sqlite + sqlite-vec works

Summary

On Windows, OpenClaw 2026.4.14 still degrades memory indexing to FTS-only with repeated sqlite-vec unavailable / chunks_vec not updated warnings.

This persists after:

• updating OpenClaw to 2026.4.14
• forcing a full memory reindex
• rebuilding the memory DB from scratch

A direct local node:sqlite + sqlite-vec test on the same machine succeeds, which suggests the problem is in OpenClaw's memory-core runtime path rather than the machine, Windows generally, or sqlite-vec generally.

Impact

• semantic memory recall is degraded to FTS-only behavior
• chunks_vec is never created on a fresh DB
• downstream features that depend on healthy vector-backed recall, including dreaming/synthesis workflows, remain blocked

Environment

• OS: Windows 11
• OpenClaw: 2026.4.14
• Node.js: v24.13.1
• sqlite-vec path observed by OpenClaw:
  • C:\Users\artva\AppData\Roaming\npm\node_modules\openclaw\node_modules\sqlite-vec-windows-x64\vec0.dll
• Workspace memory store:
  • C:\Users\artva\.openclaw\memory\main.sqlite

Symptoms

openclaw memory status reports:

• Vector: unknown
• FTS: ready
• Indexed: 30/30 files

openclaw memory index --agent main --force completes, but logs warnings like:

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

This happens across many files.

What was ruled out

1) Stale DB / stale schema

I backed up the existing DB, moved it aside, and forced a fresh rebuild.

Result:

• new DB created successfully
• chunks and FTS tables were created
• no chunks_vec table was created
• indexing still logged sqlite-vec unavailable

So this does not appear to be caused by stale DB state.

2) Missing allowExtension: true

Current 2026.4.14 dist appears to open the memory DB with:

const db = new DatabaseSync(dbPath, { allowExtension });

So the previously reported allowExtension issue does not seem to explain this specific case.

3) Windows / sqlite-vec / node:sqlite generally being broken

On the same machine, a direct standalone Node test succeeded using:

import { DatabaseSync } from 'node:sqlite';
import * as sqliteVec from 'sqlite-vec';

const db = new DatabaseSync(':memory:', { allowExtension: true });
sqliteVec.load(db);
const row = db.prepare('select vec_version() as v, vec_length(?) as len').get(
  new Uint8Array(new Float32Array([0.1, 0.2, 0.3, 0.4]).buffer)
);
console.log(row);

Result:

{"v":"v0.1.9","len":4}

That suggests the lower stack works locally.

Current best diagnosis

This looks like an OpenClaw-specific memory-core runtime issue rather than a general local environment problem.

The likely failing step is somewhere in the real memory-core vector initialization path, for example:

• bundled/runtime behavior around sqliteVec.load(db) differing from the standalone case
• CREATE VIRTUAL TABLE IF NOT EXISTS chunks_vec USING vec0(...) failing after load
• an error during vector init being swallowed and only surfacing as sqlite-vec unavailable

The current dist appears to use a sane sequence:

1. initialize provider / generate embeddings
2. call ensureVectorReady(sample.length)
3. call loadSqliteVecExtension({ db, extensionPath })
4. then run CREATE VIRTUAL TABLE IF NOT EXISTS chunks_vec USING vec0(...)

But in the failing runtime path, chunks_vec never appears.

Relevant code path observed in current dist

OpenClaw appears to:

1. initialize provider / get embeddings first
2. call ensureVectorReady(sample.length)
3. call loadSqliteVecExtension({ db, extensionPath })
4. then run:

CREATE VIRTUAL TABLE IF NOT EXISTS chunks_vec USING vec0(
  id TEXT PRIMARY KEY,
  embedding FLOAT[${dimensions}]
)

But in the failing runtime path, chunks_vec never appears.

Commands run

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

Then a clean DB rebuild test:

• moved C:\Users\artva\.openclaw\memory\main.sqlite aside
• removed WAL/SHM files
• reran:

openclaw memory index --agent main --force

Expected behavior

• chunks_vec should be created on a fresh DB
• forced memory indexing should populate vector rows
• openclaw memory status should report vector availability cleanly

Actual behavior

• memory indexing completes
• chunk/FTS writes succeed
• vector table is never created
• repeated warnings indicate sqlite-vec is unavailable
• memory recall is degraded to FTS-only behavior

Related issues

Potentially related to:

• #64776 sqlite-vec extension not loaded during gateway runtime memory sync
• #65156 sqlite-vec loads but registers no functions / ABI mismatch
• #65244 missing allowExtension option in DatabaseSync (though this specific build appears to include it)

Why this matters

This blocks reliable semantic memory and, by extension, downstream features that depend on healthy vector-backed recall, including dreaming/synthesis workflows.