Setup memory wiki | Friends of the Crustacean 🦞🤝 | Page 1

buoyant copper Apr 16, 2026, 9:27 PM

#

Hello, can you walk me through setting up memory-wiki for all my agents? I would like to use bridge mode, and have it be obsidian compatible inside my obsidian directory at /home/node/obsidian . Any other questions I need to answer?

magic vaporBOT Apr 16, 2026, 9:27 PM

#

warped parrotBOT Apr 16, 2026, 9:27 PM

#

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

magic vaporBOT Apr 16, 2026, 9:27 PM

#

whole hollyBOT Apr 16, 2026, 9:29 PM

#

Yep. A single memory-wiki vault in bridge mode can aggregate public memory artifacts from multiple agent workspaces, so this can work for “all my agents” as long as they’re on the same gateway.

First, please paste:

openclaw --version

A few setup questions that matter:

Is /home/node/obsidian the actual Obsidian vault root, or do you want a subfolder inside it?
Do you want official Obsidian CLI integration, or just Obsidian-friendly markdown?
What’s your active memory backend right now, memory-core, QMD, or something else?
Are all those agents on one OpenClaw gateway, or spread across multiple gateways?

If you want the cleanest setup, I’d recommend a dedicated subfolder like /home/node/obsidian/openclaw-wiki. If you point memory-wiki at /home/node/obsidian directly, it will create files/folders like AGENTS.md, WIKI.md, entities/, sources/, reports/, etc. at that root.

#

Use JSON5 in your OpenClaw config, under plugins.entries.memory-wiki:

{
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          vault: {
            path: "/home/node/obsidian/openclaw-wiki", // or "/home/node/obsidian" if you really want the root
            renderMode: "obsidian",
          },
          obsidian: {
            enabled: true,

#

            useOfficialCli: false, // set true only if `obsidian` is on PATH
            vaultName: "OpenClaw Wiki",
            openAfterWrites: false,
          },
          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
          },
          search: {
            backend: "shared",
            corpus: "all",

#

          },
          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,
            createDashboards: true,
          },
        },
      },
    },
  },
}

Then restart the gateway and run:

#

openclaw wiki init
openclaw wiki doctor
openclaw wiki bridge import
openclaw wiki compile
openclaw wiki status

If you enable the official Obsidian CLI too:

openclaw wiki obsidian status

Docs:

#

https://docs.openclaw.ai/concepts/memory

If you paste your version plus current memory backend, I can turn this into an exact config for your setup.

buoyant copper Apr 16, 2026, 9:32 PM

#

Yes a subfolder under obsidian, so maybe like /home/node/obsidian/wiki .
2.Currently I am just using obsidian friendly markdown with git as I don't have sync subscription.
QMD
All agents in a single gateway.

whole hollyBOT Apr 16, 2026, 9:33 PM

#

Nice, that’s the sweet spot. QMD + one shared bridge-mode wiki vault on a single gateway is exactly the setup I’d recommend.

I’d use /home/node/obsidian/wiki.

Config

Keep your existing QMD config, then add/adjust this in your OpenClaw config JSON5:

{
  memory: {
    backend: "qmd",
    // keep your existing qmd config here
  },

  plugins: {

#

    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",

          vault: {
            path: "/home/node/obsidian/wiki",
            renderMode: "obsidian",
          },

          obsidian: {
            enabled: true,
            useOfficialCli: false, // good for plain Obsidian markdown + git
            openAfterWrites: false,

#

          },

          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
          },

          search: {
            backend: "shared",
            corpus: "all",
          },

#


          context: {
            includeCompiledDigestPrompt: false,
          },

          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,
            createDashboards: true,
          },
        },
      },
    },
  },
}

#

Then run

If you use the source install, swap openclaw for pnpm openclaw.

openclaw gateway restart
openclaw wiki init
openclaw wiki doctor
openclaw wiki bridge import
openclaw wiki compile
openclaw wiki status

