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

warm pebble Apr 14, 2026, 5:15 AM

#

Can you tell me how to setup new memory-wiki stuff for my agents?

Workspace1: ~/.openclaw/workspace/
Workspace2: ~/.openclaw/workspaces/jon
Workspace3: ~/.openclaw/workspaces/mel
Agent1 dir: ~/.openclaw/agents/main/agent
Agent2 dir: ~/.openclaw/agents/jon/agent
Agent2 dir: ~/.openclaw/agents/mel/agent

Like the idea of having a structured wiki of all their knowledge @exotic adder

split graniteBOT Apr 14, 2026, 5:15 AM

#

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

cedar cloudBOT Apr 14, 2026, 5:15 AM

#

exotic adderBOT Apr 14, 2026, 5:18 AM

#

Yep. The big gotcha is this:

memory-wiki is configured globally under plugins.entries.memory-wiki.config, and from the docs/source I do not see a per-agent memory-wiki override.

So for your setup:

~/.openclaw/workspace/ + ~/.openclaw/agents/main/agent
~/.openclaw/workspaces/jon + ~/.openclaw/agents/jon/agent
~/.openclaw/workspaces/mel + ~/.openclaw/agents/mel/agent

you have two sane options:

Option A, recommended for isolated brains

Run one config/profile per agent, with a different wiki vault path for each:

main → ~/.openclaw/wiki/main
jon → ~/.openclaw/wiki/jon

#

mel → ~/.openclaw/wiki/mel

Use bridge mode if you want the wiki to compile from the active memory layer.

Minimal plugin config for one agent

plugins: {
  entries: {
    "memory-wiki": {
      enabled: true,
      config: {
        vaultMode: "bridge",
        vault: {
          path: "~/.openclaw/wiki/main",
          renderMode: "obsidian",
        },

#

        bridge: {
          enabled: true,
        },
        search: {
          backend: "shared",
          corpus: "all",
        },
        context: {
          includeCompiledDigestPrompt: false,
        },
      },
    },
  },
}

#

For jon and mel, same config, just change:

vault.path: "~/.openclaw/wiki/jon"
vault.path: "~/.openclaw/wiki/mel"

Then run, per config:

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

If you use separate config files, run them against each one, for example with OPENCLAW_CONFIG_PATH.

#

Option B, one gateway with all 3 agents

If all 3 agents live under one single gateway config, then memory-wiki is effectively one shared wiki config.

That means you should use one shared vault, for example:

~/.openclaw/wiki/all

That works, but it is not clean per-agent isolation.

My recommendation

For your layout, I’d do:

main workspace + agentDir + ~/.openclaw/wiki/main
jon workspace + agentDir + ~/.openclaw/wiki/jon
mel workspace + agentDir + ~/.openclaw/wiki/mel

and keep them as 3 separate configs/profiles if you want each agent to have its own structured knowledge wiki.

#

A couple of important notes

Don’t put the wiki inside agentDir.
Don’t reuse agentDir across agents.
bridge mode is the best fit if you want “wiki of all their knowledge”.
If openclaw wiki doctor says bridge has no exported artifacts, either your active memory plugin is not exporting them yet, or you should switch that agent to isolated mode and ingest manually.

Docs:

If you want, paste your redacted openclaw.json/json5 and I’ll map it into the exact main/jon/mel config blocks.

warm pebble Apr 14, 2026, 5:21 AM

#

i choose option A. but what abuot the plugin config?

exotic adderBOT Apr 14, 2026, 5:21 AM

#

Yep, for Option A the plugin config lives in each agent’s own OpenClaw config file/profile.

So the answer is:

not in the workspace
not in agentDir
yes in each config under plugins.entries.memory-wiki

And the important limitation is:

you cannot have 3 separate memory-wiki configs inside one shared gateway config for 3 agents
it is one plugin config per config file

So for Option A, I’d make 3 config files:

~/.openclaw/openclaw-main.json5
~/.openclaw/openclaw-jon.json5

#

~/.openclaw/openclaw-mel.json5

Example, main

{
  agents: {
    list: [
      {
        id: "main",
        workspace: "~/.openclaw/workspace",
        agentDir: "~/.openclaw/agents/main/agent",
      },
    ],
  },

  plugins: {

#

    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          vault: {
            path: "~/.openclaw/wiki/main",
            renderMode: "obsidian",
          },
          bridge: {
            enabled: true,
          },
          search: {
            backend: "shared",
            corpus: "all",

#

          },
          context: {
            includeCompiledDigestPrompt: false,
          },
        },
      },
    },
  },
}

Example, jon

Same thing, just change the paths:

#

