obsidian-second-brain: a markdown memory layer that eight CLI agents share

The gap it targets: session memory versus vault memory

The README states the problem directly: Claude Code has no persistent memory across sessions, and neither does Grok Bot, Codex, Gemini or the others. A session ends and the context is gone. Meanwhile the notes accumulate in Obsidian and stay inert. The project's framing is that you already own the long-term memory, and the tool doing the thinking cannot reach it.

The intended user is named in the README: developers, founders and operators, writers, researchers, with four role presets chosen at setup. That is a narrower audience than "anyone with an Obsidian vault". The workflow assumes you talk to a CLI agent daily, that decisions and people recur across projects, and that you would rather have those facts in files you can open than in a provider's memory store. If you use one agent occasionally and your notes are a personal journal, the 45 commands are mostly surface area you will never touch.

What the commands actually do to a note

The README's demo caption describes one /obsidian-save turning a conversation into five cross-linked notes: a person, a project with the decision attached, a task, a board card, and the daily note. The starting set is three commands: /obsidian-init for setup, /obsidian-save to capture, /obsidian-find to recall. The remaining 42 cover synthesis, reconciliation, research, scheduled maintenance and a /create-command interview flow for authoring your own.

The part that distinguishes this from a note-taking plugin is where the writes land. The comparison table in the README sets Karpathy's LLM Wiki pattern against this project: new sources in the original pattern append pages and cross-reference them, while here they rewrite existing pages, so people get updated, claims revised and stale facts replaced. Contradictions are handled by /obsidian-reconcile rather than left for manual resolution, and /obsidian-synthesize writes synthesis pages for patterns you never asked about.

That rewrite behaviour is the whole design. It is also the risk, and the README does not pretend otherwise.

OKM and the AI-first note format

The freshness model is called OKM, Open Knowledge Metabolism, documented in references/freshness-policy.md. The rule stated in the README is that every stored fact is timeless, dated, or a pointer, so the knowledge base does not fill with facts that used to be true. A dated fact presumably carries its date and degrades visibly; a pointer defers to a source that can be re-read.

The note format is explicitly not for human reading. Notes get a `## For future agent` preamble plus frontmatter aimed at LLM retrieval. The README calls this AI-first, and it is a real trade-off: a vault full of preambles and structured frontmatter is less pleasant to browse in Obsidian's reading view than prose notes. If you value the vault as something you read yourself, this convention works against you. v0.15 added an AI-FIRST.md file and a callout preamble, and the release notes mention typed edges, which suggests the linking model is still being formalised rather than settled.

Install paths and the platform surface

The README's install section is referenced by anchor rather than reproduced in the material available here, so the exact install commands cannot be quoted. What is confirmed: the project runs on Claude Code, Grok Bot, Codex CLI, Gemini CLI, OpenCode, Antigravity, Hermes and Pi, and the banner counts 47 commands while the body text says 45. That discrepancy is worth resolving against the live README before you plan around a specific command count.

v0.15, subtitled The Port, is the release that matters for non-Unix users. According to the release notes, the plugin now runs on Windows the way it runs on macOS and Linux, with Windows paths, CRLF and BOM note handling, UTF-8 everywhere and a USERPROFILE-aware config home. The same release added /obsidian-reindex, an Obsidian lint plugin, Simplified Chinese triggers, and a multilingual trigger schema. A vault synced between a Mac and a Windows machine is exactly the case that used to break, and the changelog claims a contributor fixed it end to end across two PRs. Treat that as a claim to verify with your own vault rather than a guarantee.

The scheduled agents are the part to think hardest about

Four agents run on a schedule: a morning brief, a nightly consolidation, a weekly review, and a vault-health check. The README's line is that the vault compounds while you sleep. Nightly consolidation is the one that rewrites notes without you watching.

This is where the project's ambition and its failure modes sit in the same place. An agent that revises claims overnight can silently drop a nuance you wrote deliberately, or reconcile two facts that were both true in different contexts. The freshness policy is the mitigation, and the reconcile command is the other one, but neither is described in enough detail in the available material to say how a contested fact is adjudicated. If your notes contain anything you cannot afford to have paraphrased, the honest answer is that this tool is not built for that vault. Run the scheduled agents against a separate vault, or keep the nightly consolidation off until you have read what it produces for a week.

A second constraint is retrieval quality. The README claims hybrid semantic search, which implies both embedding-based and lexical matching. How the index is built, where it lives, and what happens when the vault is edited outside the plugin are not covered in the material here. The v0.15 notes mention a reproducible retrieval benchmark, which is a reasonable signal that the author cares about measuring this, but no numbers are given.

Where a plain markdown vault or a hosted memory API wins

The obvious alternative is doing nothing special: keep the Obsidian vault, and let each CLI agent read files when you point it at them. That costs you the cross-linking, the reconcile step and the scheduled maintenance, but it also means nothing rewrites your notes behind your back, and there is no install to maintain across eight agents. For a vault under a few hundred notes, this is often the right call.

The other direction is a hosted memory service attached to one provider. Those give you managed storage and retrieval without asking you to keep a vault in a particular shape, but the memory is tied to that provider, so switching agents means starting over. The README's pitch is the inverse: your vault outlives whichever CLI you switch to. That is a genuine architectural difference, not a slogan, and it is the strongest argument for this project. It is also the reason the note format is AI-first rather than pretty, because portability across agents requires a convention all of them can read.

A third option is a general knowledge-graph tool layered over the vault. Those tend to be query tools, not writing tools; they will not create the five cross-linked notes from a conversation, and they will not reconcile contradictions. The difference is that obsidian-second-brain writes, and writing is where the risk lives.

Maintenance, licence and what to check before adopting

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and imposes no copyleft obligation on your own notes or on tooling you build around the skill. This is a description of the licence text, not legal advice; if you are embedding it in a product, have counsel read the file.

The maintenance picture from the release history is active. Three releases are listed between July and September 2026, v0.13.0 The Open Standard, v0.14.0 The Harvest, and v0.15.0 The Port. The v0.15 notes reference a 763-test CI wall, a generated docs site, platform ownership and an Obsidian lint plugin. The last push date is 2026-09-06, two days after the v0.15 release. A contributor fixed Windows support across two PRs, which suggests the project accepts outside patches.

The upgrade cost is the thing to weigh. A skill that rewrites notes on a schedule will interact with every format change the project makes, and the AI-first convention has already moved once in v0.15 with the callout preamble and typed edges. Before adopting, verify three things against your own vault: that /obsidian-init produces a layout you recognise, that a single /obsidian-save round-trips a conversation into notes you would have written yourself, and that the scheduled agents can be disabled per agent rather than as a group. If the third is not configurable, the nightly consolidation is an all-or-nothing decision.

Editorial conclusion

Adopt it if you already keep a working Obsidian vault and want the same facts available to Claude Code, Codex, Gemini CLI, OpenCode, Antigravity, Hermes, Pi and Grok Bot without re-explaining your projects each session. Do not adopt it if you want a database-backed memory with transactional guarantees, or if you are unwilling to let a scheduled agent rewrite notes you wrote by hand. Before trusting it, run /obsidian-init on a copy of the vault, trigger /obsidian-save once, and read the diff it produces against the source conversation.

Official sources

1. eugeniughelbur/obsidian-second-brain on GitHub
2. License: MIT
3. Project website
4. README
5. Releases