Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix CLI `wiki bridge import` returns 0 artifacts while runtime bridge works correctly [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#70181•Fetched 2026-04-23 07:28:09
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
prasad-yashdeepprasad-yashdeep
Participants
prasad-yashdeepprasad-yashdeep
Timeline (top)
cross-referenced ×1referenced ×1

openclaw wiki bridge import (CLI) returns 0 artifacts across 0 workspaces and removes previously synced bridge sources, while the runtime bridge (in-process wiki_status tool) correctly sees all artifacts.

Root Cause

The CLI standalone process calls listActiveMemoryPublicArtifacts but the memory-core plugin does not wire up its public artifacts export for out-of-process (CLI) invocations. The runtime (in-process) path works because the memory plugin is fully initialized in the gateway process.

This means every CLI wiki bridge import invocation destructively removes all bridge-sourced pages (155 removed in the example above), which are then only restored when the runtime bridge runs again.

Fix Action

Workaround

Avoid running openclaw wiki bridge import from the CLI. The runtime bridge handles sync correctly in-process.

PR fix notes

PR #70185: fix(wiki): register memory publicArtifacts in CLI-metadata mode

Description (problem / solution / changelog)

Problem

openclaw wiki bridge import always returns 0 artifacts / 0 workspaces and destructively removes previously-synced bridge sources — even though the in-process runtime bridge works perfectly with 155+ artifacts.

Root cause

The CLI process loads plugin cli-metadata.ts entries (lightweight) instead of the full index.ts. The memory-core cli-metadata.ts only registered CLI commands and never called registerMemoryCapability(), so memoryPluginState.capability stayed empty. When the wiki bridge called listActiveMemoryPublicArtifacts(), it got nothing back.

Additionally, the CLI-metadata plugin loader in loader.ts only wired registerCli as a handler — registerMemoryCapability defaulted to a no-op, so even if the plugin tried to register, it would be silently swallowed.

Fix

Two changes:

  1. extensions/memory-core/cli-metadata.ts: Register the publicArtifacts provider (via listMemoryCorePublicArtifacts) and declare kind: "memory" so the memory slot resolution accepts it.

  2. src/plugins/loader.ts: Wire registerMemoryCapability in the CLI-metadata buildPluginApi handlers (with the same hasKind guard used in full registration) so the call actually reaches memoryPluginState.

Testing

  • All 6 bridge.test.ts tests pass ✅
  • All 105 loader.test.ts tests pass ✅
  • Zero new type errors (6 pre-existing errors in pi-embedded-runner are unrelated)

Fixes #70181

Changed files

  • extensions/memory-core/cli-metadata.ts (modified, +10/-0)
  • src/plugins/loader.ts (modified, +28/-0)

Code Example

# CLI — broken
$ openclaw wiki bridge import
Bridge import synced 0 artifacts across 0 workspaces (0 new, 0 updated, 0 unchanged, 155 removed). Indexes refreshed (4 files).

$ openclaw wiki status
Bridge: enabled (0 exported artifacts)
Pages: 147 sources, 0 bridge provenance

---

Bridge: enabled (155 exported artifacts)
Pages: 302 sources, 149 bridge provenance
RAW_BUFFERClick to expand / collapse

Description

openclaw wiki bridge import (CLI) returns 0 artifacts across 0 workspaces and removes previously synced bridge sources, while the runtime bridge (in-process wiki_status tool) correctly sees all artifacts.

Reproduction

# CLI — broken
$ openclaw wiki bridge import
Bridge import synced 0 artifacts across 0 workspaces (0 new, 0 updated, 0 unchanged, 155 removed). Indexes refreshed (4 files).

$ openclaw wiki status
Bridge: enabled (0 exported artifacts)
Pages: 147 sources, 0 bridge provenance

Meanwhile, the in-process runtime tool returns:

Bridge: enabled (155 exported artifacts)
Pages: 302 sources, 149 bridge provenance

Analysis

The CLI standalone process calls listActiveMemoryPublicArtifacts but the memory-core plugin does not wire up its public artifacts export for out-of-process (CLI) invocations. The runtime (in-process) path works because the memory plugin is fully initialized in the gateway process.

This means every CLI wiki bridge import invocation destructively removes all bridge-sourced pages (155 removed in the example above), which are then only restored when the runtime bridge runs again.

Environment

  • OpenClaw version: 2026.4.21 (f788c88)
  • OS: macOS (Darwin 25.2.0, arm64)
  • Node: v22.22.0
  • Wiki vault mode: bridge

Expected Behavior

CLI wiki bridge import should see the same artifacts as the runtime bridge and sync them correctly.

Workaround

Avoid running openclaw wiki bridge import from the CLI. The runtime bridge handles sync correctly in-process.

extent analysis

TL;DR

Avoid running openclaw wiki bridge import from the CLI to prevent removal of bridge-sourced pages, and rely on the runtime bridge for correct syncing.

Guidance

  • The issue is caused by the memory-core plugin not exporting public artifacts for out-of-process CLI invocations, leading to destructive removal of bridge-sourced pages.
  • To verify the issue, compare the output of openclaw wiki bridge import and openclaw wiki status with the output of the in-process runtime tool.
  • As a workaround, avoid using the CLI command and rely on the runtime bridge to handle syncing, as it correctly initializes the memory plugin.
  • Consider monitoring the OpenClaw version for updates that may address this issue, as the current version (2026.4.21) has this limitation.

Example

No code snippet is provided, as the issue is related to the interaction between the CLI and the runtime bridge, and not a specific code snippet.

Notes

This workaround may not be suitable for all use cases, especially those relying heavily on the CLI for automation or scripting. The runtime bridge's correct functioning is dependent on the memory plugin being fully initialized in the gateway process.

Recommendation

Apply the workaround and avoid using openclaw wiki bridge import from the CLI, as it is the safest approach given the current version's limitations.

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…
#optimization#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix CLI `wiki bridge import` returns 0 artifacts while runtime bridge works correctly [1 pull requests, 1 participants]