Summary

memory-wiki bridge still imports 0 artifacts on OpenClaw 2026.4.27 even though PR #72615 is installed and memory-core does register publicArtifacts correctly.

The remaining bug appears to be a split singleton between the installed OpenClaw dist and the managed plugin-runtime-deps dist mirror:

• memory-core registers publicArtifacts into the canonical installed dist/memory-state-*.js module.
• memory-wiki bridge gateway method runs from the managed plugin-runtime-deps/openclaw-2026.4.27-*/dist/... mirror and calls listActiveMemoryPublicArtifacts() from the mirrored dist/memory-state-*.js module.
• That mirrored module has a separate empty memoryPluginState, so wiki.bridge.import sees hasCapability=false and returns artifactCount: 0.

So #72615 fixed CLI → Gateway routing, but the Gateway bridge path can still read the wrong memory-state singleton.

Environment

• OpenClaw: 2026.4.27 (cbc2ba0)
• OS: Linux x64
• Node: v22.22.2
• Install: npm global
• Runtime mirror involved: managed plugin-runtime-deps/openclaw-2026.4.27-*
• Memory slot: plugins.slots.memory = "memory-core"
• memory-wiki enabled; bridge migration was rolled back after the zero-artifact result for safety.

Relevant config shape

{
  "plugins": {
    "slots": { "memory": "memory-core" },
    "entries": {
      "memory-core": { "config": { "dreaming": { "enabled": true } } },
      "memory-wiki": {
        "enabled": true,
        "config": {
          "vaultMode": "bridge",
          "bridge": {
            "enabled": true,
            "readMemoryArtifacts": true,
            "indexDailyNotes": true,
            "indexMemoryRoot": true,
            "indexDreamReports": true,
            "followMemoryEvents": true
          }
        }
      }
    }
  }
}

Repro

1. Configure memory-core as the selected memory slot.
2. Configure memory-wiki bridge with readMemoryArtifacts=true.
3. Ensure the configured workspace(s) contain MEMORY.md and memory/*.md files.
4. Restart Gateway.
5. Run:

openclaw gateway call wiki.bridge.import --json --timeout 60000

Actual result

{
  "importedCount": 0,
  "updatedCount": 0,
  "skippedCount": 0,
  "removedCount": 0,
  "artifactCount": 0,
  "workspaces": 0,
  "pagePaths": [],
  "indexesRefreshed": false,
  "indexUpdatedFiles": [],
  "indexRefreshReason": "no-import-changes"
}

openclaw wiki status --json in bridge mode also reports:

{
  "vaultMode": "bridge",
  "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."
    }
  ]
}

Expected result

Bridge import should see the artifacts exported by memory-core.publicArtifacts.listArtifacts() and import source pages from MEMORY.md, daily notes, dream reports, etc.

In a standalone harness, invoking the bundled memory-core plugin registration captures publicArtifacts and returns non-zero artifacts across the configured workspaces.

Example harness shape:

{
  "registered": true,
  "keys": ["promptBuilder", "flushPlanResolver", "runtime", "publicArtifacts"]
}
{
  "artifactCount": 118,
  "workspaces": [
    "<workspace-1>",
    "<workspace-2>",
    "<workspace-3>",
    "<workspace-4>"
  ]
}

Diagnosis evidence

Temporary instrumentation of both copies of dist/memory-state-*.js showed the singleton split.

During Gateway startup, memory-core registered public artifacts into the canonical installed module:

{
  "event": "registerMemoryCapability",
  "pluginId": "memory-core",
  "keys": ["promptBuilder", "flushPlanResolver", "runtime", "publicArtifacts"],
  "hasPublicArtifacts": true,
  "stack": [
    "<installed-openclaw>/dist/memory-state-*.js",
    "<installed-openclaw>/dist/loader-*.js",
    "<plugin-runtime-deps>/dist/extensions/memory-core/index.js"
  ]
}

But when calling wiki.bridge.import, the bridge code used the mirrored module and found no capability:

{
  "event": "listActiveMemoryPublicArtifacts:start",
  "hasCapability": false,
  "keys": [],
  "hasPublicArtifacts": false,
  "cfgHasAgents": true,
  "agentCount": 4,
  "stack": [
    "<plugin-runtime-deps>/dist/memory-state-*.js",
    "<plugin-runtime-deps>/dist/cli-*.js",
    "<plugin-runtime-deps>/dist/extensions/memory-wiki/index.js"
  ]
}

That explains the 0 artifact result: memory-core and memory-wiki are not sharing the same memoryPluginState singleton.

Why this is different from the closed bridge issues

Related historical issues were closed as fixed/superseded by #72615. This install has #72615 behavior: bridge CLI routes through Gateway. The remaining failure is not CLI-local routing; it is the Gateway/plugin-runtime-deps mirror reading a different memory-state module instance.

Likely related closed/superseded issues:

• #68828
• #65722
• #63157
• #65092
• #63092

Closest active adjacent issue found:

• #74777 (plugin-runtime-deps memory runtime dependencies not retained/resolved), but this report is specifically about the memory capability singleton split causing bridge artifact export to be invisible.

Suggested fix directions

One of these should fix it:

1. Make memory-wiki bridge obtain public memory artifacts through an injected host/runtime API rather than importing listActiveMemoryPublicArtifacts() from the mirrored dist bundle.
2. Ensure singleton core modules such as memory-state-* are externalized/shared-resolved from the canonical Gateway runtime, not duplicated into plugin-runtime-deps.
3. Pass a canonical listPublicArtifacts dependency into syncMemoryWikiImportedSources() / bridge Gateway methods from the host runtime.

A local workaround would be to make the mirrored memory-state-*.js re-export the canonical installed module, but that is fragile because plugin-runtime-deps is regenerated.

Safety note

Bridge mode was not left enabled after the zero-artifact result, to avoid an empty bridge sync/prune risk.