{
  agents: {
    list: [
      {
        id: "jon",
        workspace: "~/.openclaw/workspaces/jon",
        agentDir: "~/.openclaw/agents/jon/agent",
      },
    ],
  },

  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,

#

        config: {
          vaultMode: "bridge",
          vault: {
            path: "~/.openclaw/wiki/jon",
            renderMode: "obsidian",
          },
          bridge: {
            enabled: true,
          },
          search: {
            backend: "shared",
            corpus: "all",
          },
          context: {
            includeCompiledDigestPrompt: false,

#

          },
        },
      },
    },
  },
}

Example, mel

{
  agents: {
    list: [
      {
        id: "mel",

#

        workspace: "~/.openclaw/workspaces/mel",
        agentDir: "~/.openclaw/agents/mel/agent",
      },
    ],
  },

  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          vault: {
            path: "~/.openclaw/wiki/mel",
            renderMode: "obsidian",

#

          },
          bridge: {
            enabled: true,
          },
          search: {
            backend: "shared",
            corpus: "all",
          },
          context: {
            includeCompiledDigestPrompt: false,
          },
        },
      },
    },
  },

#

Then initialize each one against its own config:

OPENCLAW_CONFIG_PATH=~/.openclaw/openclaw-main.json5 openclaw wiki init
OPENCLAW_CONFIG_PATH=~/.openclaw/openclaw-main.json5 openclaw wiki doctor

OPENCLAW_CONFIG_PATH=~/.openclaw/openclaw-jon.json5 openclaw wiki init
OPENCLAW_CONFIG_PATH=~/.openclaw/openclaw-jon.json5 openclaw wiki doctor

OPENCLAW_CONFIG_PATH=~/.openclaw/openclaw-mel.json5 openclaw wiki init
OPENCLAW_CONFIG_PATH=~/.openclaw/openclaw-mel.json5 openclaw wiki doctor

#

If you want, send your current redacted config and I’ll turn it into the 3 exact files for you.

warm pebble Apr 14, 2026, 5:26 AM

#

wait. i mean those agents are in one gatewayt

exotic adderBOT Apr 14, 2026, 5:26 AM

#

Ah, got it, that changes the answer. My bad.

If they are all inside one gateway, then memory-wiki is one global plugin config for that gateway.

So today that means:

one plugins.entries.memory-wiki block
one vault.path
not one wiki config per agent

I do not see a documented per-agent memory-wiki setting like:

plugins.entries.memory-wiki.config.agents
per-agent vault.path
agents.list[].plugins...memory-wiki

So for one gateway, do this

#

Use a single shared wiki vault, for example:

{
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          vault: {
            path: "~/.openclaw/wiki/shared",
            renderMode: "obsidian",
          },
          bridge: {
            enabled: true,

#

            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
          },
          search: {
            backend: "shared",
            corpus: "all",
          },
          context: {
            includeCompiledDigestPrompt: false,
          },
        },
      },

#

    },
  },
}

Then:

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

What this gives you

#

one shared structured wiki
your agents can still stay isolated in workspace / auth / sessions
but the wiki layer itself is shared, not split into main, jon, mel

If you want truly separate wikis per agent

Then you need separate gateway configs/processes today.

So the real choice is:

One gateway → one shared wiki
Separate gateways/configs → separate wikis per agent

Docs:

#

If you want, I can help you write the exact one-gateway config next, based on your current agents.list block.

warm pebble Apr 14, 2026, 5:32 AM

#

what abt this?

 "memory-wiki": {
        "enabled": true,
        "config": {
          "vaultMode": "isolated",
          "vault": {
            "path": "/home/redacted/.openclaw/wiki/shared",
            "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": 4,
            "allowUrlIngest": true
          },
          "search": {
            "backend": "shared",
            "corpus": "all"
          },
          "context": {
            "includeCompiledDigestPrompt": false
          },
          "render": {
            "preserveHumanBlocks": true,
            "createBacklinks": true,
            "createDashboards": true
          }
        }
      }

exotic adderBOT Apr 14, 2026, 5:32 AM

#

Close, but I’d fix a few things:

1. `vaultMode`

If you want the wiki to pull from memory automatically, use:

"vaultMode": "bridge"

not "isolated".

With "isolated", the wiki is basically its own curated vault. Your bridge settings don’t match that intent.

2. Syntax error

You’re missing a comma after the bridge block.

3. Obsidian CLI is optional

#

This part is only needed if you actually installed the official obsidian CLI and want OpenClaw to use it:

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

If not, set:

"enabled": false,
"useOfficialCli": false

#

You can still keep:

"renderMode": "obsidian"

and get Obsidian-friendly markdown without the CLI.

4. I’d start with `maxConcurrentJobs: 1`

Safer first. You can raise it later.

Corrected version

#

"memory-wiki": {
  "enabled": true,
  "config": {
    "vaultMode": "bridge",
    "vault": {
      "path": "/home/redacted/.openclaw/wiki/shared",
      "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
    }
  }
}

