Obsidian Vault lets your agent keep its memory inside your own Obsidian vault instead of a store buried in a device-local folder. Everything the agent learns lands as plain Markdown you can open, read, and edit in Obsidian — and because the vault lives on Google Drive, that memory follows you from one device to the next. It also knows how to cope with the mess cloud sync leaves behind, spotting the conflict and duplicate files Drive scatters around so your memory stays clean. This is a storage backend the memory engine picks up and runs on its own, so nothing in your normal workflow calls it directly. It stands alone — it needs no other plugin, only a vault to point at.

This plugin is the sole vault-backend implementation — the agentm kernel's built-in vault backend was deleted at the V5-3 cutover (agentm v5.5.0, 2026-06-17; see agentm's scripts/backend_selection.py:32). It's opt-in via storage.backend=vault (see Install the vault backend).

How memory reaches the vault — the engine hands each save to the backend, which writes plain Markdown into the Drive-synced folder while watching for the conflict files sync leaves behind:

How it composes — obsidian-vault requires and enhances nothing, standing alone on the AgentM memory engine that discovers and loads it:

The heart of the plugin is a storage backend — the piece the memory engine writes to and reads from. When you point the engine at your vault, it hands every save to this backend, which writes the memory out as Markdown into the folder Drive keeps in sync. Because that folder can be open on more than one machine at once, the backend takes care to let two sessions write to the same vault without clobbering each other's work. It leans on the engine's own building blocks to do that rather than carrying its own copies, so it always runs as part of the engine, never on its own.

Cloud sync has a habit of leaving litter behind — a duplicate here, a "conflicted copy" there — whenever two devices touch the same file. The plugin knows what those stray files look like and can point them out so you can clean them up. On Claude Code it does this for you at the start of a session; everywhere else, a small health check surfaces the same thing on demand and confirms your vault is wired up and conflict-free.

Direction	Plugin	How
Enhances (soft)	—	None.
Enhanced by (soft)	—	None.
Requires (hard)	—	None. The plugin is standalone (requires: []); it depends on the agentm memory engine at runtime, not on another crickets plugin.
Required by (hard)	—	None.

Obsidian vault backend is opinionated about where memory lives, and it will not fit everyone. Reach for something else if:

• You don't keep an Obsidian vault, or you don't sync one through Google Drive — the device-local backend the engine ships with needs no plugin and no setup.
• You want a store with server-side encryption or true multi-writer transactions; this backend stores plain Markdown and reconciles concurrent writes by comparing file contents, not through a database.
• You'd rather not deal with sync-conflict files at all. Cross-device Drive sync produces them, and while the plugin detects and surfaces them, resolving each pair is still your call.

The plugin is mostly a scripts/ backend payload the agentm engine loads; the only thing you drive by hand is the vault-doctor health check. Each primitive links to the source that implements it.

Primitive	Kind	What it does
vault-doctor	skill	A read-only health check — your vault path, which backend is active, and a conflict sweep. Works on both hosts.
conflict-merger-session-start	hook	Surfaces the conflict and duplicate files Drive sync leaves behind, at session start (Claude Code only).
storage_vault.py	script	The vault backend itself — reads and writes your memory as Markdown, sharing the engine's write-lock so two sessions don't clobber each other.
doctor_vault.py	script	The read-only probe behind vault-doctor — checks the vault path, the active backend, and conflicts; it writes nothing.
vault_conflicts.py	script	Detects Google Drive's sync-conflict and duplicate files, reusing the engine's own filename classifier.

The engine talks to every storage backend through the same small set of operations, and the vault backend implements them: resolve a location, read, write, list a directory, and check whether something exists — plus two conveniences, get info and make a directory. Alongside those it tells the engine what it can and can't do, so the engine knows what it's working with:

The backend…
handles concurrent writers	yes — two sessions can write to the same vault safely
produces conflict files	yes — cross-device sync leaves them, and the backend detects them
encrypts at rest	no — memory is stored as plain Markdown
syncs across devices	yes — through Google Drive
conflict strategy	a whole-file merge for Drive's conflicted copies

These per-operation contracts are locked and test-covered by the dedicated obsidian-vault-conformance CI job (see CI gates).

The engine discovers the plugin by looking in a known place under your plugin-install directory, and ranks a vault it detects there. If you tell the engine to use the vault backend but the plugin isn't installed, it stops and says so rather than quietly falling back to the device-local store. To keep concurrent writes safe it shares the engine's own write-lock rather than carrying a copy, and it only ever runs as part of a running engine. On install it reads your existing vault path in place — it never rewrites your config, and it moves no data, so there's nothing to re-set-up.

The backend is fully live — the sole vault-backend implementation since the V5-3 cutover (agentm v5.5.0, 2026-06-17). Beyond the vault-doctor health check and conflict detection, it serves as the actual memory store: it stores and reads back your Markdown exactly, and it correctly refuses a write when another session changed the same file first (the concurrency guard). The dedicated obsidian-vault-conformance CI job runs the conformance + discovery + doctor suites against a checked-out agentm kernel on every push (Linux + Windows) — see CI gates. The full contract is described in the obsidian-vault design.

Host	Automatic nudge	Detection
Claude Code	yes — fires at session start	reachable automatically and on demand
Antigravity	no — there's no session-start event to hang it on	reachable on demand, through the vault-doctor check

On Antigravity you don't lose conflict detection — only the automatic nudge. The vault-doctor skill and its conflict check work on both hosts. See the Antigravity limitations register for the host-gap context.

The vault location is resolved at runtime, not baked into the plugin. The engine reads plugins.obsidian-vault.vault_path from its config (set via agentm_config --vault-path) and joins memory_root onto it; $MEMORY_ROOT is the per-invocation override for that result ($MEMORY_VAULT_PATH, the old name, is still read as a deprecated alias for one release). The plugin itself reads that path in place and never writes it. There's nothing else to configure — it works out of the box once a vault is set.

• Install the vault backend — install the plugin and point the engine at your vault.
• CI gates — the gate battery this backend's conformance suite runs in.
• Plugin anatomy — what a crickets plugin's scripts/ payload is.
• Antigravity limitations — why the automatic session-start nudge is Claude-only, and the host-gap register it belongs to.
• obsidian-vault design · vault-git design — the deeper design.

Reference · Architecture · Home