Summary

When using memory_search with corpus: "sessions" on the builtin memory backend, many search queries return 0 results even though:

• The keywords exist in the indexed session data (verified via direct SQL)
• The same keywords return results with corpus: "memory" (memory files work fine)
• FTS5 direct SQL queries return correct results from Python

Steps to reproduce

1. Have session transcripts indexed (builtin backend, memorySearch.experimental.sessionMemory: true)
2. Run memory_search with corpus: "sessions" for various keywords
3. Compare results between corpus: "sessions" and corpus: "memory"

Expected behavior

Keywords present in session transcripts should return matching chunks.

Actual behavior

50% failure rate across tested keywords. Some words work, others return 0 results.

Root Cause Analysis

The searchKeyword function (in dist/manager-*.js) calls FTS5 MATCH queries but errors are silently swallowed by .catch(() => []):

// Line ~2829
const keywordResults = hybrid.enabled && this.fts.enabled && this.fts.available 
    ? await this.searchKeyword(cleaned, candidates, void 0, sourceFilterList)
        .catch(() => [])  // ← Error silently swallowed
    : [];

Direct SQL confirmation: All failing keywords return correct results when queried directly against chunks_fts. The FTS index is correct and complete. The problem is in the runtime call path.

Pattern observed

Working keywords: Chinese compound words (大语言模型, 向量数据库, 注意力机制) Failing keywords: Short English words (Dify, cron, PPT, API, Agent), common Chinese terms (数据库, 部署, 汇报, 插件)

This suggests a potential issue with how Node.js node:sqlite FTS5 trigram tokenizer handles certain character patterns, which works correctly in Python sqlite3 but fails in the Node.js runtime.

Environment

• OpenClaw version: 2026.4.26
• Operating system: Ubuntu 24.04 (Linux 6.8.0-110-generic, x64)
• Install method: npm global
• Memory backend: builtin (SQLite)
• Embedding provider: openai-compatible (SiliconFlow)
• Embedding model: BAAI/bge-m3 (1024 dims)
• Session chunks indexed: 1312 (source=sessions)
• Memory chunks indexed: 838 (source=memory)
• FTS: ready
• Vector: ready (sqlite-vec)

Impact

• High severity — 50% of session search queries return empty results
• Affects all users with corpus: "sessions" or memorySearch.sources: ["sessions"]
• Session transcripts are effectively partially invisible to memory recall
• The silent error masking makes diagnosis extremely difficult

Suggested fixes

1. Remove silent .catch(() => []) in searchKeyword — log the actual error so users can diagnose
2. Test Node.js sqlite FTS5 trigram tokenizer against CJK + mixed-language queries
3. Add fallback: when FTS MATCH query fails, fall back to LIKE-based substring search (as the code already partially supports via substringTerms)
4. Add diagnostic: openclaw memory status --deep should verify FTS queries work, not just report "FTS: ready"

Workaround

Currently there is no reliable workaround. Users must either:

• Avoid corpus: "sessions" entirely (lose ability to search past conversations)
• Use corpus: "memory" only (only searches MEMORY.md and memory/*.md files)