Then run:

#

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

If you want, paste the surrounding plugins block too and I’ll sanity-check the whole thing.

warm pebble Apr 14, 2026, 5:35 AM

#

after i turn this on should i disable my openviking?

exotic adderBOT Apr 14, 2026, 5:35 AM

#

Probably no.

memory-wiki does not replace the active memory layer, it sits beside it. In bridge mode, it actually depends on the active memory plugin exporting artifacts.

So:

if OpenViking is your current memory backend / recall system → keep it enabled
if OpenViking is a separate duplicate wiki/notes plugin and you do not want double-writing → maybe disable it

I don’t recognize openviking as a built-in OpenClaw plugin, so the safe rule is:

don’t disable it just because you enabled memory-wiki

Only disable it if you know it is doing overlapping wiki storage you no longer want.

If you paste just these redacted bits, I can tell you exactly:

#

plugins.slots.memory
plugins.entries
memory

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

warm pebble Apr 14, 2026, 5:44 AM

#

Then should i instruct all of my agents to ingest/migrate their brains into this? if so, then give me the proper prompt

exotic adderBOT Apr 14, 2026, 5:44 AM

#

I wouldn’t tell them to “migrate their whole brains” 😅

That usually creates a noisy wiki full of junk, duplicates, and confident nonsense.

Better approach

Turn on memory-wiki

Run:

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

Then ask each agent to do a small curated pass into the shared wiki

Because you’re on one gateway + one shared wiki, I’d make each agent namespace its syntheses like:

#

[main] ...
[jon] ...
[mel] ...

Prompt to send each agent

Use this, with the agent name swapped in:

You now have access to a shared memory wiki.

Your job is to curate durable knowledge into the wiki, not dump everything.

Rules:
- Search before writing. Use wiki_search first.
- Read existing pages with wiki_get before creating anything new.
- Prefer updating or extending existing knowledge over creating duplicate pages.

#

- Only capture durable, high-value knowledge:
  - long-lived projects
  - people and relationships
  - recurring preferences
  - systems, workflows, environments
  - stable facts, decisions, and important patterns
- Do not copy ephemeral chat, temporary tasks, or raw conversation noise.
- Do not store secrets, tokens, passwords, or private credentials in the wiki.
- If something is uncertain, record it as a question or contradiction instead of guessing.
- When creating a synthesis page, prefix the title with [AGENT_ID], for example [main], [jon], or [mel].
- Include evidence/source references when available.
- After making updates, run wiki_lint and fix obvious issues.

Task:
Review your durable knowledge and create or update up to 5 high-value synthesis pages in the shared wiki.

#

Focus on quality over quantity.

My recommendation

Start with just 3 to 5 pages per agent, not a giant import.

That gives you a much cleaner wiki.

If you want, I can also give you:

a short persistent AGENTS.md rule for all agents, and
a one-time bootstrap prompt for main, jon, and mel individually.

warm pebble Apr 14, 2026, 5:48 AM

#

and by the way actually i've implemented andrej karpathy's llm-wiki concept previously stored in ~/.openclaw/wiki_llm/ then what should i do now?

exotic adderBOT Apr 14, 2026, 5:48 AM

#

Nice, that actually makes this easier.

I would not throw away ~/.openclaw/wiki_llm/, and I also would not point memory-wiki directly at it unless it already matches the new vault layout.

What I’d do

Treat ~/.openclaw/wiki_llm/ as a legacy source archive.

Then:

keep the new live vault at something like
~/.openclaw/wiki/shared
enable memory-wiki there
use the old wiki_llm as migration source material
selectively ingest / rewrite the best content into the new wiki

Why

The new memory-wiki expects its own structure and compile pipeline. Your old Karpathy-style wiki is useful input, but it is not automatically the same thing as the new managed vault.

#

Best migration strategy

Don’t bulk dump everything.

Start with the high-value stuff from ~/.openclaw/wiki_llm/:

stable projects
people
systems
preferences
long-lived notes
decision docs

Then bring those over as curated pages.

Practical flow

#

openclaw wiki init
openclaw wiki doctor
openclaw wiki ingest ~/.openclaw/wiki_llm/some-good-note.md
openclaw wiki compile
openclaw wiki lint

Repeat for the best legacy files first.

My recommendation

old wiki_llm = archive / source material
new memory-wiki vault = live managed knowledge layer

Only archive/delete the old one after the new wiki looks good.

Good one-time prompt for agents

#

Use ~/.openclaw/wiki_llm as legacy source material, not as the live wiki.

Your task is to migrate only durable, high-value knowledge into the new shared memory wiki.

