Honcho memory plugin missing publicArtifacts capability for Wiki Bridge mode
Summary
When using openclaw-honcho as the active memory plugin slot (plugins.slots.memory = "openclaw-honcho"), the Wiki Bridge reports zero exported artifacts even though:
- Honcho is healthy and running (Docker services up, PostgreSQL/Redis/Deriver all operational)
- Memory data exists across workspaces (session exports, daily notes, etc.)
- The documented QMD + bridge-mode hybrid setup is configured correctly
memory-wiki in bridge mode successfully imports artifacts when using memory-core as the slot
The root cause appears to be that Honcho does not implement or expose the publicArtifacts.listArtifacts capability that the Wiki Bridge plugin SDK expects from the active memory plugin.
Expected behavior
When plugins.entries["memory-wiki"].config.vaultMode = "bridge" and plugins.slots.memory = "openclaw-honcho":
openclaw wiki status should report nonzero bridgePublicArtifactCount
openclaw wiki bridge import should detect and import artifacts from Honcho workspaces
- The Wiki Bridge should be able to compile Honcho memory data (session exports, daily notes, dream reports) into durable wiki pages
Actual behavior
Wiki vault mode: bridge
Bridge: enabled (0 exported artifacts)
Pages: 1 sources, 0 entities, 0 concepts, 8 syntheses, 10 reports
Warning: Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet.
openclaw wiki bridge import --json:
{
"importedCount": 0,
"updatedCount": 0,
"skippedCount": 0,
"removedCount": 0,
"artifactCount": 0,
"workspaces": 0
}
Configuration (our setup)
{
plugins: {
slots: { memory: "openclaw-honcho" }, // ← HONCHO NOT memory-core
entries: {
"memory-wiki": {
enabled: true,
config: {
vaultMode: "bridge",
bridge: { enabled: true, readMemoryArtifacts: true, followMemoryEvents: true, indexDreamReports: true },
search: { backend: "shared", corpus: "all" }
}
},
"openclaw-honcho": {
enabled: true,
config: { baseUrl: "http://localhost:8000", apiKey: "...", workspaceId: "openclaw" }
}
}
},
memory: { backend: "qmd" } // ← QMD as active memory backend
}
Related issues (for memory-core, NOT Honcho)
These issues describe the same symptom but for memory-core as the memory slot:
This issue is specifically about Honcho, which has never been tested for the publicArtifacts capability. The fix for memory-core (forced registration into memory-state singleton) may not apply to Honcho since it's a Dockerized service with different architecture.
Proposed solution
- Add
publicArtifacts.listArtifacts capability to Honcho — expose an endpoint or SDK method that returns exported memory artifacts in the format expected by Wiki Bridge
- Register this capability via
registerMemoryCapability() in the OpenClaw plugin SDK
- Update documentation to clarify that not all memory plugins support bridge mode out of the box
Workaround (for our setup)
Until Honcho implements this capability, use isolated mode for Wiki:
plugins.entries["memory-wiki"].config.vaultMode = "isolated" // instead of "bridge"
Or manually maintain wiki pages via wiki_apply as we've been doing. This is functional but loses the automated bridge sync.
Impact
- The recommended QMD + Honcho + Wiki Bridge hybrid setup (documented in OpenClaw docs) does NOT work when using Honcho as the memory slot
- Users following the documented pattern will encounter "0 exported artifacts" and have no clear path forward
- This is a missing capability, not a configuration issue
Environment
- OpenClaw version: 2026.5.7
- Memory backend: QMD
- Active memory plugin: openclaw-honcho (Dockerized)
- Wiki mode: bridge
- Honcho services: API, PostgreSQL, Redis, Deriver, Prometheus, Grafana — all running
Honcho memory plugin missing publicArtifacts capability for Wiki Bridge mode
Summary
When using
openclaw-honchoas the active memory plugin slot (plugins.slots.memory = "openclaw-honcho"), the Wiki Bridge reports zero exported artifacts even though:memory-wikiin bridge mode successfully imports artifacts when usingmemory-coreas the slotThe root cause appears to be that Honcho does not implement or expose the
publicArtifacts.listArtifactscapability that the Wiki Bridge plugin SDK expects from the active memory plugin.Expected behavior
When
plugins.entries["memory-wiki"].config.vaultMode = "bridge"andplugins.slots.memory = "openclaw-honcho":openclaw wiki statusshould report nonzerobridgePublicArtifactCountopenclaw wiki bridge importshould detect and import artifacts from Honcho workspacesActual behavior
openclaw wiki bridge import --json:{ "importedCount": 0, "updatedCount": 0, "skippedCount": 0, "removedCount": 0, "artifactCount": 0, "workspaces": 0 }Configuration (our setup)
Related issues (for memory-core, NOT Honcho)
These issues describe the same symptom but for
memory-coreas the memory slot:openclaw wiki bridge importalways returns 0 artifacts — CLI does not initialize memory-core plugin runtime #65722 — "openclaw wiki bridge importalways returns 0 artifacts — CLI does not initialize memory-core plugin runtime"This issue is specifically about Honcho, which has never been tested for the
publicArtifactscapability. The fix formemory-core(forced registration into memory-state singleton) may not apply to Honcho since it's a Dockerized service with different architecture.Proposed solution
publicArtifacts.listArtifactscapability to Honcho — expose an endpoint or SDK method that returns exported memory artifacts in the format expected by Wiki BridgeregisterMemoryCapability()in the OpenClaw plugin SDKWorkaround (for our setup)
Until Honcho implements this capability, use isolated mode for Wiki:
Or manually maintain wiki pages via
wiki_applyas we've been doing. This is functional but loses the automated bridge sync.Impact
Environment