Honcho and memory-wiki | Friends of the Crustacean 🦞🤝 | Page 1

timber verge Apr 13, 2026, 11:29 AM

#

So I enabled honcho and memory-wiki, but running openclaw wiki status it shows

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

lime spokeBOT Apr 13, 2026, 11:29 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

little pulsarBOT Apr 13, 2026, 11:29 AM

#

ivory umbraBOT Apr 13, 2026, 11:30 AM

#

First, can you paste openclaw --version?

That warning usually means memory-wiki itself is working, but bridge mode has nothing to import.

With current OpenClaw behavior, memory-wiki bridge mode only pulls in public memory artifacts exported by the active memory plugin. Honcho stores memory in the Honcho service, and it does not appear to export those bridge artifacts, so this warning is expected:

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

So the practical options are:

Use Honcho + memory-wiki in isolated mode if you just want the wiki
Use a memory plugin that exports public artifacts if you specifically want bridge mode behavior

Docs:

#

If you paste your version plus your plugins.entries config for Honcho + memory-wiki, I can tell you the cleanest exact config.

timber verge Apr 13, 2026, 11:34 AM

#

openclaw --version
OpenClaw 2026.4.8 (9ece252)

"memory-wiki": {
"enabled": true,
"config": {
"vaultMode": "bridge",
"vault": {
"path": "~/.openclaw/wiki/main",
"renderMode": "obsidian"
},
"obsidian": {
"enabled": true,
"useOfficialCli": true,
"vaultName": "OpenClaw Wiki",
"openAfterWrites": false
},
"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-honcho": {
    "enabled": true,
    "config": {
      "apiKey": "REDACTED",
      "baseUrl": "https://api.honcho.dev",
      "workspaceId": "REDACTED"
    }
  },

ivory umbraBOT Apr 13, 2026, 11:34 AM

#

Yep, with that config on 2026.4.8, this is expected, not a broken setup.

Your config says:

active memory plugin = openclaw-honcho
memory-wiki.vaultMode = bridge

bridge mode only works when the active memory plugin exports public memory artifacts. Honcho currently does not, so wiki status warns correctly.

So the clean answer is:

If you want Honcho + memory-wiki

Switch memory-wiki to isolated mode.

"memory-wiki": {

#

  "enabled": true,
  "config": {
    "vaultMode": "isolated",
    ...
  }
}

I’d also set:

"bridge": {
  "enabled": false
}

#

If you specifically want `bridge` mode

You need an active memory plugin that exports public artifacts, for example the built-in file-based memory path, not Honcho-only.

Also, openclaw wiki bridge import will not fix this with Honcho, because there are no public artifacts for it to import.

Docs:

If you want, paste the rest of your memory config and I can suggest the exact Honcho-friendly memory-wiki config block.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

timber verge Apr 13, 2026, 11:42 AM

#

so there is no way to import current memory into wiki?

ivory umbraBOT Apr 13, 2026, 11:42 AM

#

Not from Honcho’s live memory service directly, no, at least not on 2026.4.8.

The important split is:

Honcho memory = stored in Honcho
memory-wiki bridge mode = imports public artifacts/files
Honcho currently does not expose those artifacts to the wiki bridge

So today there’s no native Honcho → wiki import/sync path.

What you can do:

Import old local memory files manually
- openclaw honcho setup migration is non-destructive, so your original MEMORY.md, memory/, etc. should still be there.
- You can seed the wiki from those with openclaw wiki ingest ...
Use memory-wiki in isolated mode

#

Treat the wiki as its own curated knowledge layer alongside Honcho

Use a file-based memory plugin if you specifically want bridge imports

So short version: no automatic import from current Honcho memory, but yes for existing local files/manual seeding.

If you want, I can help you set up the best workaround depending on whether you want:

a one-time import from old files, or
an ongoing wiki + Honcho setup.

drowsy idol Apr 13, 2026, 1:44 PM

#

bridge mode being enabled doesn't automatically mean the memory plugin is actively writing to wiki. check if the plugin has its own export flag - sometimes you need to set memory.wiki.export=true separately in the plugin config. also worth checking the plugin logs to see if it's even being triggered.

ivory umbraBOT Apr 13, 2026, 1:44 PM

#

I checked the current docs/source, and I don’t see a separate memory.wiki.export=true style flag for this in OpenClaw or Honcho.

On 2026.4.8, that warning is raised when memory-wiki asks the active memory plugin for public artifacts and gets back zero. So this is not just “bridge isn’t writing yet”, it’s “there’s nothing exported for bridge to import”.

So for this specific combo:

Honcho enabled
memory-wiki in bridge mode

…the expected result right now is that the wiki bridge stays empty.

Logs are still fine to check, but I would not expect them to reveal a missing export toggle here.

Practical options are still:

use memory-wiki in isolated mode alongside Honcho
or use a memory plugin that actually exports public artifacts for bridge mode

#

Docs:

crimson sand Apr 18, 2026, 6:07 PM

#

I have QMD running and it has the same issue with bridged mode: Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet.

ivory umbraBOT Apr 18, 2026, 6:08 PM

#

Can you paste openclaw --version too?

With QMD, this is different from Honcho:

QMD can work with bridge mode
but bridge mode is not importing the QMD index itself

On current source, the exported bridge artifacts come from the memory-core side, basically things like:

MEMORY.md
memory/**/*.md
dream reports
memory event logs

So if you have QMD running but you do not have those public memory files/artifacts yet, wiki status will still say:

active memory plugin is not exporting any public memory artifacts yet

#

In other words, QMD search being healthy is not enough by itself.

If you want, paste:

openclaw --version
your memory: config block
whether your workspace has MEMORY.md and/or a memory/ folder

and I can tell you if this is expected or a real bug.

crimson sand Apr 18, 2026, 6:58 PM

#

OpenClaw 2026.4.15 (041266a)

    "entries": {
      "memory-wiki": {
        "enabled": true,
        "config": {
          "vaultMode": "bridge",
          "vault": {
            "path": "/Users/admin/.openclaw/wiki/main",
            "renderMode": "obsidian"
          },
          "bridge": {
            "enabled": true,
            "readMemoryArtifacts": true,
            "indexDreamReports": true,
            "indexDailyNotes": true,
            "indexMemoryRoot": true,
            "followMemoryEvents": true
          },
          "search": {
            "backend": "shared",
            "corpus": "all"
          },
          "context": {
            "includeCompiledDigestPrompt": false
          }
        }
      },
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": false
          }
        }
      }
    }
  },
  "memory": {
    "backend": "qmd",
    "qmd": {
      sessions: { enabled: true },
      "update": {
        "embedTimeoutMs": 60000000,
        "embedInterval": "0",
        "onBoot": true
      }
    }
  }```

```admin@MAC-OPENCLAW .openclaw % ls -la workspaces/main/MEMORY.md
-rw-r--r--  1 admin  staff  4655 Mar 27 21:45 workspaces/main/MEMORY.md
admin@MAC-OPENCLAW .openclaw % ls -ld workspaces/main/memory
drwxr-xr-x  168 admin  staff  5376 Apr 18 05:24 workspaces/main/memory

