Summary

• Problem: openclaw wiki bridge import always returns 0 artifacts, even when openclaw gateway call wiki.bridge.import against the same store returns the real count. openclaw wiki doctor then falsely warns that memory-core is not exporting any public artifacts.
• Why it matters: users (and the doctor report) conclude their bridge configuration or dreaming pipeline is broken when it is actually fine. The CLI / gateway-RPC mismatch is hard to diagnose without reading the plugin registration code.
• What changed: runWikiBridgeImport now calls the wiki.bridge.import gateway RPC via callGatewayFromCli instead of invoking syncMemoryWikiImportedSources in-process. addGatewayClientOptions is attached to the wiki bridge import subcommand so users can point at a remote gateway or pass an explicit token. Error path surfaces a clear "gateway running?" message instead of a silent 0.
• What did NOT change (scope boundary): other wiki CLI commands (wiki status, wiki doctor, wiki unsafe-local import) still run in-process and are out of scope for this PR. The gateway RPC handler, the sync implementation, and memory-core's capability registration are all untouched.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: memory-wiki: openclaw wiki bridge import CLI returns 0 artifacts while openclaw gateway call wiki.bridge.import works correctly #67190
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: registerMemoryCapability — which populates memoryPluginState.capability.capability.publicArtifacts.listArtifacts — runs inside memory-core's register() hook, which only fires in the gateway daemon process. The CLI command path loads each plugin's cli-metadata.js to wire subcommands but does not execute the full plugin register() flow. Result: in a fresh CLI subprocess, memoryPluginState.capability is undefined and listActiveMemoryPublicArtifacts short-circuits to []. The gateway RPC handler wiki.bridge.import works because it runs inside the daemon where the capability is already registered.
• Missing detection / guardrail: no test covered the "CLI subprocess → memory-core capability" boundary, so the in-process path silently returned an empty result instead of failing loudly.
• Contributing context (if known): listActiveMemoryPublicArtifacts intentionally degrades gracefully to [] when the capability is absent — that is correct for plugin-aware callers inside the daemon, but catastrophic for a CLI entrypoint expecting artifacts.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/memory-wiki/src/cli.test.ts (new describe("runWikiBridgeImport", ...) block).
• Scenario the test should lock in: runWikiBridgeImport must call callGatewayFromCli("wiki.bridge.import", ...) with forwarded opts and render Bridge import synced N artifacts...; it must throw a clear "gateway running?" error when the RPC returns nothing.
• Why this is the smallest reliable guardrail: the bug is about which code path the CLI takes, not about the sync implementation itself. A unit test with an injected callGateway mock catches any future regression that reroutes the command back to the in-process sync helper.
• Existing test that already covers this (if any): None — prior to this PR, runWikiBridgeImport had no direct test.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• openclaw wiki bridge import now reports the same importedCount / artifactCount as openclaw gateway call wiki.bridge.import for the same store.
• openclaw wiki bridge import --help now lists --url, --token, --timeout, --expect-final in addition to --json (from addGatewayClientOptions).
• When the gateway is not running, the CLI now errors loudly with a WebSocket connection failure (and a "gateway running?" hint if the RPC returns an empty response) instead of silently printing 0 artifacts.
• No config, no persisted state, no protocol changes.

Diagram (if applicable)

Before:
[openclaw wiki bridge import] -> [CLI subprocess]
                              -> [syncMemoryWikiImportedSources] (in-process)
                              -> [listActiveMemoryPublicArtifacts]
                              -> [memoryPluginState.capability = undefined]
                              -> [returns []] -> "0 artifacts" (silent false negative)

[openclaw gateway call wiki.bridge.import] -> [gateway daemon]
                                           -> [syncMemoryWikiImportedSources]
                                           -> [capability registered] -> "N artifacts"

After:
[openclaw wiki bridge import] -> [CLI subprocess]
                              -> [callGatewayFromCli("wiki.bridge.import")]
                              -> [gateway daemon RPC handler]
                              -> [syncMemoryWikiImportedSources]
                              -> [capability registered] -> "N artifacts"

[openclaw wiki bridge import] with gateway down -> [WebSocket connection error] (loud failure)

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No — the new --token flag on the subcommand uses the same addGatewayClientOptions surface already used by other CLI commands (browser, qa-lab).
• New/changed network calls? Yes, but same target: the CLI now opens a WebSocket to the local gateway instead of calling the in-process sync helper. The RPC target, scope, and payload are identical to the existing wiki.bridge.import method that has been shipped for prior releases.
• Command/tool execution surface changed? No
• Data access scope changed? No — the RPC handler uses WRITE_SCOPE, same as before. Anyone who could already run the CLI locally already had that authority.

Repro + Verification

Environment

• OS: Linux (also reproduced on Debian 13 in the issue)
• Runtime/container: local pnpm openclaw gateway --force, memory-wiki extension bundled
• Model/provider: N/A (CLI only)
• Integration/channel (if any): memory-core bridge mode (vaultMode: "bridge", all bridge flags enabled)
• Relevant config (redacted): plugins.entries.memory-wiki.config.vaultMode = "bridge"

Steps

1. Start gateway: pnpm openclaw gateway --force
2. Run pnpm openclaw wiki bridge import --json
3. Compare to pnpm openclaw gateway call wiki.bridge.import --json
4. Stop the gateway and re-run pnpm openclaw wiki bridge import to exercise the failure path

Expected

• Step 2 and step 3 print identical importedCount / artifactCount
• Step 4 prints a clear WebSocket/"gateway running?" error instead of 0 artifacts
• pnpm openclaw wiki bridge import --help lists --url, --token, --timeout, --expect-final

Actual

• Matches expected. Verified via unit tests that mock callGatewayFromCli and assert both the happy path and the empty-result error path (extensions/memory-wiki/src/cli.test.ts).

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

$ pnpm test extensions/memory-wiki/src/cli.test.ts
 Test Files  1 passed (1)
      Tests  6 passed (6)

$ pnpm check
... (tsgo, oxlint, import-cycles, madge-import-cycles, host-env-policy all green)

Human Verification (required)

• Verified scenarios:
  • runWikiBridgeImport now routes through the mocked callGatewayFromCli with "wiki.bridge.import" as the method and forwards url / token / json opts
  • Renders Bridge import synced N artifacts across W workspaces (...) output from the RPC result
  • Throws a "gateway running?" error when the RPC returns undefined
• Edge cases checked:
  • Gateway RPC opts come through the Commander subcommand (WikiBridgeImportCommandOptions now extends GatewayRpcOpts)
  • Empty/missing gatewayOpts still works (spread handles undefined)
  • Other wiki CLI commands that share syncMemoryWikiImportedSources are unchanged
• What you did not verify:
  • Live gateway round-trip against a store with real dreaming-narrative memory artifacts — the local test store had no indexed artifacts. Unit tests cover the routing contract; the live end-to-end path is identical to the already-working gateway call wiki.bridge.import the issue author validated.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes — runWikiBridgeImport keeps its exported signature (new fields are optional), and the command name / output format are unchanged.
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Users who ran openclaw wiki bridge import without a running gateway used to get a silent 0 artifacts result; they will now get a loud WebSocket error.
  • Mitigation: That prior behavior was the bug. The loud error is the correct outcome and matches how callGatewayFromCli already behaves in other CLI commands (browser, qa-lab). The error message explicitly hints at the gateway.
• Risk: Test-only injection seam (callGateway? param) leaks into the public signature of runWikiBridgeImport.
  • Mitigation: Field is optional, typed against the same callGatewayFromCli contract from openclaw/plugin-sdk/browser-node-runtime, and documented inline. Production callers pass nothing and get the real runtime.