memory search

[short forge]

What I Found

The memory_search failure is a red herring for the actual state of
your system.

Here's what the openclaw memory status --deep command revealed:

1. Memory databases are present and healthy. All SQLite databases
   exist in ~/.openclaw/memory/, including main.sqlite (13MB — your main
   agent's memory store), and others for each sub-agent.
2. Vector store is loaded and ready. The sqlite-vec extension
   (vec0.so) is found and loaded successfully.
3. But — zero content has been indexed. For the main agent
   specifically, the status shows:
   • Embeddings: ready (the service is available)
   • By source: memory · 0/0 files · 0 chunks (nothing indexed)
   • Dirty: yes (the database has changes waiting to be indexed, but
     indexing never ran)
4. The node-llama-cpp GPU mode is failing. The logs show The prebuilt
   binary for platform "linux" "x64" with Vulkan support is not
   compatible with the current system, falling back to using no GPU.
   This means the local embedding model is falling back to CPU-only
   mode, which is slow and may be causing timeouts during the indexing
   process.
5. Your daily memory files ARE fine. The files in
   /home/rr420/my_projects/openclaw/memory/ exist and are readable —
   2026-04-27.md and 2026-04-28.md.

─────────────────────────────────────────────────────────────────────

Root Cause Summary

The memory system itself works fine. The issue is that the embedding
indexer has not successfully processed your memory files into the
vector store. The databases are empty, and the memory_search calls
are failing because there's simply nothing to search — not because of
a database corruption or access issue.

  "memorySearch": {
    "provider": "local"
  },

what u think, why , how to fix

[visual warren]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[subtle cradle]

First: please run openclaw --version — version matters a lot for memory bugs.

My read: the Vulkan/node-llama-cpp warning is probably not the main root cause. It explains “local embeddings may be slow,” but memory · 0/0 files means OpenClaw is not seeing any memory files to index for that agent/workspace.

Most likely causes:

1. Wrong active workspace
   Your files are in /home/rr420/my_projects/openclaw/memory/, but the main agent may be using another workspace, usually ~/.openclaw/workspace.

2. Memory config in legacy/wrong place
   Current config should be under:

{
  agents: {
    defaults: {

      memorySearch: {
        provider: "local"
      }
    }
  }
}

3. Indexer never ran / timed out after fixing paths
   Then the CPU-only local embedding fallback matters.

Try this:

openclaw config get agents.defaults.workspace

openclaw config get agents.list
openclaw memory status --deep --agent main

If the workspace is not /home/rr420/my_projects/openclaw, either set it:

openclaw config set agents.defaults.workspace "/home/rr420/my_projects/openclaw"
openclaw gateway restart
openclaw memory index --force --agent main

Or keep your current workspace and add the notes as extra paths:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "local",
        extraPaths: ["/home/rr420/my_projects/openclaw/memory"]
      }
    }
  }
}

Then:

openclaw gateway restart
openclaw memory index --force --agent main
openclaw memory search "2026-04-27" --agent main

If indexing starts but hangs/errors, switch temporarily to a hosted embedding provider to prove the pipeline works, or increase local timeout:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "local",
        sync: {
          embeddingBatchTimeoutSeconds: 1200

        }
      }
    }
  }
}

Docs: https://docs.openclaw.ai/concepts/memory-search and https://docs.openclaw.ai/reference/memory-config

[short forge]

but i use api provider not local model, what u think, is that matter, i use provider like google and nvidia

[subtle cradle]

Yes, that matters — chat provider ≠ memory embedding provider.

If your chat model is Google/NVIDIA, memory search does not automatically use that unless agents.defaults.memorySearch.provider is set to a supported embedding provider.

Important bits:

• memorySearch.provider: "local" means memory embeddings are using local node-llama-cpp, regardless of your chat model.
• For Google/Gemini embeddings, use gemini, not google:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "gemini",
        model: "gemini-embedding-001"

      }
    }
  }
}

• I don’t think nvidia is a supported memory embedding provider ID directly. Supported memory providers include gemini, openai, voyage, mistral, deepinfra, ollama, local, etc.

But: memory · 0/0 files still smells like workspace/path issue, not provider issue. Wrong provider usually gives “embeddings not ready” or embedding errors; 0/0 files means it didn’t find memory files to index.

Check these:

openclaw --version
openclaw config get agents.defaults.workspace

openclaw config get agents.defaults.memorySearch
openclaw memory status --deep --agent main

Then fix both sides:

1. Point workspace or extraPaths at /home/rr420/my_projects/openclaw/memory
2. Set memory provider to gemini
3. Reindex:

openclaw gateway restart
openclaw memory index --force --agent main

Docs: https://docs.openclaw.ai/concepts/memory-search

Config: https://docs.openclaw.ai/reference/memory-config

[short forge]

why agent stop ans?

streaming watchdog: no stream updates for 30s; resetting status.
The backend may have dropped this run silently — send a new message
to resync.
connected | idle
agent main (Yumika) | session main (openclaw-tui) |
nvidia/minimaxai/minimax-m2.7 | think medium | tokens 117k/200k
(59%)
16:49:20+08:00 info cron {"module":"cron","storePath":"/home/rr420/.openclaw/cron/jobs.json"} {"pruned":1,"retentionMs":86400000} cron-reaper: pruned 1 expired cron run session(s)
16:49:38+08:00 warn diagnostic {"subsystem":"diagnostic"} stuck session: sessionId=main sessionKey=agent:main:main state=processing age=395s queueDepth=0
16:50:06+08:00 warn diagnostic {"subsystem":"diagnostic"} stuck session: sessionId=main sessionKey=agent:main:main state=processing age=423s queueDepth=0
Log tail truncated (increase --max-bytes).

[subtle cradle]

That log is chat-run streaming, not the memory indexer.

What happened:

• TUI got no stream chunks for 30s → it reset the UI to idle.
• Gateway still thinks agent:main:main is processing for 395s+.
• So the backend/model call likely hung or silently dropped the stream.
• cron-reaper line is unrelated.
• 117k/200k context is pretty big, and nvidia/minimaxai/minimax-m2.7 may be more likely to stall on long/tool-heavy turns.

Try in order:

/stop

Then send a simple message. If still weird:

/reset soft

If still stuck:

/new

If even /stop does not clear it, restart gateway:

openclaw gateway restart

Then check the real error with a bigger log tail:

openclaw --version
openclaw status --all
openclaw logs --max-bytes 200000

My guess: NVIDIA/Minimax stream dropped or hung, not memory DB corruption. If it keeps happening, test the same prompt on a smaller fresh session (/new) or another provider/model. Also your memory provider should still be fixed separately — don’t leave memorySearch.provider: "local" if you intend API embeddings.

Docs: https://docs.openclaw.ai/tools/slash-commands

[short forge]

[assistant turn failed before producing content]

[assistant turn failed before producing content]

[assistant turn failed before producing content]

[assistant turn failed before producing content]

[subtle cradle]

That line is a failure placeholder, not the real error.

[assistant turn failed before producing content] means: the model/backend run crashed, timed out, or got aborted before it emitted any assistant text. OpenClaw stores that placeholder so the session transcript isn’t empty/broken. The real cause is in errorMessage / gateway logs.

Since you have it 4 times, I’d treat this as same session repeatedly failing, likely provider/stream/runtime related — not the memory DB itself.

Do this:

/stop
/reset soft

If it fails again:

/new

If still stuck:

openclaw gateway restart

Then collect the useful debug info:

openclaw --version
openclaw status --all
openclaw logs --max-bytes 300000