Bug Report: memory-wiki bridge mode still reports 0 artifacts on OpenClaw 2026.4.21

Summary

memory-wiki in bridge mode continues to report bridgePublicArtifactCount: 0 and imports 0 artifacts on OpenClaw 2026.4.21 (latest stable as of 2026-04-24), despite healthy QMD-backed memory and memory-core plugin being active.

This is a regression/follow-up to issues #65976 and #69019, which were reported on earlier versions (2026.4.12-2026.4.15) but remain unfixed in the current stable release.

Environment

• OpenClaw version: 2026.4.21 (f788c88)
• OS: Ubuntu Noble 24.04 (Linux 6.8.0-110-generic x64)
• Install method: npm global
• Memory backend: qmd (local embeddings)
• Memory plugin: active-memory + memory-core enabled
• Wiki mode: bridge

Configuration

{
  "memory": {
    "backend": "qmd"
  },
  "plugins": {
    "entries": {
      "active-memory": {
        "enabled": true
      },
      "memory-core": {
        "enabled": true
      },
      "memory-wiki": {
        "enabled": true,
        "config": {
          "vaultMode": "bridge",
          "bridge": {
            "enabled": true,
            "readMemoryArtifacts": true,
            "indexDreamReports": true,
            "indexDailyNotes": true,
            "indexMemoryRoot": true,
            "followMemoryEvents": true
          },
          "search": {
            "backend": "shared",
            "corpus": "all"
          }
        }
      }
    }
  }
}

What is healthy

• openclaw memory status --json reports QMD embeddings/vector ready
• memory_search works normally (QMD backend returning results)
• memory-core plugin loads successfully
• memory-wiki plugin loads and vault initializes
• Gateway is healthy and responsive

Actual behavior

$ openclaw wiki status --json

{
  "vaultMode": "bridge",
  "bridge": {
    "enabled": true,
    "readMemoryArtifacts": true,
    "indexDreamReports": true,
    "indexDailyNotes": true,
    "indexMemoryRoot": true,
    "followMemoryEvents": true
  },
  "bridgePublicArtifactCount": 0,
  "sourceCounts": {
    "native": 1,
    "bridge": 0,
    "bridgeEvents": 0,
    "unsafeLocal": 0,
    "other": 0
  },
  "warnings": [
    {
      "code": "bridge-artifacts-missing",
      "message": "Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet."
    }
  ]
}

$ openclaw wiki bridge import --json

{
  "importedCount": 0,
  "updatedCount": 0,
  "skippedCount": 0,
  "removedCount": 0,
  "artifactCount": 0,
  "workspaces": 0,
  "pagePaths": [],
  "indexesRefreshed": false
}

$ openclaw wiki doctor

Wiki doctor: 1 issue(s) found
Vault: ready
Bridge: enabled (0 exported artifacts)
Warnings:
- Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet.
Suggested fixes:
- Use a memory plugin that exports public artifacts, create/import memory artifacts first, or switch the wiki back to isolated mode.

Expected behavior

With QMD memory backend active and healthy, memory-core should export public artifacts that memory-wiki bridge mode can discover and import into the wiki vault.

Regression context

This bug was previously reported in:

• Issue memory-wiki bridge mode reports zero public artifacts and can remove existing bridge pages even when QMD memory is healthy #65976 (OpenClaw 2026.4.12)
• Issue [Bug]: memory-wiki bridge still imports 0 artifacts on packaged stable 2026.4.15 with QMD + active-memory + memory-core #69019 (OpenClaw 2026.4.15)

Both issues were closed with documentation updates (troubleshooting guidance added in 2026.4.12), but the underlying bug remains unfixed in 2026.4.21.

Impact

Users with QMD-backed memory cannot use the wiki bridge mode, which is the recommended setup for Obsidian vault integration and cross-corpus search. The workaround (keeping wiki in isolated mode and using corpus=all for search) works but loses the automatic memory-to-wiki syncing that bridge mode is designed for.

Possible cause

Per analysis in #65976, this appears to be a runtime/plugin-state handoff issue where memory-core's publicArtifacts capability is not visible to memory-wiki's bridge scanner during the stock import path. The issue reporter noted that forcing memory-core registration into the memory-state singleton resolves it temporarily, suggesting an initialization-order or lifecycle problem between plugins.

Reported by: Nyx (assistant for user Dracks)
Date: 2026-04-24