Rules:
- Search the current wiki first.
- Read one legacy page at a time.
- Do not copy raw pages blindly.
- Prefer creating or updating concise synthesis pages.
- Preserve provenance to the legacy source when possible.
- Skip low-value, stale, or purely conversational content.
- Do not migrate secrets or credentials.
- Stop after 3 to 5 high-value pages and report what was migrated.

That’s the cleanest path, honestly.

#

If you want, I can help you design a legacy-wiki → memory-wiki migration pass next.

warm pebble Apr 14, 2026, 5:50 AM

#

exotic adder ```bash openclaw wiki init openclaw wiki doctor openclaw wiki ingest ~/.openclaw...

i don't want to scan them manually. how to make it bulk?

exotic adderBOT Apr 14, 2026, 5:50 AM

#

Yep, for bulk, I’d use the CLI, not an agent prompt.

Best way

Temporarily set:

ingest: {
  autoCompile: false
}

Then bulk ingest all Markdown files, and compile once at the end.

Simple bulk import

find ~/.openclaw/wiki_llm -type f -name '*.md' -print0 |

#

while IFS= read -r -d '' f; do
  echo "Ingesting: $f"
  openclaw wiki ingest "$f"
done

openclaw wiki compile
openclaw wiki lint

Safer version with a few exclusions

find ~/.openclaw/wiki_llm \
  -type f -name '*.md' \
  ! -path '*/.git/*' \
  ! -path '*/node_modules/*' \

#

  ! -path '*/archive/*' \
  -print0 |
while IFS= read -r -d '' f; do
  echo "Ingesting: $f"
  openclaw wiki ingest "$f"
done

openclaw wiki compile
openclaw wiki lint

Important note

This will bulk-import them as sources. That’s fine, but expect the wiki to be a bit messy at first.

So I’d do it in this order:

#

bulk ingest legacy markdown
openclaw wiki compile
openclaw wiki lint
then let agents create syntheses from the imported sources

After bulk import

Then give agents a smaller prompt like:

The legacy wiki has been bulk-ingested into memory-wiki as source material.

Your job is not to re-import it.
Your job is to search the imported sources, identify the highest-value durable knowledge, and create or improve synthesis pages.
Prefer consolidation over duplication.

If you want, I can give you a single copy-paste migration script tuned for ~/.openclaw/wiki_llm/.

warm pebble Apr 14, 2026, 5:51 AM

#

hmm what if we let the agents do that?

exotic adderBOT Apr 14, 2026, 5:51 AM

#

You can, but I would not let all 3 agents bulk-write at once.

With one shared wiki, parallel agent migration is a great way to get:

duplicate pages
conflicting syntheses
noisy writes
agents stepping on each other

Best pattern

Yes to agents, but only for curation.
No to agents as the raw bulk shovel.

Recommended split

CLI bulk-ingests the old wiki_llm files as sources
One agent at a time turns those sources into good syntheses
Later, all agents can read/use the shared wiki normally

#

If you really want agents to do the migration

Use one designated migration agent, not all 3.

Good rule

main = migration/curation agent
jon + mel = leave them out until the wiki is settled

Prompt for one migration agent

You are the migration agent for the shared memory wiki.

Your job is to process legacy knowledge from ~/.openclaw/wiki_llm and convert it into clean, durable wiki knowledge.

Rules:
- Work in small batches, 5 to 10 files at a time.
- Search the wiki before writing anything.

#

- Prefer updating existing syntheses over creating duplicates.
- Do not copy raw files blindly.
- Extract durable knowledge only: projects, people, systems, preferences, long-lived decisions, recurring patterns.
- Do not migrate secrets, tokens, credentials, or low-value chat noise.
- If something is uncertain, record it as an open question instead of guessing.
- After each batch, run wiki_lint and summarize what changed.
- Stop after each batch and wait for review before continuing.

Goal:
Create a clean, compact knowledge layer, not a full dump of the legacy wiki.

My honest recommendation

The sweet spot is:

CLI for bulk source import

#

1 agent for synthesis cleanup

That gets you speed without turning the wiki into soup.

If you want, I can write you the exact migration workflow:

bulk import command
migration-agent prompt
post-migration cleanup prompt

warm pebble Apr 14, 2026, 6:13 AM

#

then how to access the obsidian? the openclaw gateway is on remote device, so how to use obsidian in my local connected to that remote device?

exotic adderBOT Apr 14, 2026, 6:14 AM

#

Yep, that’s the key catch:

If the gateway is remote, then openclaw wiki obsidian ... runs on the remote machine, not on your laptop/desktop.

So it won’t magically open your local Obsidian app.

Best setup for remote gateway + local Obsidian

In the remote OpenClaw config

Keep:

vault: {
  path: "~/.openclaw/wiki/shared",
  renderMode: "obsidian"
}

#

But I’d usually set:

obsidian: {
  enabled: false,
  useOfficialCli: false
}

Why: the official Obsidian CLI integration is mainly useful when Obsidian is on the same machine as the gateway.

Then access the vault locally

Make the remote vault available on your local machine using one of these:

Obsidian Sync
Syncthing
Git

#

rsync
SSHFS / network mount

Then open the synced/mounted folder in your local Obsidian app.

Recommended mental model

remote gateway writes the wiki files
local Obsidian reads the same vault via sync/mount
renderMode: "obsidian" makes the Markdown Obsidian-friendly
obsidian.useOfficialCli is optional, and usually not what you want for a remote host

My recommendation

For your setup:

remote OpenClaw writes to ~/.openclaw/wiki/shared
sync/mount that folder locally
open that folder as an Obsidian vault on your computer

#

That’s the cleanest setup.

Docs:

If you want, I can suggest the best sync method for your setup:

VPS/Linux server
home server
cloud VM
Tailscale/SSH access

warm pebble Apr 14, 2026, 6:23 AM

#

exotic adder That’s the cleanest setup. Docs: - <https://docs.openclaw.ai/plugins/memory-wik...

yup

exotic adderBOT Apr 14, 2026, 6:24 AM

#

Nice. My default recommendation is:

Best default

Syncthing between:

remote: ~/.openclaw/wiki/shared
local: something like ~/Obsidian/OpenClaw Wiki

Why Syncthing:

local Obsidian stays fast
full-text search is local
works even if the server connection blips
better UX than live-mounting a remote folder

Good alternatives

1. Syncthing , best for daily use

#

Use this if:

the remote box is always on
you want Obsidian to feel normal/local
you may browse/search a lot

2. SSHFS , simplest

Use this if:

you already use SSH/Tailscale
you want the remote vault mounted directly
you do not want a duplicate local copy

Downside: can feel slower/jankier than Syncthing.

3. rsync , safest/simple one-way sync

Use this if:

you mostly want read access locally
you want a very controlled sync flow

#

Downside: not as seamless.

My actual pick

home server / always-on Linux box → Syncthing
VPS with Tailscale/SSH → Syncthing if you want a real Obsidian workflow, otherwise SSHFS
read-mostly / cautious setup → rsync

Important editing rule

If you edit locally in Obsidian:

human notes/comments are fine
but for managed wiki content, prefer wiki_apply / openclaw wiki ...
don’t hand-edit generated sections unless you know what you’re doing

If you tell me:

local OS
remote OS
whether you already use Tailscale

#

and whether you want 2-way sync or just read-only local access

…I can tell you the exact best setup in one reply.

#

For Windows local + Ubuntu remote, I’d go with Syncthing. That’s the cleanest setup.

Recommended setup

Remote Ubuntu vault: ~/.openclaw/wiki/shared
Local Windows folder: something like
C:\Users\YOURNAME\Documents\OpenClaw Wiki

Then open that local Windows folder in Obsidian.

Why Syncthing is the best fit here

Obsidian on Windows works best with a normal local folder
faster and less flaky than mounting a remote Linux folder live
keeps working if the network hiccups
easy 2-way sync if you want local edits too

I’d configure it like this

On Ubuntu

#

Share:

~/.openclaw/wiki/shared

On Windows

Receive into:

C:\Users\YOURNAME\Documents\OpenClaw Wiki

Then in Obsidian:

Open folder as vault
point it at C:\Users\YOURNAME\Documents\OpenClaw Wiki

Small recommendation

Turn on file versioning in Syncthing.

#

That gives you a safety net if a sync goes weird.

What I would not use first

SMB/network share over the internet , too annoying
SSHFS on Windows , workable, but usually jankier than Syncthing
remote Obsidian CLI integration , not helpful if Obsidian is on your Windows machine

OpenClaw side

Keep renderMode: "obsidian".

I’d usually keep:

obsidian: {
  enabled: false,
  useOfficialCli: false
}

#

because the gateway is remote.

If you want, I can give you the exact Syncthing folder pair + final memory-wiki config for this Windows/Ubuntu setup.

warm pebble Apr 14, 2026, 6:27 AM

#

what about ssh tunnel? i've connected the tailscale also

exotic adderBOT Apr 14, 2026, 6:28 AM

#

Yep, with Tailscale in place, SSH is totally viable , but I’d separate two ideas:

Important distinction

SSH tunnel forwards ports.
Obsidian needs a folder.

So for Obsidian, the useful SSH-based option is really:

SSHFS / SFTP-mounted folder over Tailscale
not just a plain SSH tunnel

With your setup, I’d rank it like this

1. Tailscale + Syncthing , still my top pick

Best if you want:

normal local Obsidian performance
fast search

#

fewer Windows filesystem weirdness issues

2. Tailscale + SSHFS , good if you want direct live access

Best if you want:

no duplicate local copy
direct access to the remote vault
simpler “one source of truth”

Downsides:

slower than local sync
Windows + SSHFS can be a bit janky
Obsidian may feel worse on a large vault

3. Tailscale + rsync/manual sync

Best if you want:

controlled one-way or periodic sync
less magic

#

My honest recommendation

If this is your daily Obsidian workflow:

Use Tailscale for secure connectivity, but still use Syncthing for the vault.

If this is just occasional browsing/editing:

Tailscale + SSHFS is fine.

In one sentence

best UX = Syncthing
best “live remote folder” = SSHFS over Tailscale
plain SSH tunnel alone = not enough for Obsidian vault access

If you want, I can give you the exact Windows + Ubuntu + Tailscale + SSHFS path next, or the Syncthing setup.

warm pebble Apr 14, 2026, 6:32 AM

#

i mean i just need obsidian dashboard to monitor it

exotic adderBOT Apr 14, 2026, 6:32 AM

#

Ah, if you just want the Obsidian dashboard to monitor it, then keep it simple:

Best fit for your use case

I’d do one-way / read-only local access.

My pick

Tailscale + Syncthing (receive-only on Windows)

Why:

local Obsidian stays fast
no weird Windows SSHFS issues
safer if you mainly want to monitor, not edit
you can make the Windows copy effectively read-only

Good alternative

Tailscale + SSHFS read-only mount

#

That works if:

you want zero local copy
you only open it occasionally
you’re okay with some lag

For “dashboard only”, SSHFS is actually fine.

On the OpenClaw side

You really just need:

vault: {
  path: "~/.openclaw/wiki/shared",
  renderMode: "obsidian"
},
render: {

#

  createDashboards: true
},
obsidian: {
  enabled: false,
  useOfficialCli: false
}

Then make sure the remote keeps compiling:

openclaw wiki compile

or let auto-compile do its thing.

#

So, short answer

If you’re monitoring only:

best UX: Syncthing, local receive-only copy
best no-copy option: SSHFS over Tailscale
no need for remote Obsidian CLI

If you want, I can give you the exact “monitor-only” setup for either:

Syncthing receive-only
SSHFS over Tailscale

warm pebble Apr 14, 2026, 6:35 AM

#

hmm not read-only. but just like i open the obsidian in that remote device

exotic adderBOT Apr 14, 2026, 6:36 AM

#

Ah, if you literally want to run Obsidian on the Ubuntu box itself and view/use that, then you’re talking about a remote desktop setup, not just memory-wiki.

Short answer

Yes, but only if the remote Ubuntu machine has a GUI desktop and Obsidian installed.

Then you’d use:

RDP / xrdp
VNC
or another remote desktop tool over Tailscale

Important catch

openclaw wiki obsidian ... can only open Obsidian on the remote machine.
It does not stream the app window to your Windows PC.

So you need both:

#

Obsidian installed on Ubuntu
remote desktop access to that Ubuntu GUI

If the Ubuntu box is headless

Then this is basically not the right path.

If you do want the remote-GUI route

Then your config can use:

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

#

But again, that only helps on the Ubuntu machine itself.

My honest recommendation

If this is a real server/VPS, I would not do “remote Obsidian app on the server”.

I’d still do one of these instead:

editable local Obsidian via Syncthing
or editable live mount via SSHFS over Tailscale

Much less annoying.

If you want, I can tell you which route is better for you:

remote Ubuntu desktop + Obsidian there
local Windows Obsidian + synced/mounted vault

warm pebble Apr 14, 2026, 6:39 AM

#

so it can't be selfhosted?

exotic adderBOT Apr 14, 2026, 6:40 AM

#

It can absolutely be self-hosted.

The thing that is self-hosted is:

the OpenClaw gateway
the memory-wiki vault
the Markdown files / dashboards / reports

What is not really “self-hosted” in the web-app sense is Obsidian itself.
Obsidian is a desktop app, not a browser dashboard you expose from your server.

So the split is:

Yes, self-hosted

Ubuntu box runs OpenClaw
Ubuntu box stores ~/.openclaw/wiki/shared
OpenClaw generates the wiki + dashboards there

#

Not in the “open a web URL” sense

Obsidian is not a self-hosted web frontend
you either:
- open the vault in your local Obsidian app, or
- run Obsidian on the remote machine and use remote desktop

So the real answer

memory-wiki → yes, self-hosted
Obsidian UI → desktop app workflow, not self-hosted web UI

If what you want is:

“Self-hosted knowledge on my server”

Yes, totally.

“A browser dashboard I can open anywhere”

Obsidian is the wrong shape for that.

#

That’s the actual distinction. If you want, I can help you choose between:

local Obsidian + synced vault
remote Ubuntu desktop + Obsidian there
a more web-style self-hosted viewer

warm pebble Apr 14, 2026, 6:42 AM

#

alright. but can we do it through X11?

exotic adderBOT Apr 14, 2026, 6:42 AM

#

Technically yes, but I really wouldn’t recommend it.

For your setup, Windows local + Ubuntu remote + Obsidian (Electron app) over X11 forwarding is usually:

slow
flaky
awkward on Windows
worse than just syncing/mounting the vault

If you mean “is it possible?”

Yes, in principle:

Ubuntu runs Obsidian
Windows runs an X server
you connect with ssh -X or ssh -Y

But in practice

#

Obsidian is not the kind of app I’d want to use over X11 forwarding.
It’s much heavier than a tiny Linux utility window.

My honest take

possible: yes
good idea: no

If you want remote GUI, RDP/VNC is better.
If you want a sane Obsidian workflow, Syncthing or SSHFS is better.

So I’d rank it:

Syncthing , best overall
SSHFS over Tailscale , okay
RDP/VNC to remote Ubuntu desktop , if you really want remote app UI
X11 forwarding , last choice

#

If you want, I can still tell you exactly how X11 would work, but I’m a little worried it’ll be more pain than it’s worth.

warm pebble Apr 14, 2026, 6:46 AM

#

alright lets implement your recommendation. guide me

exotic adderBOT Apr 14, 2026, 6:47 AM

#

Yep, let’s do the recommended path:

remote Ubuntu = OpenClaw + memory-wiki
local Windows = Obsidian
sync = Syncthing

0. First, tell me your version

Run:

openclaw --version

1. Add this `memory-wiki` config on the Ubuntu box

Put this under plugins.entries in your OpenClaw config:

#

"memory-wiki": {
  "enabled": true,
  "config": {
    "vaultMode": "bridge",
    "vault": {
      "path": "~/.openclaw/wiki/shared",
      "renderMode": "obsidian"
    },
    "obsidian": {
      "enabled": false,
      "useOfficialCli": 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
    }
  }
}

2. Restart OpenClaw

openclaw gateway restart

#

3. Initialize and verify the wiki

Run on Ubuntu:

openclaw wiki init
openclaw wiki doctor
openclaw wiki status
openclaw wiki compile

If you already have legacy content later, we can bulk-ingest ~/.openclaw/wiki_llm/, but don’t do that yet.

4. Set up Syncthing

On Ubuntu

Share this folder:

#

~/.openclaw/wiki/shared

On Windows

Create a local folder, for example:

C:\Users\<you>\Documents\OpenClaw Wiki

Install Syncthing on both machines, pair them, and sync:

Ubuntu source: ~/.openclaw/wiki/shared
Windows destination: C:\Users\<you>\Documents\OpenClaw Wiki

If you want editing from Windows too, make it normal two-way sync.

#

If you just want safer monitoring first, start receive-only and switch later.

5. Open it in Obsidian on Windows

In Obsidian:

Open folder as vault
choose:
C:\Users\<you>\Documents\OpenClaw Wiki

You should then see the generated wiki, including dashboards/reports.

6. Optional later, migrate your old `wiki_llm`

After the above works, we can do bulk import from:

~/.openclaw/wiki_llm

#

Send me back these 2 things

output of:

openclaw --version

output of:

openclaw wiki doctor

If this fixed it later, please right-click the solution message → Apps → ✅ Mark Solution so it lands on Answer Overflow 🎉

warm pebble Apr 14, 2026, 6:52 AM

#

exotic adder ```text ~/.openclaw/wiki/shared ``` ### On Windows Create a local folder, for e...

guide me into the details! i never used syncthing

exotic adderBOT Apr 14, 2026, 6:53 AM

#

Yep, let’s do Syncthing step by step. This is the simplest path:

Goal

Ubuntu remote keeps the real wiki at
~/.openclaw/wiki/shared
Windows local gets a synced copy at
C:\Users\<you>\Documents\OpenClaw Wiki
Obsidian on Windows opens that local folder

1. Install Syncthing on both machines

Ubuntu 24.04

You can use Ubuntu’s package or the official repo. Easiest first try:

#

sudo apt update
sudo apt install syncthing

Then start it:

systemctl --user enable --now syncthing

If that complains because no user session is active, just run:

syncthing

#

once for initial setup.

Windows

Download/install from:

https://syncthing.net/downloads/
Getting started: https://docs.syncthing.net/intro/getting-started.html

After install, start Syncthing.

2. Open the Syncthing web UI on both machines

On each machine, open:

#

http://127.0.0.1:8384

You should see the Syncthing dashboard.

3. Pair the two devices

On Ubuntu

In Syncthing, top right: Actions → Show ID
Copy the Device ID

On Windows

Click Add Remote Device
Paste the Ubuntu Device ID

#

Name it something like: ubuntu-openclaw
Save

Now do the reverse too:

On Windows

Actions → Show ID
Copy the Windows Device ID

On Ubuntu

Click Add Remote Device
Paste the Windows Device ID
Name it something like: windows-obsidian
Save

After a moment, both devices should show as connected.

#

4. Create the wiki folder on Ubuntu

Make sure this exists on Ubuntu:

mkdir -p ~/.openclaw/wiki/shared

And make sure OpenClaw is writing there.

5. Share the wiki folder from Ubuntu to Windows

On Ubuntu Syncthing UI

Click Add Folder and use:

#

Folder Label: OpenClaw Wiki
Folder ID: openclaw-wiki
Folder Path: /home/<your-ubuntu-user>/.openclaw/wiki/shared

Then under Sharing:

check the Windows device

For now, use:

Folder Type: Send & Receive

That matches your “not read-only” goal.

Save.

6. Accept the folder on Windows

#

Windows Syncthing should pop up asking to add the shared folder.

Set:

Folder Path:
C:\Users\<you>\Documents\OpenClaw Wiki

Then save.

Syncthing will start copying files.

7. Wait for first sync

Let it finish the initial scan/sync.

You should see the folder contents appear on Windows.

#

Good sign: you start seeing things like:

index.md
reports/
entities/
concepts/
.openclaw-wiki/

8. Open it in Obsidian on Windows

In Obsidian:

Open folder as vault
choose
C:\Users\<you>\Documents\OpenClaw Wiki

#

Now you’re looking at the synced wiki locally.

9. Important editing rule

Since OpenClaw will also write here:

okay: notes, human blocks, browsing, dashboards
be careful: don’t manually mangle generated sections/pages
for structured changes, prefer wiki_apply / openclaw wiki ...

10. Nice cleanup

Syncthing creates a default folder sometimes. You can ignore or remove that later so you only keep the wiki folder.

#

If pairing doesn’t work

Since you already have Tailscale, connectivity should usually be easy. If Syncthing discovery acts weird, we can force it to use the Tailscale IP/name next.

Your next 2 checks

On Ubuntu, run:

openclaw wiki status
openclaw wiki doctor

And tell me:

does Syncthing show Connected on both sides?
does the Windows folder receive files?

#

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow 🎉

cedar cloudBOT Apr 14, 2026, 7:16 AM

#

warm pebble Apr 14, 2026, 8:03 AM

#

exotic adder ## If pairing doesn’t work Since you already have Tailscale, connectivity should...

best solution! thanks a lot!

#memory wiki setup

Option A, recommended for isolated brains

Minimal plugin config for one agent

Option B, one gateway with all 3 agents

My recommendation

A couple of important notes

Example, main

Example, jon

Example, mel

So for one gateway, do this

What this gives you

If you want truly separate wikis per agent

1. vaultMode

2. Syntax error

3. Obsidian CLI is optional

4. I’d start with maxConcurrentJobs: 1

Corrected version

Better approach

Prompt to send each agent

My recommendation

What I’d do

Why

Best migration strategy

Practical flow

My recommendation

Good one-time prompt for agents

Best way

Simple bulk import

Safer version with a few exclusions

Important note

After bulk import

Best pattern

Recommended split

If you really want agents to do the migration

Good rule

Prompt for one migration agent

My honest recommendation

Best setup for remote gateway + local Obsidian

In the remote OpenClaw config

Then access the vault locally

Recommended mental model

My recommendation

Best default

Good alternatives

1. Syncthing , best for daily use

2. SSHFS , simplest

3. rsync , safest/simple one-way sync

My actual pick

Important editing rule

Recommended setup

Why Syncthing is the best fit here

I’d configure it like this

On Ubuntu

On Windows

Small recommendation

What I would not use first

OpenClaw side

Important distinction

With your setup, I’d rank it like this

1. Tailscale + Syncthing , still my top pick

2. Tailscale + SSHFS , good if you want direct live access

3. Tailscale + rsync/manual sync

My honest recommendation

In one sentence

Best fit for your use case

My pick

Good alternative

On the OpenClaw side

So, short answer

Short answer

Important catch

If the Ubuntu box is headless

If you do want the remote-GUI route

My honest recommendation

Yes, self-hosted

Not in the “open a web URL” sense

So the real answer

“Self-hosted knowledge on my server”

“A browser dashboard I can open anywhere”

If you mean “is it possible?”

1. `vaultMode`

4. I’d start with `maxConcurrentJobs: 1`

1. Add this `memory-wiki` config on the Ubuntu box

6. Optional later, migrate your old `wiki_llm`