What this gives you

QMD stays your active memory backend
memory-wiki builds a shared wiki at /home/node/obsidian/wiki

#

bridge mode imports public artifacts from all agent workspaces on that gateway
Obsidian sees normal markdown files, so git works fine

Good sanity check

If openclaw wiki doctor says bridge artifacts are missing, paste that output. That usually means the active memory layer is not exporting what the wiki expects yet.

Docs:

One more thing, please paste openclaw --version too. I’m happy to sanity-check the exact config against your version before you restart.

buoyant copper Apr 16, 2026, 9:48 PM

#

(unknown) — Deployed locally, trusted globally, debugged eternally.

Wiki doctor: 1 issue(s) found

Wiki vault mode: bridge
Vault: ready (/home/node/obsidian/wiki)
Render mode: obsidian
Obsidian CLI: missing
Bridge: enabled (0 exported artifacts)
Unsafe local: disabled
Pages: 0 sources, 0 entities, 0 concepts, 0 syntheses, 5 reports
Source provenance: 0 native, 0 bridge, 0 bridge-events, 0 unsafe-local, 0 other

Warnings:

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

Suggested fixes:

Use a memory plugin that exports public artifacts, create/import memory artifacts first, or switch the wiki back to isolated mode.
node@af97fcfa17f4:/app$ openclaw wiki bridge import

whole hollyBOT Apr 16, 2026, 9:50 PM

#

Let me check the artifact-export side before I send you a guess.

#

Good news, this looks like a state issue, not a bad memory-wiki config.

What bridge is looking for is very specific. With QMD, memory-wiki only imports exported memory artifacts from the agent workspaces, basically:

MEMORY.md or memory.md
memory/*.md
memory/dreaming/*.md
the memory event log

If those files do not exist yet, wiki doctor shows exactly what you got: 0 exported artifacts.

Two important nuances:

QMD is not the problem. QMD + bridge mode is valid.
Bridge mode does not import arbitrary QMD indexed paths. If QMD is indexing external folders, those stay searchable via memory_search, but they do not automatically become wiki bridge sources.

Also, the Obsidian CLI: missing line is fine for your setup. You are using Obsidian-friendly markdown, not the official CLI.

#

What to do next

1. Make sure at least one agent workspace has actual memory files

The easiest way is to ask an agent to save something durable, for example:

“Remember that this gateway uses a shared memory wiki in /home/node/obsidian/wiki.”

That should cause the workspace to start growing real memory files.

2. Then rerun

openclaw wiki bridge import
openclaw wiki compile
openclaw wiki status

#

3. If you want me to verify the root cause, paste:

openclaw memory status
one agent workspace path
whether that workspace currently has MEMORY.md and/or a memory/ folder

Likely outcome

My bet is that your agents simply have no exported workspace memory artifacts yet, or all the useful stuff currently lives in extra QMD-indexed paths outside the workspaces.

If it’s the second case, then you have two options:

keep bridge mode for workspace memory only, and use QMD for broader recall
or switch the wiki to isolated/unsafe-local if you want to pull local notes directly into the wiki layer

Docs:

#

https://docs.openclaw.ai/cli/wiki

If you paste openclaw memory status, I can tell you pretty quickly which of those two cases you’re in.

buoyant copper Apr 16, 2026, 9:53 PM

#

All my agents pretty much have stuff in the memory folder like

$ cd ..
node@af97fcfa17f4:~/.openclaw$ ls workspace/aurora/memory/
2026-04-10-2003.md 2026-04-10-new-session-greeting.md 2026-04-10-session-start.md 2026-04-11-frisky-cat-cafe.md 2026-04-12.md 2026-04-14.md 2026-04-15.md 2026-04-16.md

whole hollyBOT Apr 16, 2026, 9:54 PM

#

Let me check the workspace resolution path, because if the files exist but bridge still sees 0, the next likely culprit is that memory-core is looking at different agent workspace paths than the ones you’re inspecting.

#

Yeah, if ~/.openclaw/workspace/aurora/memory/*.md exists, then bridge should not be at 0.

So we’ve narrowed it down a lot. The two most likely causes now are:

OpenClaw is resolving the agent workspace to a different path than the one you inspected.
You’re on a build that predates a couple of recent fixes around:
- openclaw wiki using the live plugin config
- memory public artifacts disappearing on warm/plugin-registry reloads

Please run these next

openclaw agents list --json
openclaw memory status --agent aurora --json

What I want to confirm:

#

aurora’s workspace resolves to the same path you checked, something like:
/home/node/.openclaw/workspace/aurora
the active memory plugin is still memory-core
the backend is qmd

If those look correct

Then I’d honestly update first, because there were recent fixes in exactly this area.

If you want, paste:

openclaw agents list --json
openclaw memory status --agent aurora --json

and I’ll tell you which side is wrong, path resolution or build/version.

Docs:

https://docs.openclaw.ai/cli/agents

#

Glad we caught this, because your vault config itself looks basically right.

buoyant copper Apr 16, 2026, 9:56 PM

#

I am guessing because qmd is having some issues

$ openclaw memory status --agent aurora

🦞 OpenClaw 2026.4.14 (unknown) — I'll butter your workflow like a lobster roll: messy, delicious, effective.

Memory Search (aurora)
Provider: qmd (requested: qmd)
Model: qmd
Sources: memory
Indexed: 664/8 files · 664 chunks
Dirty: no
Store: ~/.openclaw/agents/aurora/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/workspace/aurora
Dreaming: 0 3 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 664/8 files · 664 chunks
Vector: unavailable
Vector error: QMD status probe failed: qmd status timed out after 5000ms
Batch: disabled (failures 0/0)
Recall store: 241 entries · 0 promoted · 241 concept-tagged · 197 spaced · scripts=241 latin
Recall path: ~/.openclaw/workspace/aurora/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-16T18:26:55.291Z
QMD audit: ~/.openclaw/agents/aurora/qmd/xdg-cache/qmd/index.sqlite · 14426112 bytes · 4 collections
Dreaming artifacts: diary present · 5 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace/aurora/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/aurora/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspace/aurora/DREAMS.md

whole hollyBOT Apr 16, 2026, 9:57 PM

#

Yeah, I don’t think the QMD timeout is the root cause here.

Your memory status output is actually the important part:

OpenClaw sees aurora
it resolves the workspace correctly to ~/.openclaw/workspace/aurora
QMD sees and indexes the memory files
dreaming artifacts are present

So bridge mode should be seeing exported artifacts from that workspace.

Because you’re on 2026.4.14, I think this is much more likely to be an older OpenClaw bug than a bad QMD setup. There were later fixes around:

memory public artifacts disappearing after warm/plugin-registry loads
openclaw wiki using the live plugin config correctly

My recommendation

#

Update OpenClaw to latest
Restart the gateway / container fully
Re-run:

openclaw wiki doctor
openclaw wiki bridge import
openclaw wiki status

Update docs:
https://docs.openclaw.ai/install/updating

Why I’m leaning that way

If this were just “QMD is broken”, I’d expect memory status to be much uglier. But your memory layer is clearly alive and pointed at the right workspace. The missing piece is the bridge artifact surface, which lines up with those later fixes.

#

If it still says 0 after updating

Then I’d call it a real bug and file it here with these outputs:

openclaw --version
openclaw wiki doctor
openclaw memory status --agent aurora

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

If you want, after you update, paste the new wiki doctor output and I’ll sanity check it.

buoyant copper Apr 17, 2026, 10:57 AM

#

We stepping back I found the issue with the qmd error with 'openclaw memory status --agent aurora', seems at one point I changed the name of that agent from auora to jim-ceo, so there are some wires crossed, how can I fix?

🦞 OpenClaw 2026.4.14

$ openclaw memory status --agent jim-ceo

Memory Search (jim-ceo)
Provider: qmd (requested: qmd)
Model: qmd
Sources: memory
Indexed: 1182/9 files · 1182 chunks
Dirty: no
Store: ~/.openclaw/agents/jim-ceo/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/workspace/aurora
Dreaming: 0 3 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 1182/9 files · 1182 chunks
Vector: ready
Batch: disabled (failures 0/0)
Recall store: 265 entries · 0 promoted · 265 concept-tagged · 221 spaced · scripts=265 latin
Recall path: ~/.openclaw/workspace/aurora/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-17T07:06:35.606Z
QMD audit: ~/.openclaw/agents/jim-ceo/qmd/xdg-cache/qmd/index.sqlite · 59047936 bytes · 4 collections
...

node@af97fcfa17f4:~/.openclaw$ openclaw memory status --agent aurora
Memory Search (aurora)
Provider: qmd (requested: qmd)
Model: qmd
Sources: memory
Indexed: 664/9 files · 664 chunks
Dirty: no
Store: ~/.openclaw/agents/aurora/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/workspace/aurora
Dreaming: 0 3 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 664/9 files · 664 chunks
Vector: unavailable
Vector error: QMD status probe failed: qmd status timed out after 5000ms
Batch: disabled (failures 0/0)
Recall store: 265 entries · 0 promoted · 265 concept-tagged · 221 spaced · scripts=265 latin
Recall path: ~/.openclaw/workspace/aurora/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-17T07:06:35.606Z
QMD audit: ~/.openclaw/agents/aurora/qmd/xdg-cache/qmd/index.sqlite · 14426112 bytes · 4 collections

whole hollyBOT Apr 17, 2026, 10:59 AM

#

I’m going to verify the supported cleanup path before I tell you to move anything.

#

Ah, yep, that’s the crossed wires.

You currently have two agent IDs (aurora and jim-ceo) with separate QMD state dirs but the same workspace:

~/.openclaw/agents/aurora/...
~/.openclaw/agents/jim-ceo/...
both pointing at ~/.openclaw/workspace/aurora

That’s a messy setup for QMD and likely part of why bridge mode got weird.

My recommendation, safest first

Option A, safest

Keep the workspace path for now, but make jim-ceo the only agent that points to it.

Audit current agents/bindings:

#

openclaw agents list --bindings

In your config, keep only the real agent entry, something like:

{
  agents: {
    list: [
      {
        id: "jim-ceo",
        workspace: "~/.openclaw/workspace/aurora",
      },
    ],
  },

#

Remove old bindings from aurora, bind traffic to jim-ceo if needed.
Restart gateway.
Force a clean reindex for the real agent:

openclaw memory index --agent jim-ceo --force
openclaw memory status --agent jim-ceo
openclaw wiki doctor
openclaw wiki bridge import

Important

Do not run openclaw agents delete aurora yet if jim-ceo is still using ~/.openclaw/workspace/aurora, because delete can move the workspace too, and you do not want that.

#

Option B, cleaner later

After Option A is stable, you can also rename the workspace path itself so everything matches:

move ~/.openclaw/workspace/aurora → ~/.openclaw/workspace/jim-ceo
update jim-ceo.workspace
restart
reindex again

That’s cleaner, but I would not do it first.

Why this helps

QMD state is per agent id, while the memory files live in the workspace.
Right now you effectively have two indexes fighting over one workspace.

What I’d do, in order

#

make jim-ceo the only configured/bound agent for that workspace
restart gateway
openclaw memory index --agent jim-ceo --force
test openclaw wiki doctor

If you want, paste your openclaw agents list --bindings output and I can tell you exactly what to remove.

buoyant copper Apr 17, 2026, 11:22 AM

#

Ok I moved everything to jim-ceo reindexed memory, and deleted aurora workspace, but 'openclaw memory status --agent jim-ceo' looks good, and shows Index: 9 files, but 'wiki doctor' still shows no files.

whole hollyBOT Apr 17, 2026, 11:23 AM

#

Yep, that pretty much confirms it.

If:

openclaw memory status --agent jim-ceo looks healthy
QMD indexes the 9 files
the old aurora confusion is gone

but openclaw wiki doctor still reports 0 exported artifacts, then I would stop tweaking the config. At that point it’s almost certainly the 2026.4.14 bridge/public-artifacts bug, not your setup.

I’d do this now

Update OpenClaw to latest
Fully restart the gateway or container
Re-run:

#

openclaw wiki doctor
openclaw wiki bridge import
openclaw wiki status

Update docs:
https://docs.openclaw.ai/install/updating

Why I’m confident

memory status proving the files are there is the hard part.
wiki doctor still seeing zero after the agent cleanup means the bridge surface itself is what’s broken.

If you need it working today

Temporary workaround:

#

switch memory-wiki to isolated
ingest notes directly into the wiki layer

That’s not as nice as bridge mode, but it avoids this bug path.

If it still fails after updating

Then it’s worth filing a bug with:

openclaw --version
openclaw memory status --agent jim-ceo
openclaw wiki doctor

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

If you update and paste the new output, I’ll help check it.

buoyant copper Apr 17, 2026, 1:13 PM

#

So yes I agree it seems it is due to a bug in the bridge mode, and I see a few open issues about this, and have subscribed to them to watch for updates.

Regarding the workaround, if I would switch to isolated, how does this work in practice?

whole hollyBOT Apr 17, 2026, 1:14 PM

#

Yep. In practice, isolated mode means:

one shared wiki vault for all your agents, but you curate it directly instead of having it auto-import memory artifacts.

So it still works well with Obsidian, it just stops being an automatic mirror of agent memory.

What changes

With bridge mode:

memory-wiki tries to pull in MEMORY.md, daily notes, dream reports, etc.

With isolated mode:

the wiki is its own source of truth
you add content by:
- editing files in Obsidian
- using openclaw wiki ingest <file>
- using wiki tools like wiki_apply

#

Config for the workaround

I’d switch to something like this:

{
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "isolated",
          vault: {
            path: "/home/node/obsidian/wiki",
            renderMode: "obsidian",
          },

#

          obsidian: {
            enabled: true,
            useOfficialCli: false,
            openAfterWrites: false,
          },
          bridge: {
            enabled: false,
          },
          search: {
            backend: "local",
            corpus: "wiki",
          },
          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,

#

            createDashboards: true,
          },
        },
      },
    },
  },
}

Practical workflow

Option 1, edit directly in Obsidian

Open /home/node/obsidian/wiki as part of your vault and work in:

entities/
concepts/

#

syntheses/
sources/

Then run:

openclaw wiki compile
openclaw wiki lint

Option 2, ingest selected source files

For important files you already have, ingest them one by one:

openclaw wiki ingest ~/.openclaw/workspace/jim-ceo/MEMORY.md
openclaw wiki ingest ~/.openclaw/workspace/jim-ceo/memory/2026-04-17.md

#

openclaw wiki compile

That creates source pages under sources/.

What I would recommend

Do not try to manually ingest every daily note from every agent. That gets annoying fast.

I’d use isolated mode as a curated knowledge layer:

import a few important source files
maintain higher-level syntheses in Obsidian
let agents read the wiki with wiki_search / wiki_get

So the pattern becomes:

#

memory/QMD = raw recall layer
isolated memory-wiki = curated shared knowledge base

That’s actually a pretty decent setup until bridge mode is fixed.

Docs:

If you want, I can sketch a good folder structure for /home/node/obsidian/wiki so it feels natural in Obsidian.

oblique marten Apr 17, 2026, 6:22 PM

#

@krill, similar issue but on the stock memory platform rather than qmd, with memory-core enabled, dreaming enabled, bridge mode enabled. On v2026.4.15.

Here's what wiki doctor says:

Wiki doctor: 1 issue(s) found

Wiki vault mode: bridge
Vault: ready (/Users/jeeves/Obsidian/JeevesWiki)
Render mode: obsidian
Obsidian CLI: available (requested)
Bridge: enabled (0 exported artifacts)
Unsafe local: disabled
Pages: 0 sources, 0 entities, 0 concepts, 0 syntheses, 6 reports
Source provenance: 0 native, 0 bridge, 0 bridge-events, 0 unsafe-local, 0 other

Warnings:

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

Suggested fixes:

Use a memory plugin that exports public artifacts, create/import memory artifacts first, or switch the wiki back to isolated mode.

whole hollyBOT Apr 17, 2026, 6:23 PM

#

Yep, that points to the same bridge/public-artifacts bug, and the fact that you’re seeing it on the stock memory-core path makes me more confident it is not QMD-specific.

If you want one quick sanity check, run:

openclaw memory status --agent <your-agent-id>

If that shows the workspace/memory files are healthy, then I would stop tweaking config. wiki doctor showing 0 exported artifacts in bridge mode on 2026.4.15 looks like the same broken path.

So my read is:

memory-core itself is fine
bridge mode is the broken piece
isolated mode is the practical workaround for now

If you want to add a useful datapoint to the bug, the best bundle is:

#

openclaw --version
openclaw memory status --agent <id>
openclaw wiki doctor

and drop that on the GitHub issue you found.

If you want, I can also give you the minimal isolated-mode config for your exact Obsidian path so you can get moving right away.

oblique marten Apr 17, 2026, 6:30 PM

#

For openclaw memory status --agent <id>, get different results if I use

openclaw memory status --agent main (shows 90/90 memory files)
openclaw memory status --agent jeeves (shows 0/0)

even though:

    "id": "main",
    "default": true,
    "name": "Jeeves",

whole hollyBOT Apr 17, 2026, 6:31 PM

#

Ah, yep, that part is expected.

--agent uses the agent ID, not the visible/display name.

So in your case:

id: "main" = the real agent id
name: "Jeeves" = just the human-facing label

That means:

openclaw memory status --agent main

is the correct command.

#

But:

openclaw memory status --agent jeeves

is treated like a different agent id, so OpenClaw looks for a separate jeeves agent/workspace/state and you get the empty 0/0 result.

Practical rule

For CLI commands, use the id:

✅ --agent main
❌ --agent jeeves (unless you actually created an agent whose id is jeeves)

What this means for the bridge issue

#

If:

openclaw memory status --agent main

shows 90/90 memory files, but wiki doctor still says 0 exported artifacts, then that still points back to the same bridge/public-artifacts bug.

So this new detail explains the confusing CLI output, but it does not explain away the bridge problem.

Docs:
https://docs.openclaw.ai/cli/agents

If you want, I can give you the exact isolated-mode config for your /Users/jeeves/Obsidian/JeevesWiki path.

oblique marten Apr 17, 2026, 6:32 PM

#

Please do.

whole hollyBOT Apr 17, 2026, 6:32 PM

#

Yep, here’s a clean isolated-mode setup for your path.

Config

Keep your current memory setup as-is, then set memory-wiki like this:

{
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "isolated",

          vault: {

#

            path: "/Users/jeeves/Obsidian/JeevesWiki",
            renderMode: "obsidian",
          },

          obsidian: {
            enabled: true,
            useOfficialCli: true,
            vaultName: "JeevesWiki", // change if your Obsidian vault name differs
            openAfterWrites: false,
          },

          bridge: {
            enabled: false,
          },

#

          search: {
            backend: "local",
            corpus: "wiki",
          },

          context: {
            includeCompiledDigestPrompt: false,
          },

          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,
            createDashboards: true,
          },
        },

#

      },
    },
  },
}

Then run

openclaw gateway restart
openclaw wiki init
openclaw wiki status

Practical workflow

#

Edit directly in Obsidian

Work inside:

entities/
concepts/
syntheses/
sources/

Then refresh the compiled view:

openclaw wiki compile
openclaw wiki lint

Or ingest selected files

For important files you want inside the wiki:

#

openclaw wiki ingest /path/to/file.md
openclaw wiki compile

Since this is isolated mode, I’d treat it as a curated knowledge base, not a full dump of every memory file.

Recommendation

A good starting pattern is:

import a few important source docs
create a couple of top-level syntheses in Obsidian
let the agents use wiki_search / wiki_get against that vault

Docs:

https://docs.openclaw.ai/plugins/memory-wiki

#

https://docs.openclaw.ai/cli/wiki

If you want, I can also suggest a simple folder/template structure for JeevesWiki so it feels good in Obsidian.

oblique marten Apr 17, 2026, 6:35 PM

#

Please do.

whole hollyBOT Apr 17, 2026, 6:35 PM

#

Yep. For Obsidian, I’d keep it really simple and lean into the folders memory-wiki already wants.

Good starter structure

index.md
your front door
syntheses/
living summaries you actually read often
entities/
one page per person, project, system, org, place, etc.
concepts/
durable ideas, rules, workflows, mental models
sources/

#

imported raw material, meeting notes, docs, transcripts

reports/
generated dashboards, mostly read-only

What I’d create first

In `syntheses/`

current-state.md
active-projects.md
open-questions.md
people-and-roles.md

In `concepts/`

operating-principles.md
writing-style.md
decision-rules.md

#

In `entities/`

jeeves.md
one page per important person/project/system

Naming style I’d use

Flat, boring, searchable names:

entities/jeeves.md
entities/customer-support-bot.md
concepts/meeting-rhythm.md
syntheses/weekly-overview.md
sources/2026-04-17-planning-notes.md

No fancy nesting at first. Obsidian search is good enough.

Practical rule of thumb

#

sources = raw inputs
syntheses = your best current understanding
entities = who/what matters
concepts = reusable ideas/processes
reports = generated output, don’t fight it

A nice simple workflow

ingest or drop raw notes into sources/
summarize them into syntheses/current-state.md
pull stable facts into entities/ and concepts/
run:

openclaw wiki compile
openclaw wiki lint

#

My recommendation

If you want the vault to feel good fast, start with just these 3 files:

syntheses/current-state.md
syntheses/open-questions.md
entities/jeeves.md

That gives you a clean home page, a working scratchpad, and one concrete entity page.

If you want, I can also draft a minimal template for those 3 files so you can paste them straight into Obsidian.

oblique marten Apr 17, 2026, 6:43 PM

#

Yes.

whole hollyBOT Apr 17, 2026, 6:44 PM

#

Nice. I’d keep these plain and lightweight at first, then let the wiki tools add more structure later.

`syntheses/current-state.md`

# Current State

## What seems true right now
- 
- 
- 

## Active threads
- 
- 
-

#


## Risks / friction
- 
- 
- 

## Next actions
- 
- 
- 

## Useful links
- [[syntheses/open-questions]]
- [[entities/jeeves]]

#

`syntheses/open-questions.md`

# Open Questions

## High priority
- [ ] 
- [ ] 
- [ ] 

## Medium priority
- [ ] 
- [ ] 

## Parked
- [ ]

#

- [ ] 

## Recently answered
- [x]

`entities/jeeves.md`

# Jeeves

## Summary
A short plain-English description of who Jeeves is and what role he plays.

## Responsibilities

#

- 
- 
- 

## Preferences
- 
- 
- 

## Important relationships
- 
- 
- 

## Open questions

#

- 
- 
-

After creating them

Run:

openclaw wiki compile
openclaw wiki lint

Small tip

#

I’d treat:

current-state.md as the living “what matters now” page
open-questions.md as the pressure-release valve
jeeves.md as the seed for your entity graph

That’s enough to make the vault feel useful fast.

If this ends up helping, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

oblique marten Apr 17, 2026, 6:44 PM

#

One last thing. Are these configurations correct?

  "memory-core": {
    "config": {
      "dreaming": {
        "enabled": true,
        "frequency": "30 22 * * *"
      }
    }
  },
  "active-memory": {
    "enabled": true,
    "config": {
      "enabled": true,
      "agents": [
        "main"
      ],
      "queryMode": "recent",
      "promptStyle": "balanced",
      "timeoutMs": 15000,
      "logging": true
    }
  },

whole hollyBOT Apr 17, 2026, 6:45 PM

#

Let me verify those keys before I bless them.

#

Yes, those look basically correct. The keys are real, and the shape matches the docs.

`memory-core`

This part is fine:

"memory-core": {
  "config": {
    "dreaming": {
      "enabled": true,
      "frequency": "30 22 * * *"
    }
  }
}

#

That enables dreaming and runs it daily at 22:30.

`active-memory`

This is also valid as long as your actual agent id is main:

"active-memory": {
  "enabled": true,
  "config": {
    "enabled": true,
    "agents": ["main"],
    "queryMode": "recent",
    "promptStyle": "balanced",
    "timeoutMs": 15000,
    "logging": true

#

}
}

Two small notes

1. `agents: ["main"]` is correct

Use the agent id, not the display name.
So if your config has:

"id": "main",
"name": "Jeeves"

then ["main"] is the right value.

#

2. I would probably add `allowedChatTypes`

If you do not set it, Active Memory defaults to direct-message style chats only.

So a slightly safer explicit version is:

"active-memory": {
  "enabled": true,
  "config": {
    "enabled": true,
    "agents": ["main"],
    "allowedChatTypes": ["direct"],
    "queryMode": "recent",
    "promptStyle": "balanced",
    "timeoutMs": 15000,
    "logging": true

#

}
}

If you want it in channels too, add "channel".

Optional cleanup

config.enabled: true is okay, but optional.
You can keep it, I probably would while tuning.

Short version

memory-core.dreaming block: ✅ correct
active-memory block: ✅ correct
add allowedChatTypes if you want to be explicit

#Setup memory wiki

Config

Then run

What this gives you

Good sanity check

What to do next

1. Make sure at least one agent workspace has actual memory files

2. Then rerun

3. If you want me to verify the root cause, paste:

Likely outcome

Please run these next

If those look correct

If you want, paste:

My recommendation

Why I’m leaning that way

If it still says 0 after updating

My recommendation, safest first

Option A, safest

Important

Option B, cleaner later

Why this helps

What I’d do, in order

I’d do this now

Why I’m confident

If you need it working today

If it still fails after updating

What changes

Config for the workaround

Practical workflow

Option 1, edit directly in Obsidian

Option 2, ingest selected source files

What I would recommend

Practical rule

What this means for the bridge issue

Config

Then run

Practical workflow

Edit directly in Obsidian

Or ingest selected files

Recommendation

Good starter structure

What I’d create first

In syntheses/

In concepts/

In entities/

Naming style I’d use

Practical rule of thumb

A nice simple workflow

My recommendation

syntheses/current-state.md

syntheses/open-questions.md

entities/jeeves.md

After creating them

Small tip

memory-core

active-memory

Two small notes

1. agents: ["main"] is correct

2. I would probably add allowedChatTypes

Optional cleanup

Short version

In `syntheses/`

In `concepts/`

In `entities/`

`syntheses/current-state.md`

`syntheses/open-questions.md`

`entities/jeeves.md`

`memory-core`

`active-memory`

1. `agents: ["main"]` is correct

2. I would probably add `allowedChatTypes`