#View memory wiki

1 messages · Page 1 of 1 (latest)

gilded sierra
#

I understand that the memory system has been set up in a wiki format. I've also enabled QMD, but how can I visual the wiki

fallen violetBOT
#

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

boreal shoreBOT
#

QMD gives you better memory search/indexing; it isn’t the visual viewer. For “visualizing” the wiki, the intended path is to render the memory-wiki vault as Markdown and open it in Obsidian.

Try:

openclaw wiki status
openclaw wiki doctor
openclaw wiki init          # if the vault is not initialized yet
openclaw wiki bridge import # if you’re using bridge mode
openclaw wiki compile

Then either open the vault path from openclaw wiki status directly in Obsidian, or, if you enabled the Obsidian CLI integration:

openclaw wiki obsidian status
#
openclaw wiki obsidian open index.md
# useful generated dashboards:
openclaw wiki obsidian open reports/claim-health.md
openclaw wiki obsidian open reports/relationship-graph.md
openclaw wiki obsidian open reports/open-questions.md

Config-wise, the key bits are vault.renderMode: "obsidian" and optionally obsidian.enabled: true. Dashboards are generated when render.createDashboards is enabled.

Docs:
https://docs.openclaw.ai/plugins/memory-wiki
https://docs.openclaw.ai/cli/wiki
https://docs.openclaw.ai/concepts/memory-qmd

gilded sierra
#

These are my mempry settings

#

"memory": {
"backend": "qmd",
"citations": "auto",
"qmd": {
"command": "/home/admin/.bun/bin/qmd",
"searchMode": "search",
"includeDefaultMemory": true,
"paths": [
{
"path": "/home/admin/.openclaw/workspace/wiki",
"name": "wiki",
"pattern": "/*.md"
},
{
"path": "/home/admin/.openclaw/workspace/memory",
"name": "memory-root",
"pattern": "
/*.md"
},
{
"path": "/home/admin/.openclaw/workspace/MEMORY.md",
"name": "memory-main"
},
{
"path": "/home/admin/.openclaw/workspace/LEARNINGS.md",
"name": "learnings"
}
],
"update": {
"interval": "5m",
"debounceMs": 15000,
"onBoot": true,
"waitForBootSync": false
},
"limits": {
"maxResults": 6,
"timeoutMs": 10000
}
}
},

boreal shoreBOT
#

I don’t see the settings attached/pasted in that message — looks like Discord sent an empty body after the text.

Can you paste the relevant config block plus these outputs?

openclaw --version
openclaw wiki status
openclaw wiki doctor

The block I’m looking for is usually around:

memory: { ... },
plugins: {
  entries: {
#
    "memory-wiki": { ... }
  }
}

Once I can see those, I can tell you the exact way to open/visualize the vault.

#

Yep — that config enables QMD indexing, but it does not enable the memory-wiki plugin itself.

Right now this line:

{
  "path": "/home/admin/.openclaw/workspace/wiki",
  "name": "wiki",
  "pattern": "**/*.md"
}

means “make this folder searchable by QMD.” It does not create the compiled wiki vault, reports, dashboards, Obsidian helpers, etc.

To get the visual wiki, add the plugin config separately, something like:

#
plugins: {
  entries: {
    "memory-wiki": {
      enabled: true,
      config: {
        vaultMode: "isolated",
        vault: {
          path: "/home/admin/.openclaw/workspace/wiki",
          renderMode: "obsidian",
        },
        obsidian: {
          enabled: true,
          useOfficialCli: true,
          vaultName: "OpenClaw Wiki",
          openAfterWrites: false,
#
        },
        render: {
          preserveHumanBlocks: true,
          createBacklinks: true,
          createDashboards: true,
        },
      },
    },
  },
}

Then restart the gateway and run:

#
openclaw wiki init
openclaw wiki compile
openclaw wiki status

After that, open /home/admin/.openclaw/workspace/wiki as a vault in Obsidian. The visual stuff will mostly be Markdown pages under index.md, entities/, concepts/, syntheses/, and generated dashboards under reports/.

Small caution: if you keep that same /workspace/wiki path in memory.qmd.paths, QMD will index the generated wiki pages too. That’s fine if intentional, but it can duplicate memory/search results. I’d usually let memory-wiki own that folder, then use openclaw wiki search/get for wiki content and QMD for your raw memory files.

Docs: https://docs.openclaw.ai/plugins/memory-wiki and https://docs.openclaw.ai/cli/wiki

gilded sierra
#

is there a separate wiki for each agent?

boreal shoreBOT
#

Short version: QMD memory is agent-scoped; the memory-wiki vault is not automatically per-agent.

By default, memory-wiki uses one vault path:

~/.openclaw/wiki/main

Or whatever you set here:

plugins: {
  entries: {
    "memory-wiki": {
      config: {
        vault: { path: "..." }
#
      }
    }
  }
}

So if multiple agents share the same OpenClaw config and same memory-wiki plugin config, they’ll see/use the same wiki vault.

Your QMD setup is different: OpenClaw manages QMD per agent under something like:

~/.openclaw/agents/<agentId>/qmd/

But your extra memory.qmd.paths are explicit paths. If every agent has the same paths array, they’ll all index the same folders.

#

If you want separate visual wikis, give each environment/agent setup a different wiki vault path, e.g.:

vault: {
  path: "/home/admin/.openclaw/wiki/main-agent",
  renderMode: "obsidian",
}

and another config/profile/gateway for another agent using:

vault: {
  path: "/home/admin/.openclaw/wiki/research-agent",
  renderMode: "obsidian",
}
#

For your current setup, I’d treat /home/admin/.openclaw/workspace/wiki as one shared visual wiki unless you intentionally split paths.

gilded sierra
#

If I edit the wiki to remove unwanted info, will those changes go back into memory?

boreal shoreBOT
#

Usually no — editing the wiki does not write changes back into the active memory store.

Think of it like this:

  • QMD / active memory = searchable source/index layer
  • memory-wiki = compiled/curated Markdown vault beside it
  • bridge import = pulls memory artifacts into the wiki, not a two-way sync

So if you delete something from the wiki page, it won’t automatically remove it from MEMORY.md, memory/, QMD’s indexed source paths, or old session transcript indexes.

Two important gotchas:

  1. If the unwanted info still exists in the source memory files, a later openclaw wiki bridge import / compile can bring it back into generated wiki content.
  2. If you configured QMD to index the wiki folder, then editing the wiki will affect QMD search results for that wiki folder after reindexing — but it still won’t delete the original memory source.

For actually removing unwanted info, remove it from the source too, then refresh:

#
# edit/remove from MEMORY.md, memory/*.md, LEARNINGS.md, etc.
openclaw memory index --force
openclaw wiki bridge import
openclaw wiki compile

Also: don’t hand-edit generated blocks if you can avoid it; compile may overwrite them. For durable curation, edit source pages/human blocks or use openclaw wiki apply ... where possible.

gilded sierra
#

the status says my wiki is in ~/.openclaw/wiki/main, but that is different to the setting in plugins

boreal shoreBOT
#

That usually means the memory-wiki plugin config you edited is not the config the wiki CLI is reading — or it’s in the wrong shape/path and got ignored, so it falls back to the default:

~/.openclaw/wiki/main

Check these in order:

openclaw --version
openclaw config file
openclaw config get plugins.entries.memory-wiki.config.vault.path
openclaw wiki status
openclaw gateway status

The most common causes are:

#
  1. Editing the wrong config file — service/CLI profile mismatch, OPENCLAW_CONFIG_PATH, different Linux user, Docker/Nix, etc.
  2. Config block is in the wrong place — it must be under:
plugins: {
  entries: {
    "memory-wiki": {
      enabled: true,
      config: {
        vault: {
          path: "/home/admin/.openclaw/workspace/wiki",
          renderMode: "obsidian",
        },
      },
    },
  },
#
}
  1. Gateway/CLI not restarted/reloaded after config change — restart the gateway after editing plugin config.
  2. You only configured QMD paths — memory.qmd.paths[].path = /workspace/wiki just tells QMD to index that folder; it does not set the memory-wiki vault path.

If openclaw config get plugins.entries.memory-wiki.config.vault.path prints your custom path but openclaw wiki status still shows ~/.openclaw/wiki/main, that’s likely a bug or profile mismatch — paste those command outputs and your plugins.entries.memory-wiki block.

gilded sierra
#

admin@PiClaw:~/.openclaw/wiki/main/reports $ openclaw --version
openclaw config file
openclaw config get plugins.entries.memory-wiki.config.vault.path
openclaw wiki status
openclaw gateway status
OpenClaw 2026.5.7 (eeef486)

🦞 OpenClaw 2026.5.7 (eeef486) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

~/.openclaw/openclaw.json

🦞 OpenClaw 2026.5.7 (eeef486) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

Config path not found: plugins.entries.memory-wiki.config.vault.path

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

Wiki vault mode: isolated
Vault: ready (/home/admin/.openclaw/wiki/main)
Render mode: native
Obsidian CLI: missing
Bridge: disabled
Unsafe local: disabled
Pages: 0 sources, 0 entities, 0 concepts, 0 syntheses, 9 reports
Source provenance: 0 native, 0 bridge, 0 bridge-events, 0 unsafe-local, 0 other

🦞 OpenClaw 2026.5.7 (eeef486) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

│
â—‡
Service: systemd user (enabled)
File logs: /var/log/openclaw/openclaw.log
Command: /usr/bin/node /home/admin/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.1.90:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 11941, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

boreal shoreBOT
#

That output confirms it: OpenClaw is not seeing any memory-wiki vault path config.

This line is the key:

Config path not found: plugins.entries.memory-wiki.config.vault.path

So openclaw wiki status is falling back to the default vault:

/home/admin/.openclaw/wiki/main

Your earlier memory.qmd.paths config only tells QMD to index /home/admin/.openclaw/workspace/wiki; it does not configure the memory-wiki plugin.

Add this under the top-level config in ~/.openclaw/openclaw.json:

#
plugins: {
  entries: {
    "memory-wiki": {
      enabled: true,
      config: {
        vaultMode: "isolated",
        vault: {
          path: "/home/admin/.openclaw/workspace/wiki",
          renderMode: "obsidian",
        },
        obsidian: {
          enabled: true,
          useOfficialCli: true,
          vaultName: "OpenClaw Wiki",
          openAfterWrites: false,
#
        },
        render: {
          preserveHumanBlocks: true,
          createBacklinks: true,
          createDashboards: true,
        },
      },
    },
  },
}

Then:

#
openclaw gateway restart
openclaw config get plugins.entries.memory-wiki.config.vault.path
openclaw wiki status
openclaw wiki init
openclaw wiki compile

After that, wiki status should show:

Vault: ready (/home/admin/.openclaw/workspace/wiki)
Render mode: obsidian

One note: your Pi says Obsidian CLI: missing. That’s okay if you’re just opening the folder manually in Obsidian from another machine. The CLI helpers like openclaw wiki obsidian open ... only work if the obsidian CLI exists on that Pi.

gilded sierra
#

The plugins config is incorrect, there should be quotes around items

boreal shoreBOT
#

You’re right — if you’re editing it as strict JSON, quote the keys. OpenClaw’s config is JSON5-ish in many places, but a quoted version is safer to paste.

Use this shape:

"plugins": {
  "entries": {
    "memory-wiki": {
      "enabled": true,
      "config": {
        "vaultMode": "isolated",
        "vault": {
          "path": "/home/admin/.openclaw/workspace/wiki",
          "renderMode": "obsidian"
        },
        "obsidian": {
#
          "enabled": true,
          "useOfficialCli": true,
          "vaultName": "OpenClaw Wiki",
          "openAfterWrites": false
        },
        "render": {
          "preserveHumanBlocks": true,
          "createBacklinks": true,
          "createDashboards": true
        }
      }
    }
  }
}
#

Make sure it’s merged into the top-level object in ~/.openclaw/openclaw.json — don’t add a second top-level { ... } around it if the file already has one.

gilded sierra
#

ok, it;s now in the correct space but when I compile it I only see 9 pages, it appears to be empty

boreal shoreBOT
#

That’s expected if the wiki is in isolated mode and you haven’t ingested/imported anything yet.

The 9 pages are just the generated report/dashboard pages. They’ll be empty until the vault has source/entity/concept/synthesis pages.

You have two choices:

Option A — curated standalone wiki
Import files manually:

openclaw wiki ingest /home/admin/.openclaw/workspace/MEMORY.md
openclaw wiki ingest /home/admin/.openclaw/workspace/LEARNINGS.md
openclaw wiki ingest /home/admin/.openclaw/workspace/memory
openclaw wiki compile
openclaw wiki status
#

Option B — wiki generated from active memory
Switch the plugin to bridge mode:

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

Then:

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

Important bit: your memory.qmd.paths only makes those files searchable by QMD. It does not automatically create wiki pages from them. The wiki needs either ingest or bridge import.

If bridge import still gives 0 sources, paste openclaw wiki doctor — that usually tells us whether the active memory backend is exporting bridge artifacts.

gilded sierra
#

Wiki doctor: 1 issue(s) found Wiki vault mode: bridge Vault: ready (/home/admin/.openclaw/workspace/wiki) Render mode: obsidian Obsidian CLI: missing (requested) Bridge: enabled (100 exported artifacts) Unsafe local: disabled Pages: 100 sources, 0 entities, 0 concepts, 0 syntheses, 9 reports Source provenance: 0 native, 97 bridge, 3 bridge-events, 0 unsafe-local, 0 other Warnings: - Obsidian CLI is enabled in config but obsidian is not available on PATH. Suggested fixes: - Install the official Obsidian CLI or disable obsidian.useOfficialCli.

boreal shoreBOT
#

That’s actually a healthy bridge import now — it’s not empty anymore:

Pages: 100 sources, 0 entities, 0 concepts, 0 syntheses, 9 reports
Bridge: enabled (100 exported artifacts)

What’s happening: bridge mode imported your memory artifacts as source pages. It does not automatically invent entity/concept/synthesis pages from them during compile. compile refreshes indexes/dashboards/digests; it’s not an AI summarization pass.

So in Obsidian, look under:

/home/admin/.openclaw/workspace/wiki/sources/
/home/admin/.openclaw/workspace/wiki/reports/

If you want higher-level pages, create them intentionally, e.g.:

#
openclaw wiki search "topic you care about"
openclaw wiki get <source-id-or-path>
openclaw wiki apply synthesis "My Topic Summary" \
  --body "Summary of the important bits..." \
  --source-id <source.id>
openclaw wiki compile

Or ask an agent to use wiki_search/wiki_get and create syntheses with wiki_apply for the topics you care about.

The only real warning left is:

Obsidian CLI is enabled in config but `obsidian` is not available on PATH
#

If you’re opening the vault manually in Obsidian, disable just this part:

"obsidian": {
  "enabled": true,
  "useOfficialCli": false,
  "vaultName": "OpenClaw Wiki",
  "openAfterWrites": false
}

Then openclaw wiki doctor should be clean. 🦞

gilded sierra
#

Bridge import synced 100 artifacts across 3 workspaces (0 new, 0 updated, 100 unchanged, 0 removed). Indexes not refreshed (no-import-changes).

boreal shoreBOT
#

That message is okay — it means the bridge import found the same 100 artifacts already in the wiki and skipped re-writing/index refresh because nothing changed:

0 new, 0 updated, 100 unchanged
Indexes not refreshed (no-import-changes)

If you want to refresh the generated reports/indexes anyway, run:

openclaw wiki compile
openclaw wiki status

Then inspect the imported content here:

#
ls -la /home/admin/.openclaw/workspace/wiki/sources
ls -la /home/admin/.openclaw/workspace/wiki/reports

The 100 sources, 0 entities, 0 concepts, 0 syntheses state means the wiki currently contains raw/source pages only. That’s normal for bridge import. Higher-level visual pages don’t appear automatically; you create syntheses/entities from those sources with openclaw wiki apply ... or by asking an agent to curate them.

Also, “across 3 workspaces” means bridge found exported memory artifacts from three workspace contexts. That’s not necessarily bad — just worth knowing if you expected only one workspace.

gilded sierra
#

This is running on a headless raspberry pi, is it possible to view the wiki remotely, perhaps using the openclaw dashboard?

boreal shoreBOT
#

Yes — partially via the OpenClaw dashboard, and fully via a remote Markdown/Obsidian workflow.

For the dashboard, open your Pi’s dashboard from another machine:

http://192.168.1.90:18789/

Then go to Dreams / Dreaming → Diary → Memory Palace. That tab is backed by memory-wiki and can preview wiki pages.

One catch: with your current status:

100 sources, 0 entities, 0 concepts, 0 syntheses

Dashboard’s Memory Palace may say it’s not populated yet, because it’s mainly useful once the wiki has syntheses/entities/concepts. Raw bridge-imported source pages live on disk under:

#
/home/admin/.openclaw/workspace/wiki/sources/

For a full visual wiki from a headless Pi, I’d use one of these:

  1. Obsidian on your laptop + remote folder mount

    • Mount the Pi folder with SSHFS/SFTP/rclone.
    • Open /home/admin/.openclaw/workspace/wiki as an Obsidian vault locally.
  2. VS Code Remote SSH

    • Connect to the Pi.
    • Open /home/admin/.openclaw/workspace/wiki.
    • Good for browsing/searching Markdown without needing Obsidian on the Pi.
  3. Dashboard for summaries, Obsidian/VS Code for full vault

    • Best combo, honestly.
#
  • Dashboard = memory palace/preview surface.
    • Obsidian/VS Code = actual source/report browsing.

I would not port-forward the dashboard publicly unless you put it behind proper auth/VPN/Tailscale. LAN or Tailscale is the safer path.

gilded sierra
#

Do you mean 'dreaming' on the web dashboard?

boreal shoreBOT
#

Yes — I mean the Dreaming page in the OpenClaw web dashboard.

Open:

http://192.168.1.90:18789/

Then look for Dreaming / Dreams in the left nav, then the Diary tab. Inside Diary there should be subtabs like:

  • Dreams
  • Imported Insights
  • Memory Palace

Memory Palace is the dashboard view backed by memory-wiki.

But with your current wiki state — 100 sources, 0 entities, 0 concepts, 0 syntheses — Memory Palace may look empty or say it’s not populated yet. That dashboard surface focuses on compiled pages like syntheses/entities/concepts, not raw sources/ imports.

gilded sierra
#

Yes it says memory palace not populated yet

boreal shoreBOT
#

Yep, that matches your wiki status exactly.

The dashboard Memory Palace intentionally doesn’t show raw sources/ pages. It only becomes populated when the wiki has higher-level pages:

entities/
concepts/
syntheses/

Right now you have:

100 sources, 0 entities, 0 concepts, 0 syntheses

So the source imports are there, but nothing has been curated into the “palace” view yet.

#

To confirm the sources exist:

find /home/admin/.openclaw/workspace/wiki/sources -type f | head -20
openclaw wiki search "memory" --max-results 10

To make Memory Palace populate, create at least one synthesis page, for example:

openclaw wiki search "home assistant" --mode source-evidence

Pick one or more source IDs/paths from the results, then:

#
openclaw wiki apply synthesis "Home Assistant Memory Summary" \
  --body "Summary of the useful Home Assistant-related memory from imported sources." \
  --source-id <source.id>

openclaw wiki compile

After that, reload Dreaming → Diary → Memory Palace and it should show a Syntheses cluster.

So: bridge import = raw source layer; Memory Palace = curated compiled layer. You’ve got the first half working now. 🦞

gilded sierra
#

I've only let dreaming happen once as it is scheduled for 3am and I turn the raspberry pi off usually for the night

boreal shoreBOT
#

Ahh yep, that explains why it feels thin. If the Pi is off at 3am, the managed dreaming cron won’t get a chance to run, so the Dreaming UI won’t accumulate much.

Change the dreaming schedule to a time the Pi is usually on. The default is:

"frequency": "0 3 * * *"

You can move it to, say, 8pm:

"plugins": {
  "entries": {
    "memory-core": {
      "config": {
        "dreaming": {
#
          "enabled": true,
          "frequency": "0 20 * * *"
        }
      }
    }
  }
}

Or run it every 6 hours while the Pi is up:

"frequency": "0 */6 * * *"

After changing it:

gilded sierra
#

isn't that every 6 minutes?

boreal shoreBOT
#

Nope — 0 */6 * * * is every 6 hours, at minute 0.

Cron fields are:

minute hour day-of-month month day-of-week

So:

0 */6 * * *

means “minute 0, every 6th hour” → 00:00, 06:00, 12:00, 18:00.

Every 6 minutes would be:

#
*/6 * * * *

Good catch to double-check though — cron syntax is annoyingly easy to misread. 🦞

gilded sierra
#

so how do I check the next dream time from the command line

boreal shoreBOT
#

Use the cron list/show commands — dreaming is a managed cron job named Memory Dreaming Promotion.

Quick view:

openclaw cron list | grep -i dream

That table has a Next column.

For the detailed view, copy the job id from the first column and run:

openclaw cron show <job-id>

That prints fields including:

#
schedule: cron ...
next: ...
last: ...
status: ...

If you prefer JSON:

openclaw cron list --json | jq '.jobs[] | select(.name | test("Dream"; "i")) | {id, name, schedule, nextRunAtMs: .state.nextRunAtMs, status}'

And the general memory-side check is:

#
openclaw memory status --deep

That’s useful for seeing whether dreaming is enabled/blocked, but cron list/show is the best place to see the actual next scheduled time.

gilded sierra
#

so after dreaming has finished, what command do I use to update the wiki

boreal shoreBOT
#

After dreaming finishes, run:

openclaw wiki bridge import
openclaw wiki compile

That does two things:

  • bridge import pulls the latest exported memory/dream artifacts into the wiki sources/ layer.
  • compile refreshes the wiki indexes, reports, dashboards, and cache files.

Then check it with:

openclaw wiki status
#
openclaw wiki lint

If you want the one-liner:

openclaw wiki bridge import && openclaw wiki compile && openclaw wiki status

Small reminder: this updates the wiki source/report layer. The Dashboard Memory Palace still only fills once there are syntheses/, entities/, or concepts/ pages, not just raw imported sources.