Methodology
·
5 MIN
Personal knowledge management with AI: Claude Code and Obsidian
Your Obsidian vault stays local. The AI's inference does not. That split is the whole PKM decision.
LOCATION
Worldwide
SERIES
AI Tooling & Dev Harnesses
AUTHOR
Aashwin Shrivastava
PUBLISHED
The interesting question about Claude Code and Obsidian is not whether an agent can tidy your notes. It is where your notes actually go when it reads them. An Obsidian vault is plain Markdown sitting on your disk. Claude Code is a model you rent from a cloud. Once you treat that split as the design rather than an accident, a folder of Markdown turns into a second brain you query in plain language, and you keep ownership of the layer that matters.
This piece is the practitioner version of that setup, and the honest version of its limits.
01.
The vault is the asset, the agent is rented
Keep the durable thing and the swappable thing separate, and most of the design follows.
The durable thing is your vault: plain .md files, [[wikilinks]], YAML frontmatter. No database, no proprietary format, no export step. The swappable thing is the agent reading it. The two community projects leading this space, obsidian-second-brain and obsidian-mind, both ship for Claude Code, Codex CLI, and Gemini CLI on purpose. The vault is the investment; the model is a tenant you can evict.
That is the same reasoning we apply to wiring AI into any stack: own the interface, rent the capability. We wrote it up for system integration in API, MCP or CLI. Personal knowledge management is the same argument at desk scale.
02.
What changes when an agent can read your notes
An agent with file access turns a static vault into one that maintains itself, within limits you set.
CLAUDE.md is the operating manual. Run
claudefrom the vault root and it loads this file every session: your folder map, your linking conventions, your note templates, your default behaviours. It is the single load-bearing file in every working setup./initwrites a first draft.Session context is a hook, not magic. obsidian-mind injects a north-star excerpt, a task list, and a file listing at session start so the agent does not begin blank. That is a
SessionStarthook running on your machine, nothing more.Filing becomes a skill. Slash commands and subagents handle the chores: filing a clipped note into the right folder, generating a map-of-content, finding orphaned notes, writing the daily log. obsidian-second-brain ships dozens of these.
Frontmatter is the machine-readable layer. Date, status, source, a confidence marker in YAML, plus wikilinks, give the agent structure to retrieve and cross-reference against, instead of guessing from prose.
The newest shift is notes that rewrite rather than append: a new source updates and reconciles existing notes instead of stacking another dated entry. Useful, and the first place to be careful, which is the next section but one.
03.
Retrieval, not dumping: the token reality
Do not load the whole vault. Let the agent fetch the few notes a question needs.
The naive setup pushes the vault into context and breaks around a few hundred notes. The frugal setup keeps everything on disk and pulls only what matches, through command-line search or grep. Practitioners report the gap as roughly 100 tokens for a CLI vault search against tens of thousands for loading a project wholesale. The mechanics are unglamorous: search, read the three notes that matched, answer.
This still matters even though Claude Code now runs a million-token context window. The rolling rate limit bites long before the window fills, so a vault that answers in 100 tokens lets you ask a hundred questions where the dump-everything setup gives you a handful. Frugal retrieval is what makes a second brain usable daily rather than impressively once.
04.
The privacy line is inference, not storage
The community sells "everything stays in your vault, no SaaS." That is true for storage and false for inference, and the difference is the whole risk.
Your Markdown stays on your disk. But by default every query sends the relevant notes to a cloud API to be read. For a hobby vault of recipes, fine. For a vault holding client notes, contracts, or anything covered by an AVV, that is data leaving the building on each question. Plain-Markdown portability is not the same as local privacy.
Two more honest caveats. Prompt injection is structural: an agent reading your notes cannot cleanly separate "instructions" from "content," so any Markdown that enters the vault, a clipped web page, a shared note, an ingested PDF, can carry instructions it then acts on. And the risk is not hypothetical: in April 2026, attackers abused Obsidian community plugins to run code when a victim opened a shared vault, reported by The Hacker News. An agent with file-write and shell access raises that stake, not lowers it. Self-rewriting notes can also quietly invent a backlink or overwrite a correct line, and the change is saved before you read it.
05.
The same pattern, kept sovereign
Everything good about this setup survives when you move the model in-house. The privacy problem is the only part that needs the change.
The sovereign version keeps the vault and the workflow and swaps cloud inference for a local model: a retrieval layer over your Markdown served by a model running on your own hardware or in EU hosting. You keep the plain-text ownership, the CLAUDE.md operating manual, the skills, and you stop sending the contents out on every question. For a Mittelstand firm, this is the bridge from a personal experiment to real internal knowledge management, product manuals, process docs, support history, without an AVV question hanging over each query. When to make that move, and what it costs, is the subject of On-Premise vs. Cloud LLM.
The hobbyist framing is "build a second brain." The business framing is the same machine pointed at the company's knowledge instead of yours. The interesting question, again, is not whether it works. It is who gets to read the notes. So: where does your vault actually send its questions right now?
