Can Hermes Agent fully control (CRUD) my Obsidian vault?

Yes, for a vault stored in the instance. Hermes ships read_file, write_file, patch and search_files plus a terminal tool, and an Obsidian vault is just Markdown files on disk, so it can create, read, edit, move and delete notes and folders. It edits files; it does not drive the Obsidian desktop application itself.

Where should the vault live on a Hermes instance?

Use /opt/data/obsidian-vault. On Hermes the agent runs as the hermes user whose home directory is /opt/data, the persistent mount, so ~/ paths already persist there — unlike OpenClaw, where only ~/.openclaw is persisted. The reason to pin one path is consistency: the Obsidian skills previously named different locations, so an agent could create a second vault beside the one you were using. Set OBSIDIAN_VAULT_PATH so every tool call agrees.

Can Hermes reach the Obsidian vault on my laptop?

Not directly. The instance runs in a datacenter container with no route to your machine. Pair them either by syncing the folder (Obsidian Git, Obsidian Sync via the official obsidian-headless CLI, or Syncthing) or by giving the agent a private network route to your desktop with Tailscale and the Local REST API plugin.

Why did my scheduled Obsidian git pull never run on Hermes?

Hermes containers ship no cron, crond or crontab binary, so a crontab-based schedule silently does nothing. Ask the agent to schedule the periodic pull with the Hermes scheduler instead.

← Home

Integration Guide

Hermes Agent Obsidian Integration — Connect and Control Your Vault

Q: Does the Obsidian integration work on OpenClaw too?

Yes. The difference is the persistent path: OpenClaw keeps the vault at ~/.openclaw/workspace/obsidian-vault, and OpenClaw containers do have crontab. The desktop-side setup is identical. See the OpenClaw Obsidian guide for that walkthrough.

An Obsidian vault is a folder of notes and attachments, and Hermes Agent can create, read, edit and delete files in it directly. This guide covers where the vault has to live on Hermes, how to pair it with the vault already on your laptop, and the two Hermes-specific traps that catch people out.

What Hermes Can Actually Do With a Vault

Hermes ships general-purpose file tools — read_file, write_file, patch and search_files — plus a terminal tool that runs ordinary shell commands. Because an Obsidian vault is just Markdown on disk, that is genuine full CRUD: writing new notes, reading and searching the whole vault, editing and appending, renaming, moving, deleting, and maintaining folders, templates, frontmatter and wikilinks.

What it is not is control of the Obsidian application. Hermes edits the files; your desktop app renders them. Anything that only exists inside the app — a community plugin's runtime behaviour, the graph view, canvas rendering — stays on your machine.

Where the Vault Should Live

Hermes runs the agent as the hermes user, whose home directory is /opt/data — the instance's persistent mount. So a ~/... path on Hermes already lands in persistent storage, and a vault written there survives a container rebuild. This is different from OpenClaw, where the home directory is /home/node and only ~/.openclaw is persisted.

The problem on Hermes is not durability, it is ambiguity. The two Obsidian skills used to name different locations, so an agent could create a second vault beside the one you were already using and then search the empty one. Pick a single canonical path and say so explicitly:

/opt/data/obsidian-vault

Rather than hardcoding it, let the agent resolve it. This is the block both Obsidian skills now use, and it gives the right answer on Hermes and OpenClaw alike:

VAULT="${OBSIDIAN_VAULT_PATH:-${HERMES_HOME:+$HERMES_HOME/obsidian-vault}}"
VAULT="${VAULT:-$HOME/.openclaw/workspace/obsidian-vault}"

Pin it explicitly as well, so every later tool call agrees: OBSIDIAN_VAULT_PATH=/opt/data/obsidian-vault. Persist it where the runtime hands it to subsequent calls — a bare shell export dies with the shell that ran it. If you already have a vault at one of the older locations, the current skill moves it here and tells you what it did.

Quickstart

Open /dashboard/skills, search obsidian, and install the Obsidian skill. It covers vault design and day-to-day operation, and resolves the persistent path above on its own.
Message your bot: “set up my Obsidian vault”. It creates the folder structure under /opt/data/obsidian-vault and confirms the path it used — check that the path it prints starts with /opt/data.
From then on, ask it to search, read, list recent notes, or write new ones in plain language.

Connecting the Vault You Already Have

Your Hermes instance runs in a datacenter container, so it cannot reach a folder on your laptop's disk. Pairing the two means either syncing the folder or giving the agent a network route to your machine. Four options.

Option A: Obsidian Git (free, start here)

Your vault lives in a private GitHub repo. The agent commits and pushes what it changes; your desktop Obsidian pulls and pushes through the community Git plugin. It is the route worth trying first because git is already installed in the instance, so nothing has to be added to the image.

The GitHub CLI is not preinstalled. Ask the agent to install it, then authenticate from the Terminal button on your instance card — gh auth login is an interactive device-code flow, so it needs a real shell, while every later gh command works from chat.

The CLI stores its credentials under ~/.config/gh, which on Hermes is /opt/data/.config/gh — inside the persistent mount, so the login survives a rebuild. The gh binary itself does not; see the traps below.

Then, back in chat: “set up git sync for my Obsidian vault into a private repo”. On your desktop, clone that repo, open the folder as a vault, leave Restricted Mode, and install the Git community plugin by Vinzent.

Point this at a dedicated notes folder, never at a code project — Obsidian Git syncs everything in the folder, which is how people push secrets and node_modules to GitHub by accident.

Option B: Obsidian Sync, official headless client

If you already pay for Obsidian Sync, the official obsidian-headless CLI runs Sync as a background daemon and keeps notes, settings and community plugins in step across laptop, phone and agent. It needs Node 22 or newer, which the Hermes image already has.

npm install -g obsidian-headless
ob login
ob sync-setup --vault "<vault-name>" --path /opt/data/obsidian-vault
ob sync --path /opt/data/obsidian-vault --continuous

Two caveats. The package is an early release, and a global npm install lives in the image layer, not in /opt/data — so after an image upgrade, ask the agent to reinstall it and restart the daemon.

Option C: Syncthing

Syncthing keeps a folder in step between your desktop and the instance and copes with your laptop being behind NAT. It needs a client running at both ends, and the instance-side install has the same rebuild caveat as Option B.

Option D: Local REST API over Tailscale

Use this when you want your laptop to remain the authoritative copy, with no sync cycle at all. The community Local REST API plugin exposes your desktop vault, and Tailscale gives the instance a private route to your machine — you can switch Tailscale on from your instance card, so nothing has to be exposed to the public internet.

It is the most setup of the four. The plugin must bind an address the instance can actually reach rather than loopback only, the tailnet has to admit both machines, and your laptop must be awake with Obsidian running for the agent to see anything. Verify the connection end to end before relying on it. Hermes also supports MCP servers via mcp_servers in its config, so an Obsidian MCP server can ride the same tailnet route if you prefer that shape.

Two Hermes Traps Worth Knowing

There is no crontab. Hermes containers ship no cron, crond or crontab binary, so any instruction that pipes a line into crontab - silently achieves nothing. Hermes has its own scheduler — ask the agent to schedule the periodic git pull with that instead.

Anything you install lives outside persistent storage. The GitHub CLI, obsidian-headless and Syncthing all land in the container layer. The vault in /opt/data survives a rebuild; the tooling around it does not. After a major image upgrade, expect to re-run the install step once.

Does This Work on OpenClaw?

Yes, with a different vault path. OpenClaw persists ~/.openclaw, so the vault belongs at ~/.openclaw/workspace/obsidian-vault, and OpenClaw containers do have crontab. The desktop half of every option above is identical. See the OpenClaw Obsidian guide for that walkthrough.