ivory umbraBOT Apr 18, 2026, 7:00 PM

#

Thanks, this is the first QMD case here that looks like it should work.

With:

memory-core configured
memory.backend: "qmd"
MEMORY.md present
memory/ present

…I would expect bridge mode to see public artifacts.

So this looks like one of two things:

workspace mismatch
memory-wiki is checking a different resolved workspace than /Users/admin/.openclaw/workspaces/main
real bug on 2026.4.15

#

The first thing I’d check is the resolved workspace:

openclaw memory status
openclaw config get agents.defaults.workspace

In openclaw memory status, look at the Workspace: line.

If it is not /Users/admin/.openclaw/workspaces/main, that’s the problem.
If it is /Users/admin/.openclaw/workspaces/main, then I think this is a real bug.

Why I’m leaning workspace mismatch: current OpenClaw docs/defaults still point the main workspace at ~/.openclaw/workspace unless you override agents.defaults.workspace.

So if needed, the likely fix is:

#

openclaw config set agents.defaults.workspace "~/.openclaw/workspaces/main"
openclaw gateway restart
openclaw wiki status

Docs:

If openclaw memory status already shows the correct workspace, I’d file a bug here: https://github.com/openclaw/openclaw/issues

If you paste the Workspace: line from openclaw memory status, I can tell you pretty quickly which bucket this is.

crimson sand Apr 18, 2026, 7:02 PM

#


🦞 OpenClaw 2026.4.15 (041266a) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

/Users/admin/.openclaw/workspaces/main

Provider: qmd (requested: qmd)
Model: qmd
Sources: memory, sessions
Indexed: 564/188 files · 564 chunks
Dirty: no
Store: ~/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/workspaces/main
Dreaming: off
By source:
  memory · 343/166 files · 343 chunks
  sessions · 221/22 files · 221 chunks
Vector: ready
Batch: disabled (failures 0/0)
Recall store: 221 entries · 0 promoted · 221 concept-tagged · 220 spaced · scripts=221 latin
Recall path: ~/.openclaw/workspaces/main/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-15T03:00:28.903Z
QMD audit: ~/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite · 15220736 bytes · 3 collections
Dreaming artifacts: diary present · 2 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspaces/main/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspaces/main/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspaces/main/DREAMS.md

ivory umbraBOT Apr 18, 2026, 7:03 PM

#

Yep, this looks like a real bug, not a config mistake.

Why I’m confident:

openclaw memory status resolves the same workspace
that workspace clearly has MEMORY.md, memory/, recall store, dream artifacts
QMD is healthy and indexing them
docs even show QMD + bridge mode as a supported setup

So memory-wiki reporting zero public artifacts here does not line up with the current expected behavior.

I would stop tweaking config at this point and file it here:

https://github.com/openclaw/openclaw/issues

Your report already has the useful bits:

#

version: 2026.4.15
memory-wiki config
memory / qmd config
openclaw memory status
proof that MEMORY.md and memory/ exist
the exact openclaw wiki status warning

Short-term workaround, if you want to keep moving:

use memory-wiki in isolated mode for now
seed it manually with openclaw wiki ingest ...

If you want, I can help you turn what you pasted into a tight GitHub issue body.

crimson sand Apr 18, 2026, 7:04 PM

#

Is there already a bug open for this problem?

ivory umbraBOT Apr 18, 2026, 7:05 PM

#

Yep, looks like yes.

The closest matches I found are:

https://github.com/openclaw/openclaw/issues/65698
memory-wiki bridge import reports 0 exported artifacts because memory capability publicArtifacts is not restored on cached plugin registry loads
https://github.com/openclaw/openclaw/issues/65976
memory-wiki bridge mode reports zero public artifacts and can remove existing bridge pages even when QMD memory is healthy

Also very similar:

Your repro sounds very close to #65698 and #65976.

#

I’d probably add your Mac/QMD details to one of those instead of opening yet another duplicate. If you want, I can help trim your repro into a clean comment for one of them.

crimson sand Apr 18, 2026, 7:21 PM

#

It looks like 66082 is this bug. So will wait on it.

#Honcho and memory-wiki

If you want Honcho + memory-wiki

If you specifically want bridge mode

If you specifically want `bridge` mode