Summary

memory-core plugin incorrectly attempts to use OpenAI embeddings even when memory.backend = "qmd" is configured, causing both gateway startup failures and runtime memory search failures. QMD
backend uses local embeddings (embeddinggemma-300M) and should not depend on OpenAI authentication at any point.

Steps to reproduce

1. Configure OpenClaw with QMD memory backend:

   {
     "memory": {
       "backend": "qmd"
     }
   }

2. Ensure no OpenAI auth profile is configured:
  ```bash
    openclaw auth list
    # No openai:default profile present

3. Start the gateway:

  openclaw gateway start

4. Observe gateway startup failure with OpenAI auth error
5. Apply "workaround" (add dummy profile + key) to get past startup
6. Attempt to use memory_search tool multiple times
7. Observe inconsistent behavior and eventual failure

Expected behavior

• QMD backend should initialize successfully using local GGUF models for embeddings
• No OpenAI authentication should be required at startup or runtime
• All memory_search calls should use QMD's local embeddings
• Gateway should start without OpenAI-related errors
• Memory search should work entirely offline with QMD

Actual behavior

Startup Issue

• Gateway fails to start unless OpenAI auth profile exists with a valid API key
• Requires dummy workaround to bypass startup validation:

    # Add profile to config
    openclaw gateway config.patch --raw '{"auth":{"profiles":{"openai:default":{"provider":"openai","mode":"api_key"}}}}'
  
    # Set dummy key
    openclaw auth set openai:default --key "sk-dummy-key-not-used"

Runtime Issue (CRITICAL)

Even with the workaround, memory search is broken:

Test sequence:

  Query 1: "QMD memory backend configuration"
  → ✅ Uses provider: "qmd", returns results

  Query 2: "token burn optimization model selection"
  → ❌ Attempts to use OpenAI embeddings
  → ❌ Fails with 401: "Incorrect API key provided: sk-dummy..."
  → ❌ Returns: "disabled": true

  Query 3+: All subsequent searches
  → ❌ Memory search permanently disabled after first failure
  → ❌ Returns empty results with "disabled": true

Root cause:

• memory-core is not respecting memory.backend = "qmd" configuration
• Provider selection is inconsistent between calls
• Falls back to OpenAI embeddings despite explicit QMD config
• Once dummy key fails, memory search disables entirely
• No automatic recovery

Environment

• OpenClaw version: 2026.2.2-3
• OS: Linux (Docker container)
• Install method: Docker / gateway daemon
• Config: memory.backend = "qmd", QMD installed and functional via CLI
• QMD verification: qmd query "test" works correctly from shell

Logs or screenshots

Startup error (no workaround):

  [memory-core] Initializing with backend: qmd
  [auth] Validating embedding provider: openai
  Error: No available auth profile for openai (all in cooldown or unavailable)
  Gateway failed to start

Runtime error (with workaround applied):

  // First memory_search call - works
  {
    "results": [...],
    "provider": "qmd",
    "model": "qmd"
  }

  // Second memory_search call - fails and disables
  {
    "results": [],
    "disabled": true,
    "error": "openai embeddings failed: 401 {\n  \"error\": {\n    \"message\": \"Incorrect API key provided: sk-dummy***...openai...\",\n    \"type\": \"invalid_request_error\",\n    \"code\":
\"invalid_api_key\"\n  },\n  \"status\": 401\n}"
  }

  // All subsequent calls
  {
    "results": [],
    "disabled": true,
    "error": "openai embeddings failed: 401 ..."
  }

Additional context

• QMD documentation explicitly states it's a "fully local" backend with no external API dependencies
• QMD CLI tools (qmd query, qmd search) work perfectly when called directly
• memory-core appears to have two separate code paths:
  1. Startup validation (checks for OpenAI auth)
  2. Runtime embedding provider selection (sometimes ignores QMD config)
• This makes QMD backend effectively non-functional in OpenClaw despite being an advertised feature
• Users cannot use offline memory search even with QMD properly installed
• Related to PR feat (memory): Implement new (opt-in) QMD memory backend #3160 (QMD backend implementation) and issue [Feature]: Use QMD MCP server mode for warm model caching #9048 (QMD performance)

Impact

• Severity: Critical - Advertised QMD backend is unusable
• Blocks offline/airgapped deployments
• Creates false dependency on OpenAI API keys
• Memory search becomes unreliable (works once, then permanently fails)
• No clear error message guides users to resolution