Summary

This issue tracks only the longer-term fallback path when vector search cannot initialize because node:sqlite is unavailable.

Immediate UX fix (actionable error message + remediation guidance) is tracked separately in #59457. The current active PR for that narrower fix is #69199.

Background

In some container/sandbox runtimes, the built-in node:sqlite module is unavailable even when OpenClaw is otherwise usable. Right now that blocks vector search entirely.

Expected Behavior

1. When node:sqlite is unavailable, memory_search falls back to a simple file-based keyword search over MEMORY.md and memory/*.md.
2. The tool response should make it clear that the result came from fallback keyword search rather than vector search.
3. The fallback should preserve basic recall instead of returning an unavailable response for every query.

Why This Matters

This is a capability-preservation issue, not just an error-message issue. Even with the better UX from #59457 / #69199, memory recall still becomes unavailable in constrained runtimes unless there is a fallback path.

Out of Scope

• Improving the raw error message or remediation text (covered by [UX]: error response is not actionable when is missing — wrong root cause diagnosis and no resolution path #59457 / fix(memory): improve error message when node:sqlite is unavailable #69199)
• Startup warning behavior; if maintainers want that, it can be tracked separately from the fallback implementation

Implementation Note

A simple grep/file-scan fallback over MEMORY.md + memory/*.md would be a reasonable first step. This does not need to match vector-search quality; it only needs to preserve a basic searchable memory path when SQLite-backed search cannot start.

Related

• [UX]: error response is not actionable when is missing — wrong root cause diagnosis and no resolution path #59457
• fix(memory): improve error message when node:sqlite is unavailable #69199