Hi OpenClaw team — I ran into a confusing “persistent memory doesn’t work” situation that looks like a UX + diagnostics gap.

What happened

• I expected “persistent memory” to mean the agent can reliably recall relevant details from MEMORY.md / memory/*.md when asked.
• In practice, the agent failed to recall and then provided an explanation that boiled down to: “memory_search is disabled because no embedding provider API key is configured.”
• The docs do cover memory + embeddings, but this requirement wasn’t surfaced prominently during setup, and the failure mode was silent enough that it looked like the agent was just forgetting / hallucinating.
  Why this is a problem
• Without a working embedding provider (remote key or working local embeddings), semantic recall via memory_search can be effectively non-functional.
• When recall fails silently, users blame “AI forgot” and the model may invent explanations or incorrect setup commands.
• There is a CLI (openclaw memory status --deep) that reveals the real state, but it’s not obvious to new users and isn’t prompted by the wizard.
  Steps to reproduce (fresh install)

1. Install and run OpenClaw normally (gateway running, memory plugin enabled).
2. Do NOT configure any embeddings provider (no OpenAI/Gemini key and no local embeddings configured).
3. Put a unique fact into MEMORY.md in the agent workspace.
4. Ask the agent about that fact in a new chat/session.
5. Observe recall failure / empty results (or the model saying it can’t search memory).
6. Run:
   • openclaw memory status --deep
   • (optional) openclaw memory search ""

Actual behavior

• Memory recall fails in a way that’s easy to misinterpret as “persistent memory is broken.”
• There’s no prominent warning during onboarding or at runtime that semantic memory search is disabled.
• Configuration is easy to get wrong: I also hit config validation errors when trying to add a Google/Gemini provider config manually because required fields like baseUrl / models weren’t obvious from the error context.

Expected behavior

• If semantic memory search is disabled, OpenClaw should say so loudly and early:
  • During onboarding (“Memory search requires embeddings: configure OpenAI/Gemini or local embeddings”)
  • In openclaw doctor (explicit check + actionable guidance)
  • Potentially on gateway start logs (“memory_search disabled: no embedding provider configured”)
• Ideally provide a graceful fallback:
  • If embeddings are unavailable, still allow keyword-only search over Markdown (FTS/BM25) rather than returning “disabled” for memory_search, or at least return a very explicit diagnostic message the agent can surface.

Suggestions

• Add a dedicated check in openclaw doctor:
  • Detect “memory plugin enabled but embeddings unavailable”
  • Print one-line fix options (set GEMINI_API_KEY, run openclaw onboard --auth-choice gemini-api-key, or configure memorySearch.provider=local with modelPath)
• Make onboarding explicitly ask: “Enable memory semantic search?” and guide through provider selection.
• Improve config error messaging around provider blocks (if models.providers.google requires baseUrl and models, suggest a minimal valid snippet).
• Consider exposing a clear runtime status indicator (openclaw memory status summary) in the dashboard / health output.
  Environment
• OpenClaw version: 2026.2.9
• OS: Ubuntu 24.04 (VM)
• Gateway: systemd service (openclaw-gateway.service)
• Channel: WhatsApp
• Memory tools: openclaw memory status/search available

Notes

• I’m intentionally not pasting any API keys here.