OpenClaw Bug Report: memory-wiki bridge mode not exporting artifacts

Date: 2026-04-17
OpenClaw Version: 2026.4.14 (323493f)
Reporter: 王飞 (via OpenClaw agent)

Issue Summary

memory-wiki plugin in bridge mode fails to export public artifacts from memory-core plugin, while unsafe-local mode works correctly. The bridgePublicArtifactCount is always 0 despite memory-core being properly configured and functioning.

Environment

System

• OS: macOS (Darwin 25.1.0 arm64)
• Node.js: v25.8.2
• OpenClaw: 2026.4.14 (323493f)

Configuration

memory-core (active memory plugin)

{
  "memory-core": {
    "enabled": true,
    "config": {
      "dreaming": {
        "enabled": true
      }
    }
  }
}

memory-wiki (bridge mode)

{
  "memory-wiki": {
    "enabled": true,
    "config": {
      "vaultMode": "bridge",
      "vault": {
        "path": "/Users/wangfei/.openclaw/wiki/main",
        "renderMode": "obsidian"
      },
      "bridge": {
        "enabled": true,
        "readMemoryArtifacts": true,
        "indexDreamReports": true,
        "indexDailyNotes": true,
        "indexMemoryRoot": true,
        "followMemoryEvents": true
      }
    }
  }
}

Agents Configuration

• 3 agents configured: main (小菲), invest (小管), work (小芽)
• Each with separate workspace directories
• All workspaces contain valid memory files

Steps to Reproduce

1. Configure memory-wiki with vaultMode: "bridge"
2. Ensure memory-core is enabled with dreaming enabled
3. Run wiki bridge import command:

   openclaw wiki bridge import

Actual Result

Bridge import synced 0 artifacts across 0 workspaces (0 new, 0 updated, 0 unchanged, 0 removed).
Indexes not refreshed (no-import-changes).

wiki status shows:

{
  "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 detect and sync public artifacts from memory-core, similar to unsafe-local mode behavior.

Verification & Workaround Testing

Test 1: unsafe-local mode works

Changed configuration to:

{
  "vaultMode": "unsafe-local",
  "unsafeLocal": {
    "allowPrivateMemoryCoreAccess": true,
    "paths": [
      "/Users/wangfei/.openclaw/workspace/memory",
      "/Users/wangfei/.openclaw-invest/workspace/memory",
      "/Users/wangfei/.openclaw-work/workspace/memory"
    ]
  }
}

Result:

Unsafe-local import synced 227 artifacts (227 new, 0 updated, 0 unchanged, 0 removed).
Indexes refreshed (231 files).

Conclusion: The memory files exist and are accessible. The issue is specific to bridge mode's capability API call chain.

Test 2: memory-core is functioning

Gateway logs confirm memory-core is operating normally:

[plugins] memory-core: light dreaming staged 55 candidate(s) [workspace=/Users/wangfei/.openclaw/workspace].
[plugins] memory-core: REM dreaming wrote reflections from 2078 recent memory trace(s)
[plugins] memory-core: dreaming promotion complete (workspaces=3, candidates=0, applied=0, failed=0).

Conclusion: memory-core plugin is properly registered and functioning.

Root Cause Analysis

Based on code inspection of memory-wiki and memory-core plugins:

Call Chain

openclaw wiki bridge import
  → syncMemoryWikiBridgeSources()
    → listActiveMemoryPublicArtifacts()
      → memoryPluginState.capability?.capability.publicArtifacts?.listArtifacts()
        → memory-core: listMemoryCorePublicArtifacts()

Suspected Issue

The memoryPluginState.capability is undefined when called from wiki bridge import context, causing the function to return an empty array:

// From memory-state-CKpinHhR.js
async function listActiveMemoryPublicArtifacts(params) {
  return (await memoryPluginState.capability?.capability.publicArtifacts?.listArtifacts(params) ?? [])
    .map(cloneMemoryPublicArtifact)
    .toSorted(...);
}

Possible Causes

1. Capability Registration Timing: memoryPluginState.capability may not be initialized when the CLI command runs
2. Plugin Lifecycle: The capability API might not be persisted across CLI invocations
3. Gateway Context: CLI commands may not have access to the same plugin state as the gateway runtime

Impact

• Bridge mode is non-functional for syncing memory artifacts to wiki
• Users must use unsafe-local mode as a workaround, which:
  • Requires explicit path configuration
  • Bypasses the intended public artifact API abstraction
  • May have different security implications

Workaround

Use unsafe-local mode with explicit paths:

{
  "memory-wiki": {
    "config": {
      "vaultMode": "unsafe-local",
      "unsafeLocal": {
        "allowPrivateMemoryCoreAccess": true,
        "paths": [
          "/path/to/agent/workspace/memory"
        ]
      }
    }
  }
}

openclaw wiki unsafe-local import

Suggested Fix

1. Ensure memoryPluginState.capability is properly initialized when CLI commands run
2. Add logging to diagnose why capability is undefined in CLI context
3. Consider adding a fallback that directly calls listMemoryCorePublicArtifacts if capability API fails

Additional Context

• Gateway is regularly restarted (daily), ruling out initialization timing as the sole cause
• The issue persists across multiple restarts
• Both memory-core and memory-wiki plugins are bundled with OpenClaw (not third-party)

Related Documentation

• https://docs.openclaw.ai/plugins/memory-wiki (Vault modes section)
• Bridge mode documented to work with active memory plugin's public artifacts

Reporter Contact: Via OpenClaw Feishu DM (ou_179a6bee00d6b80a51aceb3d143a779a)