Title

memory-wiki bridge mode reports zero public artifacts and can remove existing bridge pages even when QMD memory is healthy

Summary

On a local OpenClaw host running 2026.4.12, memory-wiki bridge mode still reports bridgePublicArtifactCount: 0 through the stock openclaw wiki command path, even though:

• the documented QMD + bridge-mode recipe is configured
• the active memory backend is healthy
• public memory artifacts are present
• the same runtime can see and import those artifacts if memory-core is explicitly registered into the memory-state singleton first

Because the stock bridge import path sees zero artifacts, openclaw wiki bridge import --json can remove previously imported bridge pages from the wiki vault.

This looks like a runtime/plugin-state handoff issue rather than a config problem.

Version

• Reproduced on OpenClaw 2026.4.12
• Also observed on 2026.4.11

Expected behavior

With:

• memory.backend = "qmd"
• plugins.entries["memory-wiki"].enabled = true
• plugins.entries["memory-wiki"].config.vaultMode = "bridge"
• bridge flags enabled

the stock commands should:

• detect active public memory artifacts
• report a nonzero bridgePublicArtifactCount
• import bridge-backed source pages into the wiki vault

Actual behavior

The stock runtime path reports zero public artifacts:

{
  "bridgePublicArtifactCount": 0,
  "warnings": [
    {
      "code": "bridge-artifacts-missing",
      "message": "Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet."
    }
  ]
}

And the stock import path can then remove bridge pages:

{
  "importedCount": 0,
  "updatedCount": 0,
  "skippedCount": 0,
  "removedCount": 305,
  "artifactCount": 0,
  "workspaces": 0
}

Why this appears to be a bug

On the same host and same config:

1. openclaw memory status --json reports healthy QMD-backed memory across workspaces.
2. The memory-core plugin exports a publicArtifacts.listArtifacts capability.
3. If memory-core is explicitly registered into the memory-state singleton before invoking the wiki runtime, the same memory-wiki runtime immediately sees and imports all artifacts successfully.

Sanitized successful result from the forced-registration path:

{
  "importedCount": 305,
  "updatedCount": 0,
  "skippedCount": 0,
  "removedCount": 0,
  "artifactCount": 305,
  "workspaces": 8
}

That suggests:

• the artifacts exist
• the bridge import logic works
• the failure is in how the stock runtime path obtains or restores the active memory capability

Minimal repro outline

1. Configure QMD-backed memory and enable memory-wiki in bridge mode using the documented hybrid recipe.
2. Confirm memory is healthy with:

openclaw memory status --json

3. Run:

openclaw wiki status --json
openclaw wiki bridge import --json

4. Observe:

• bridgePublicArtifactCount: 0
• warning bridge-artifacts-missing
• bridge import reports artifactCount: 0
• existing bridge pages may be removed

Additional debugging notes

Local inspection of the installed runtime suggests the problem may be related to memory plugin capability restoration/caching in the plugin loader, but I cannot confirm whether that is the full root cause.

What is confirmed:

• direct forced registration of memory-core into memory-state restores expected bridge behavior
• stock openclaw wiki command path does not

Impact

• memory-wiki bridge mode appears broken even though memory data is healthy
• stock import can remove valid bridge-backed wiki pages
• this makes the feature look unreliable and raises the cost of using the recommended QMD + bridge setup

Suggested guardrail

Even before the root cause is fixed, it may be safer for openclaw wiki bridge import to avoid deleting existing bridge pages when:

• bridge mode is enabled
• active memory is configured
• artifact discovery unexpectedly returns zero

That would prevent destructive sync behavior during false-negative artifact detection.