Greptile Summary

Adds loadPlugins: "always" to the wiki and memory command paths in the CLI command catalog, matching the pattern already used by agent, message, channels, directory, agents, and configure. This fixes a production regression where wiki bridge import would see 0 artifacts because memory-core was not loaded under the default "never" policy.

Confidence Score: 5/5

Safe to merge — minimal, targeted one-file fix that follows the established catalog pattern and addresses a confirmed production data-loss incident.

The change is two lines, follows an identical pattern already used by six other commands, and the PR description includes direct verification of the fix (186 artifacts returned after the change vs. 0 before). No logic, tests, or interfaces are modified.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix: load all plugins for wiki and memor..." | Re-trigger Greptile}

We hit the exact same bug on OpenClaw v2026.4.15. wiki bridge import always returns 0 artifacts even though our workspace has MEMORY.md and a populated memory/ directory. Confirmed both CLI and gateway RPC (openclaw gateway call wiki.bridge.import) return empty artifact lists.

Root cause matches what this PR fixes: memoryPluginState.capability (which holds publicArtifacts.listArtifacts) is never registered during plugin load, so listActiveMemoryPublicArtifacts returns [].

Current workaround: switching vaultMode to unsafe-local with explicit paths works fine and gives us 118 imported wiki source pages. Looking forward to this landing so we can use bridge mode again.

Related work from PRtags group cheerful-ox-0bzt

Title: Open PR duplicate: memory capability lost across plugin scopes

* This PR

Codex automated review: keeping this open.

Current main only partially covers this PR. The loader-side memory capability preservation and bridge no-prune safety are present, but the cold openclaw wiki bridge import CLI path can still load only the memory-wiki plugin and call the in-process bridge sync without registering the active memory plugin's public-artifacts capability. This PR should stay open for maintainer reconciliation, but it should not merge unchanged.

Best possible solution:

Keep this PR open for maintainer reconciliation. Rebase it onto current main, drop the loader hunk already covered there, and replace or justify the broad command-catalog preload with a narrow tested fix: either include the configured active memory slot plugin for wiki primary CLI loads while honoring slots.memory = none and allow/disable rules, or route wiki bridge import through the existing wiki.bridge.import gateway RPC. Add focused regression coverage in src/plugins/cli.test.ts and/or extensions/memory-wiki/src/cli.test.ts, then close this PR only after the chosen canonical PR lands or this PR is updated to that shape.

What I checked:

• Current main still has no wiki/memory startup preload policy: The command catalog lists explicit preload policies for command roots such as agent, channels, directory, and agents, but there is no wiki or memory entry on current main. Unmatched command paths inherit the default loadPlugins: "never" policy. (src/cli/command-catalog.ts:34, 66f4b52db31b)
• Default policy prevents startup plugin loading for unmatched commands: resolveCliCommandPathPolicy starts from loadPlugins: "never"; shouldLoadPluginsForCommandPath only returns true for always or non-JSON text-only. Without a wiki/memory catalog entry, startup plugin preloading still does not happen for those roots. (src/cli/command-path-policy.ts:5, 66f4b52db31b)
• Scoped plugin CLI loading still does not append the memory slot: Primary-command scoped loading resolves manifest activation ids for the primary command and passes them as onlyPluginIds; there is no current code that appends the configured plugins.slots.memory id for wiki loads. The manifests show memory-wiki owns the wiki command alias while memory-core advertises cliCommand: "memory", so a wiki-scoped cold CLI load does not inherently include memory-core. (src/plugins/cli-registry-loader.ts:51, 66f4b52db31b)
• Bridge import still runs in-process and depends on active memory artifacts: runWikiBridgeImport still calls syncMemoryWikiImportedSources directly. The bridge path reads artifacts through listActiveMemoryPublicArtifacts, which returns an empty list when no memory capability is registered in the current process. That preserves the 0-artifact failure mode even though pruning is now skipped when the capability is absent. (extensions/memory-wiki/src/cli.ts:502, 66f4b52db31b)
• Loader-side capability preservation is already on main: Current main stores/restores memoryCapability in the plugin loader cache and snapshots previousMemoryCapability around non-activating and rollback loads. Regression tests cover cached capability restoration and preservation across activate:false snapshot loads, so the loader hunk in this PR is already redundant. (src/plugins/loader.ts:216, 66f4b52db31b)
• User-facing docs still describe bridge import as importing active memory plugin artifacts: The CLI docs say wiki bridge import imports public memory artifacts from the active memory plugin into bridge-backed source pages. The current in-process cold CLI path does not reliably satisfy that contract when the active memory plugin was not registered. Public docs: docs/cli/wiki.md. (docs/cli/wiki.md:163, 66f4b52db31b)

Remaining risk / open question:

• Closing this PR now would drop a still-relevant wiki bridge import 0-artifact regression on current main.
• Merging unchanged would duplicate loader-side memory capability work that is already present and tested on main.
• The command-catalog hunk broadly loads plugins for every wiki and memory command. That may be a larger execution-surface change than needed; a narrower configured-memory-slot inclusion or gateway-RPC route is safer to review and test.
• Related work is fragmented: fix(memory): keep active memory capability visible across plugin scopes #69458 remains the closest open capability-scope PR in the provided context, while fix(plugins): include memory slot plugin in primary wiki CLI scope #67063, fix(memory-wiki): route wiki bridge import CLI through gateway RPC #67208, and fix(wiki): load memory-core plugin runtime before bridge artifact import #69952 were closed unmerged. Maintainers should choose one canonical path before closing the rest.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against 66f4b52db31b.

Thanks for digging into this. We landed the narrower Gateway-routing fix in #72615, which closes the Memory Wiki bridge 0-artifacts reports without widening CLI plugin loading or loader state behavior here. Closing this as superseded by that PR.