#QMD indexed but agent not retrieving results

1 messages · Page 1 of 1 (latest)

dusk violet
#

QMD shows 3 files indexed, 38 chunks, vector ready. Content is confirmed in the sqlite index. But when asked to search memory the agent returns "no information found." This started after an OpenClaw update. Running 2026.4.21. Is there a known retrieval issue after updates, or a command to reset the search layer without wiping the index?

plain sorrelBOT
#

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

midnight zephyrBOT
#

I dug through the docs/code a bit. I do not see a specific 2026.4.21 changelog item for “QMD index is healthy but all recall comes back empty”.

A couple useful bits, though:

  • There is no dedicated “reset search layer but keep the index” command in the docs.
  • The closest safe repair path is:
    • openclaw memory status --deep --index --verbose
    • openclaw memory status --fix
    • then, if needed, openclaw memory index --force

One important clue: in 2026.4.21, failed memory recall was changed to fail open instead of crashing the reply. So a QMD/runtime failure can now look like “no information found” instead of throwing a visible error. That makes logs much more important here.

I’d test in this order:

openclaw memory search --query "an exact phrase from one of the indexed files" --max-results 10
# 
openclaw memory status --deep --index --verbose
openclaw memory status --fix
openclaw logs --follow

Then reproduce the failed in-chat recall while logs are open.

How to interpret it:

  • If openclaw memory search ... also returns nothing, this is likely a QMD retrieval/runtime problem, not an agent prompt problem.
  • If CLI search does return hits, but chat still says “no information found”, I’d check session scope first.

For QMD scope, current code defaults to:

  • allow chatType: "direct"
  • allow chatType: "channel"
  • deny group
#

So Discord threads/channels should normally be fine, but a custom memory.qmd.scope could still block results.

Also worth watching for in logs:

  • QMD timeout on first/cold search
  • invalid JSON from qmd query
  • scope denial warnings
  • fallback to builtin search

If the logs show timeouts, the docs specifically suggest increasing:

memory: {
  qmd: {
    limits: {
      timeoutMs: 120000
    }
dusk violet
#

QMD CLI search works perfectly but in-chat recall returns nothing in Telegram groups. You mentioned group chats are denied by default. What is the exact config key and format to allow group chats in memory.qmd scope? Running 2026.4.21

midnight zephyrBOT
#

Yep, the exact key is memory.qmd.scope, and the config format is JSON5, not YAML.

If you want to keep the shipped behavior plus allow group chats, use:

{
  memory: {
    backend: "qmd",
    qmd: {
      scope: {
        default: "deny",
        rules: [
          { action: "allow", match: { chatType: "direct" } },
          { action: "allow", match: { chatType: "channel" } },
          { action: "allow", match: { chatType: "group" } },
        ],
# 
      },
    },
  },
}

If you want to allow Telegram groups only, make the group rule narrower:

{
  memory: {
    backend: "qmd",
    qmd: {
      scope: {
        default: "deny",
# 
        rules: [
          { action: "allow", match: { chatType: "direct" } },
          { action: "allow", match: { chatType: "channel" } },
          { action: "allow", match: { channel: "telegram", chatType: "group" } },
        ],
      },
    },
  },
}

A couple gotchas:

  • scope is a full policy block, so if you set it, include every chat type you still want.
  • After changing it, restart the gateway:
    • openclaw gateway restart
dusk violet
#

Running tools profile "coding" in openclaw.json. Memory CLI search works fine but in-chat memory recall never fires — Lex doesn't attempt a QMD search at all, just answers from general knowledge. Does the coding profile disable memory/recall tools? What profile should I use for a personal assistant that needs full memory access?

midnight zephyrBOT
#

Short version, no. tools.profile: "coding" does not disable memory recall tools.

In current docs/code, coding includes:

  • group:memory
  • which means memory_search + memory_get

So switching from coding to full by itself will not make recall start.

What usually causes the behavior you describe is one of these:

  1. Active Memory is not enabled
  2. The active-memory plugin is enabled, but not targeted at the agent serving that chat
  3. The chat type is not allowed, especially groups
  4. memory.qmd.scope allows CLI search but blocks group-session recall
  5. tools.byProvider / tools.deny overrides are stripping memory tools for that model/provider
#

For a personal assistant with reliable automatic recall, the important part is Active Memory, not the tools profile.

What I’d recommend

Keep tools.profile: "coding" if you like the safer/default local tool surface, and add Active Memory for the actual assistant agent:

{
  tools: {
    profile: "coding"
  },
  plugins: {
    entries: {
      "active-memory": {
        enabled: true,
        config: {
# 
          agents: ["main"], // or your actual assistant agent id
          allowedChatTypes: ["direct", "group", "channel"],
          queryMode: "recent",
          promptStyle: "balanced",
          logging: true
        }
      }
    }
  },
  memory: {
    backend: "qmd",
    qmd: {
      scope: {
        default: "deny",
        rules: [
# 
          { action: "allow", match: { chatType: "direct" } },
          { action: "allow", match: { chatType: "channel" } },
          { action: "allow", match: { chatType: "group" } }
        ]
      }
    }
  }
}

Important nuance

For Telegram groups, you need both:

  • plugins.entries.active-memory.config.allowedChatTypes to include "group"
  • memory.qmd.scope to allow "group"
#

If either one is missing, recall may never fire in-chat.

What profile should you use?

  • coding: good default, and it already has memory tools
  • full: only use if you want broadly unrestricted tools, not because of memory specifically

So my actual recommendation is:

  • Use coding or full based on overall tool access preference
  • Enable Active Memory
  • Allow group in both active-memory config and QMD scope

Quick live check:

  • turn on /verbose on
  • if Active Memory is running, you should see an active-memory status line