openclaw - ✅(Solved) Fix memory-wiki bridge mode imports 0 artifacts even though memory-core exposes MEMORY.md and memory/*.md as public artifacts [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63197Fetched 2026-04-09 07:57:08
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Participants

memory-wiki in bridge mode stays empty and reports bridge-artifacts-missing, even when memory-core is enabled and the workspace clearly contains MEMORY.md and memory/*.md.

From source, memory-core appears to expose these as public artifacts:

  • MEMORY.md / memory.md => memory-root
  • memory/*.md => daily-note
  • memory/dreaming/*.md => dream-report
  • event log => event-log

But at runtime, memory-wiki sees zero bridge artifacts and imports nothing.

Root Cause

memory-wiki in bridge mode stays empty and reports bridge-artifacts-missing, even when memory-core is enabled and the workspace clearly contains MEMORY.md and memory/*.md.

From source, memory-core appears to expose these as public artifacts:

  • MEMORY.md / memory.md => memory-root
  • memory/*.md => daily-note
  • memory/dreaming/*.md => dream-report
  • event log => event-log

But at runtime, memory-wiki sees zero bridge artifacts and imports nothing.

PR fix notes

PR #63765: fix: preserve active memory capability across plugin loader state restores

Description (problem / solution / changelog)

Summary

Fix memory-wiki bridge imports staying empty when the plugin loader restores memory-related state without restoring the active memory capability registration.

Root cause

memory-wiki bridge reads public artifacts from the active memory capability registration in memoryPluginState.capability.

The plugin loader was already snapshotting and restoring other memory-related state, but it did not preserve the active memory capability in two places:

  1. cached plugin registry snapshot / restore
  2. temporary memory-state preservation around plugin registration during non-activating loads and register failures

That could leave bridge-visible public artifacts unavailable even when memory-core was active and exporting them correctly.

Changes

  • cache and restore memoryCapability in src/plugins/loader.ts
  • preserve and restore the active memory capability around plugin registration
  • add loader tests covering both non-activating loads and cached registry restores

Validation

Local runtime validation before the source patch reproduced:

  • openclaw wiki status --jsonbridgePublicArtifactCount: 0
  • openclaw wiki bridge import --jsonartifactCount: 0, workspaces: 0

After applying the fix locally:

  • openclaw wiki status --jsonbridgePublicArtifactCount: 145
  • openclaw wiki bridge import --json discovered real bridge source pages/artifacts

Source validation:

  • targeted loader tests passed locally
  • codex review --base origin/main did not identify a discrete regression introduced by this patch

AI assistance

  • AI-assisted: yes
  • Testing: targeted local loader tests passed
  • Additional validation: local runtime reproduction and validation of openclaw wiki status --json / openclaw wiki bridge import --json
  • Full repo test suite: not run in this environment

Linked issues

Fixes #63092 Related to #63197

Changed files

  • src/plugins/loader.test.ts (modified, +79/-1)
  • src/plugins/loader.ts (modified, +7/-0)

Code Example

plugins.entries["memory-wiki"] = {
  enabled: true,
  config: {
    vaultMode: "bridge",
    vault: {
      path: "~/.openclaw/wiki/main",
      renderMode: "obsidian"
    },
    bridge: {
      enabled: true,
      readMemoryArtifacts: true,
      indexDreamReports: true,
      indexDailyNotes: true,
      indexMemoryRoot: true,
      followMemoryEvents: true
    },
    ingest: {
      autoCompile: true
    },
    search: {
      backend: "shared",
      corpus: "all"
    },
    render: {
      preserveHumanBlocks: true,
      createBacklinks: true,
      createDashboards: true
    }
  }
}

---

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

---

{
  "importedCount": 0,
  "updatedCount": 0,
  "artifactCount": 0
}
RAW_BUFFERClick to expand / collapse

Summary

memory-wiki in bridge mode stays empty and reports bridge-artifacts-missing, even when memory-core is enabled and the workspace clearly contains MEMORY.md and memory/*.md.

From source, memory-core appears to expose these as public artifacts:

  • MEMORY.md / memory.md => memory-root
  • memory/*.md => daily-note
  • memory/dreaming/*.md => dream-report
  • event log => event-log

But at runtime, memory-wiki sees zero bridge artifacts and imports nothing.

Environment

  • OpenClaw: 2026.4.7
  • memory-core: enabled
  • memory-wiki: enabled
  • lossless-claw: enabled
  • vault mode: bridge
  • render mode: obsidian

Config

memory-wiki was configured roughly like:

plugins.entries["memory-wiki"] = {
  enabled: true,
  config: {
    vaultMode: "bridge",
    vault: {
      path: "~/.openclaw/wiki/main",
      renderMode: "obsidian"
    },
    bridge: {
      enabled: true,
      readMemoryArtifacts: true,
      indexDreamReports: true,
      indexDailyNotes: true,
      indexMemoryRoot: true,
      followMemoryEvents: true
    },
    ingest: {
      autoCompile: true
    },
    search: {
      backend: "shared",
      corpus: "all"
    },
    render: {
      preserveHumanBlocks: true,
      createBacklinks: true,
      createDashboards: true
    }
  }
}

memory-core had dreaming enabled.

Repro

  1. Enable memory-core
  2. Create/populate:
    • MEMORY.md
    • memory/YYYY-MM-DD.md
  3. Enable memory-wiki in bridge mode with:
    • bridge.enabled = true
    • bridge.readMemoryArtifacts = true
    • bridge.indexDreamReports = true
    • bridge.indexDailyNotes = true
    • bridge.indexMemoryRoot = true
    • bridge.followMemoryEvents = true
  4. Restart gateway
  5. Run:
    openclaw wiki status --json
    openclaw wiki bridge import --json
    openclaw wiki compile --json

Actual behavior

openclaw wiki status --json reports:

  • bridgePublicArtifactCount: 0
  • warning: bridge-artifacts-missing

openclaw wiki bridge import --json returns:

{
  "importedCount": 0,
  "updatedCount": 0,
  "artifactCount": 0
}

The vault initializes, but only default report pages exist. No source/entity/concept pages are created from memory artifacts.

Expected behavior

In bridge mode, memory-wiki should import at least:

  • MEMORY.md as a memory-root source
  • memory/*.md as daily-note sources
  • memory/dreaming/*.md as dream-report sources when present
  • memory event logs when available

Given the current docs and memory-core source, bridge mode should not be empty in this setup.

Notes

From memory-core source, public artifact listing appears to exist via:

  • collectWorkspaceArtifacts(...)
  • listMemoryCorePublicArtifacts(...)
  • plugin registration including:
    • publicArtifacts: { listArtifacts: ... }

So this looks like either:

  • a bridge import bug
  • a plugin wiring/runtime registration issue
  • workspace resolution mismatch between memory-core and memory-wiki

Question

Is there an additional config gate needed to make memory-core publish bridge-visible artifacts, or is this a regression in memory-wiki bridge mode?

extent analysis

TL;DR

The issue might be resolved by verifying the plugin registration and workspace resolution between memory-core and memory-wiki, ensuring that memory-core publishes bridge-visible artifacts.

Guidance

  • Review the memory-core plugin registration to ensure it correctly exposes public artifacts, such as MEMORY.md, memory/*.md, and memory/dreaming/*.md, as memory-root, daily-note, and dream-report sources, respectively.
  • Check the workspace resolution configuration to confirm that memory-wiki can access the artifacts published by memory-core.
  • Verify that the collectWorkspaceArtifacts and listMemoryCorePublicArtifacts functions are correctly implemented and called in the memory-core plugin.
  • Ensure that the publicArtifacts listing is properly registered in the plugin, including the listArtifacts function.

Example

No code snippet is provided as the issue does not contain sufficient information to generate a specific example.

Notes

The issue may be caused by a plugin wiring or runtime registration issue, or a workspace resolution mismatch between memory-core and memory-wiki. Further investigation is needed to determine the root cause.

Recommendation

Apply a workaround by manually verifying the plugin registration and workspace resolution configuration to ensure that memory-core publishes bridge-visible artifacts and memory-wiki can access them. This approach allows for a more detailed analysis of the issue without making assumptions about the underlying cause.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

In bridge mode, memory-wiki should import at least:

  • MEMORY.md as a memory-root source
  • memory/*.md as daily-note sources
  • memory/dreaming/*.md as dream-report sources when present
  • memory event logs when available

Given the current docs and memory-core source, bridge mode should not be empty in this setup.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING