Bug: openclaw doctor / openclaw status report memory unavailable even when mem0 runtime is healthy

Summary

After fixing a real openclaw-mem0 runtime regression locally, mem0 runtime recovered and is actively working again, but OpenClaw still reports memory as unavailable/unregistered in diagnostics.

This appears to be a doctor/status false positive.

Environment

• OpenClaw: 2026.4.2
• OS: macOS 26.4
• Node: 25.9.0
• Memory plugin: @mem0/[email protected]
• Mode: local gateway on 127.0.0.1:18789

Current incorrect diagnostics

openclaw doctor --non-interactive

Memory search
No active memory plugin is registered for the current config.

openclaw status

Memory enabled (plugin openclaw-mem0) · unavailable

Why this looks wrong

At the same time, runtime logs clearly show the memory plugin is active and working:

[plugins] openclaw-mem0: registered (mode: open-source, user: davie, graph: false, autoRecall: true, autoCapture: true)
[plugins] openclaw-mem0: injecting 10 memories into context (5 long-term, 5 session)
[plugins] openclaw-mem0: auto-captured 9 memories

After the full gateway restart, there were no new mem0 runtime validation errors.

Important context

There was a real mem0 regression first:

• nested mem0 plugin config apiKey fields had been migrated from plain strings to SecretRef objects
• the installed openclaw-mem0 path expected strings and emitted repeated runtime errors like:

{
  "code": "invalid_type",
  "expected": "string",
  "received": "object",
  "path": ["embedder", "config", "apiKey"]
}

That real runtime problem was fixed locally by making the plugin resolve nested SecretRefs before validation/use.

After that fix + full gateway restart:

• mem0 resumed normal runtime behavior
• invalid_type errors stopped
• doctor/status warnings remained

So the current issue being reported here is the remaining false-positive diagnostic state after runtime recovery, not the earlier plugin regression itself.

Expected behavior

If the memory plugin is:

• registered
• injecting memories into context
• auto-capturing memories
• no longer throwing current runtime validation errors

then:

• openclaw doctor should not say "No active memory plugin is registered"
• openclaw status should not say "Memory ... unavailable"

Actual behavior

Doctor/status still report memory as unavailable/unregistered even though runtime memory behavior is working.

Likely area to inspect

This looks like a mismatch between:

• doctor/status health heuristics
• actual runtime plugin registration and operation

Possibly:

• slot detection vs runtime registration path
• capability/health probe using a stale or stricter signal than actual runtime success
• diagnostic code not recognizing recovered plugin state correctly

Suggested fix

Align doctor/status memory health reporting with actual runtime memory-plugin state.

If full confidence is not possible, downgrade the wording to something softer, e.g.:

• Memory plugin registered, but health probe is inconclusive

instead of:

• No active memory plugin is registered for the current config

Repro-ish path

1. Start with mem0 enabled as the memory slot plugin.
2. Ensure runtime logs show mem0 registration + successful inject/capture behavior.
3. Run:
   • openclaw doctor --non-interactive
   • openclaw status
4. Observe that diagnostics still claim memory is unavailable/unregistered.

Notes

• This report is about the remaining false-positive doctor/status signal.
• The earlier runtime regression was real, but once fixed, diagnostics did not catch up to the recovered runtime state.