Bug Description

After updating to v2026.2.22-2 and the gateway restarting, the memory search index repeatedly drops to 0 files / 0 chunks. It does not self-recover without running openclaw memory index manually.

Reproduction

1. Update OpenClaw to v2026.2.22-2 (gateway restarts automatically)
2. Check openclaw memory status → shows 0/111 files · 0 chunks
3. Run openclaw memory index → rebuilds to 111 files · 1067 chunks
4. Wait ~30 minutes → index drops back to 0 files · 0 chunks again

This cycle repeated 4 times within 3 hours on 2026-02-24 (12:00, 12:30, 14:00, 14:30 local time).

Environment

• OpenClaw version: 2026.2.22-2 (upgraded from 2026.2.21-2)
• OS: macOS 26.1 (arm64) — Mac mini
• Node.js: v25.2.1
• Memory provider: Voyage AI (voyage-4-large)
• Memory store: SQLite with sqlite-vec (~/.openclaw/memory/main.sqlite)
• Vector dims: 1024
• Files indexed (when healthy): 111 files · ~1060 chunks
• Embedding cache: disabled
• Gateway: local loopback, LaunchAgent service

Current status

openclaw memory status currently shows healthy (111/111 files · 1067 chunks) after the last manual rebuild, but it may drop again.

Workaround

A cron job running every 30 minutes checks openclaw memory status and runs openclaw memory index if chunks = 0. This keeps the system functional but wastes tokens + API calls.

Notes

• This did NOT happen on v2026.2.21-2
• The index drops seem to happen silently — no error in gateway logs
• openclaw memory status shows Indexed: 0/111 files · 0 chunks but Store path is correct
• Possibly related to embedding provider initialization timing after restart (previously saw FTS-only mode bug where provider takes ~50 min to init)