Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: memory-wiki bridge imports 0 artifacts from memory-core [2 pull requests, 3 comments, 3 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#63092•Fetched 2026-04-09 07:58:42
View on GitHub
Comments
3
Participants
3
Timeline
10
Reactions
0
Author
hs58359803hs58359803
Participants
hs58359803hs58359803imadal1nimadal1nkitfuchskitfuchs
Timeline (top)
commented ×3subscribed ×3labeled ×2mentioned ×1

With memory-wiki enabled in bridge mode and memory-core active, the wiki vault initializes successfully but bridge import consistently finds 0 artifacts and 0 workspaces.

Root Cause

Affected: users trying to use memory-wiki bridge with memory-core as the active memory plugin Severity: Medium, because bridge mode appears enabled and healthy but produces no imported knowledge Frequency: 100% in observed tests Consequence: users may assume bridge mode is working, but no wiki content is imported from memory-core, which blocks the intended automatic knowledge compilation workflow

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 --json → bridgePublicArtifactCount: 0
  • openclaw wiki bridge import --json → artifactCount: 0, workspaces: 0

After applying the fix locally:

  • openclaw wiki status --json → bridgePublicArtifactCount: 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)

PR #64269: fix(memory-wiki): load runtime plugins before bridge artifact listing

Description (problem / solution / changelog)

Summary

  • ensure runtime plugins are loaded before bridge artifact listing in
  • fix false zero-artifact results in fresh CLI/status/import processes
  • keep bridge behavior aligned with the active runtime plugin state

Validation

  • Ran targeted tests:

  • All passed (17 tests)

Related

  • Fixes / addresses #63092

Changed files

  • src/memory-host-sdk/runtime-core.ts (modified, +19/-4)

Code Example

`openclaw wiki status` output:

Wiki vault mode: bridge
Vault: ready (/home/ubuntu/.openclaw/wiki/main)
Render mode: native
Obsidian CLI: missing
Bridge: enabled (0 exported artifacts)
Unsafe local: disabled
Pages: 0 sources, 0 entities, 0 concepts, 0 syntheses, 5 reports
Source provenance: 0 native, 0 bridge, 0 bridge-events, 0 unsafe-local, 0 other

Warnings:
- Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet.

`openclaw wiki bridge import` output:

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

Relevant config:


{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "0 17 * * *"
          }
        }
      },
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          vault: {
            path: "~/.openclaw/wiki/main",
            renderMode: "native"
          },
          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true
          },
          ingest: {
            autoCompile: true,
            maxConcurrentJobs: 1,
            allowUrlIngest: true
          },
          search: {
            backend: "shared",
            corpus: "all"
          },
          context: {
            includeCompiledDigestPrompt: false
          },
          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,
            createDashboards: true
          }
        }
      }
    }
  }
}
openclaw doctor did not report an obvious configuration problem.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

With memory-wiki enabled in bridge mode and memory-core active, the wiki vault initializes successfully but bridge import consistently finds 0 artifacts and 0 workspaces.

Steps to reproduce

  1. Enable memory-wiki in bridge mode in openclaw.json while keeping memory-core enabled.
  2. Restart the gateway after applying the config.
  3. Run openclaw wiki status.
  4. Run openclaw wiki bridge import.
  5. Observe that the wiki vault is ready, but bridge import reports 0 artifacts across 0 workspaces.

Expected behavior

When memory-wiki is enabled in bridge mode with memory-core as the active memory plugin, bridge import should discover at least some public memory artifacts or the docs should clearly describe what additional conditions are required before any artifacts become available.

Actual behavior

The wiki vault is created successfully and reports are generated, but openclaw wiki bridge import reports synced 0 artifacts across 0 workspaces, and openclaw wiki status warns that the active memory plugin is not exporting any public memory artifacts yet.

OpenClaw version

2026.4.8

Operating system

Ubuntu 24.04

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> gateway local runtime -> openai-codex

Additional provider/model setup details

The issue does not appear model-specific. The effective chat model in this environment is openai-codex/gpt-5.4. The active memory plugin is memory-core, and memory-wiki is enabled in bridge mode with search.backend: shared and search.corpus: all.

Logs, screenshots, and evidence

`openclaw wiki status` output:

Wiki vault mode: bridge
Vault: ready (/home/ubuntu/.openclaw/wiki/main)
Render mode: native
Obsidian CLI: missing
Bridge: enabled (0 exported artifacts)
Unsafe local: disabled
Pages: 0 sources, 0 entities, 0 concepts, 0 syntheses, 5 reports
Source provenance: 0 native, 0 bridge, 0 bridge-events, 0 unsafe-local, 0 other

Warnings:
- Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet.

`openclaw wiki bridge import` output:

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

Relevant config:


{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "0 17 * * *"
          }
        }
      },
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          vault: {
            path: "~/.openclaw/wiki/main",
            renderMode: "native"
          },
          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true
          },
          ingest: {
            autoCompile: true,
            maxConcurrentJobs: 1,
            allowUrlIngest: true
          },
          search: {
            backend: "shared",
            corpus: "all"
          },
          context: {
            includeCompiledDigestPrompt: false
          },
          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,
            createDashboards: true
          }
        }
      }
    }
  }
}
openclaw doctor did not report an obvious configuration problem.

Impact and severity

Affected: users trying to use memory-wiki bridge with memory-core as the active memory plugin Severity: Medium, because bridge mode appears enabled and healthy but produces no imported knowledge Frequency: 100% in observed tests Consequence: users may assume bridge mode is working, but no wiki content is imported from memory-core, which blocks the intended automatic knowledge compilation workflow

Additional information

This was tested specifically to avoid maintaining a separate wiki by hand. The intended workflow is to keep using project AGENTS.md and memory files as the primary source of truth, and let memory-wiki bridge compile them automatically. If this behavior is expected, it would help if the docs explicitly described what conditions are required before bridge mode can see exported/public memory artifacts from memory-core.

extent analysis

TL;DR

The most likely fix is to verify the configuration and ensure that memory-core is exporting public memory artifacts, as the current setup seems to be missing this crucial step.

Guidance

  • Review the memory-core configuration to ensure it is set up to export public memory artifacts, as the warning message suggests this is not happening.
  • Check the openclaw wiki status output to confirm the bridge mode is enabled and the vault is ready, but focus on resolving the "active memory plugin is not exporting any public memory artifacts yet" warning.
  • Investigate the memory-wiki bridge configuration, specifically the bridge section, to ensure that it is correctly set up to read memory artifacts from memory-core.
  • Consider running openclaw doctor again to see if it provides any additional insights or suggestions for resolving the issue.

Example

No specific code example is provided, as the issue seems to be related to configuration rather than code.

Notes

The issue seems to be related to the interaction between memory-wiki and memory-core, and resolving the warning about memory-core not exporting public memory artifacts is likely key to fixing the problem. The documentation for memory-wiki and memory-core should be consulted to ensure that all necessary configuration steps have been taken.

Recommendation

Apply a workaround by re-checking and adjusting the memory-core and memory-wiki configurations to ensure that memory-core is exporting public memory artifacts and that memory-wiki is correctly set up to read these artifacts. This is recommended because the issue seems to be related to a misconfiguration rather than a bug in the software.

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

When memory-wiki is enabled in bridge mode with memory-core as the active memory plugin, bridge import should discover at least some public memory artifacts or the docs should clearly describe what additional conditions are required before any artifacts become available.

#task chaining#parallel task#integration issue#index setup#retrieval issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING