A shared memory for every AI assistant: what the Obsidian-vault approach gets right, and where it stops
XDA ran a piece yesterday that I want to point at before I say anything else, because the author solved a real problem well: Nolen Jonker wired an Obsidian vault as the shared memory for Claude Code, Codex, and a local Qwen model. Five markdown files in a _meta folder describe his machine, his vault layout, his current work, his connected tools, and how he wants agents to respond. Pointer files at the vault root send each tool there on startup. His framing question is the right one: "Why not have one place they all check first, so the vault is the thing that onboards them?"
The payoff line is the one anyone who juggles multiple assistants will feel: "Every fresh session everywhere used to mean re-explaining who I am and what I'm doing, and now that's one file that tells the tool everything."
That pain is exactly the problem I build for, so this article is two things at once: an honest appreciation of the vault pattern, and a map of the two walls you hit with it, plus how the same idea works when the memory lives behind MCP instead of on one disk. Disclosure up front, as always: Calmara is my product, and the last sections are why I built it the way I did.
Quick answer: A local vault works well as shared memory for tools that can read your filesystem: Claude Code, Codex, a local model. It cannot follow you to claude.ai, ChatGPT, or your phone, and it keeps no record of which tool wrote what, or what a fact said before an agent rewrote it. The same pattern over a remote MCP server reaches both kinds of surface, with provenance.
What does the shared-vault setup actually do?
The mechanics, from the article: Claude Code reads the vault natively through its file access and a CLAUDE.md pointer. Codex picks up an AGENTS.md on startup. The local model (Qwen 3.5 9b in LM Studio) reaches the vault through a filesystem MCP server, with instructions pasted manually since LM Studio doesn't auto-load them. Decisions made in one tool get written to a current-focus.md that the next tool reads cold, so a Codex session can pick up design decisions a Claude Code session made without re-explanation. WikiLinks let both humans and agents follow cross-references.
Credit where due, in three specific ways. First, plain markdown as the interchange format is the right call: every tool can read it, you can grep it, and nothing about it locks you in. Second, "the vault onboards the tools" inverts the usual setup burden correctly; context should live in one place the tools visit, not in per-tool config scattered across dotfiles. Third, keeping it local means zero new services, zero subscriptions, and total control. If your assistants are all filesystem-capable and you are the only writer who matters, this is a good system, and you should read the original piece before this one.
What can't a local vault reach?
The first wall is structural: the vault is files on one machine, and most AI surfaces cannot read files on your machine.
Claude on the web, ChatGPT, Perplexity, and every mobile assistant app run on someone else's servers. They can connect to remote services (that is what custom connectors and remote MCP servers are), but they cannot open your laptop's filesystem, and no pointer file changes that. So the setup covers the coding-agent side of your life and stops exactly at the chat side: the place where you ask the follow-up question from your phone, or continue the thought in a browser at someone else's desk. Obsidian's own mobile app can sync the vault's text to your pocket, but the assistants you use there still can't read it.
You can bridge this with more plumbing, such as exposing a server from your machine to the public internet, but at that point you are operating infrastructure, and the simplicity that made the vault attractive is gone.
What's missing even where it works?
The second wall is quieter. "One file that tells the tool everything" cuts both ways: it is also one file that any tool can rewrite, with no record.
The article's workflow has multiple agents writing to shared files by design; that is the feature. But markdown files carry no answer to the questions that start mattering the week something goes wrong: Which agent wrote this line, and in which session? What did this file say before last Tuesday? Two tools edited current-focus.md in overlapping sessions; whose edit survived? Was this "decision" something I approved, or something an agent inferred and wrote down as fact?
Git can give you some of this if you commit the vault religiously, and to be fair, nothing stops a disciplined person from doing that. But the assistants aren't committing on your behalf, a diff doesn't tell you which of three agents made the change, and none of it gates what gets written in the first place. There's no review step between "an agent decided something about you" and "every other agent now treats it as true."
Since publishing this I have watched security researchers arrive at the same property from the other direction, which is worth knowing before you scale the pattern up. An Anthropic and EPFL preprint in August 2026 built self-propagating payloads for multi-agent setups, and the medium they travel through is the persistent file: the payloads "spread by writing themselves into agents' memory and configuration files and instructing each new host to copy them onward." One evolved payload states the appeal plainly, in the agent's own voice: "Status: Context wiped. Only SOUL.md and disk files persist." That is the same sentence a person would write to justify the vault pattern. The file is valuable because it survives the reset, and that is exactly why something malicious would want to live in it.
Keep the scale straight, because the coverage did not. The researchers tested an OpenClaw-shaped harness and a simulated coding team, not an Obsidian vault, and not the CLAUDE.md and AGENTS.md files this setup relies on. Their own verdict is that mind viruses "currently appear to be of minimal concern," harmful payloads spread worse than benign ones, and a one-paragraph warning in the system prompt was close to a complete defense. Claude Sonnet 4.6 did not just refuse; it scrubbed the payload out of its own identity file and warned the next agent. This is not a reason to stop. It is a reason to put the files your tools read on startup under version control, so that when one of them changes you find out from a diff rather than from behavior.
These are the properties I keep coming back to in what an auditable AI memory needs: provenance, history, and a review gate. A shared vault has none of them, not because the author did it wrong, but because plain files don't have anywhere to put them. The tell is what's happening around this pattern: there's already a small ecosystem of projects bolting SQLite indexes, git baselines, and cleanup passes onto vault memory (one representative repo describes itself as "Markdown-first shared memory... with SQLite, Zvec, Git, closeout, and audit"). When the pattern starts to matter, people add the database back.
How does the same pattern work over MCP?
Everything the vault does (one canonical store, every tool reads it first, decisions persist across sessions) also works with the store behind a remote MCP server, and the reach changes completely. Using Calmara as the worked example, because it's mine and I can vouch for the details:
- Claude Code and LM Studio point straight at
https://api.calmara.app/mcp: Claude Code withclaude mcp add --transport http calmara https://api.calmara.app/mcp --header "Authorization: Bearer cmra_pat_…"(or its own OAuth flow via/mcpandclaude mcp login), LM Studio with aurlplusheadersentry in itsmcp.json, using a personal access token as the bearer. Themcp-remotestdio bridge remains the fallback for clients that only speak stdio. The same two tools from the article, reading the same memory. - Codex now takes remote Streamable HTTP servers directly: per OpenAI's MCP docs, a
config.tomlentry needs just aurland abearer_token_env_varfor the token. Point it athttps://api.calmara.app/mcpwith a personal access token as the bearer and the third tool from the article should be covered too; I have confirmed the handshake against the endpoint but not yet run a full Codex session against a real token. - claude.ai, ChatGPT, and the chat surfaces the vault can't reach connect as custom connectors with OAuth. The full current matrix, including the honest not-supported rows, is on the MCP compatibility page.
And because the store is structured rather than a pile of prose, the missing properties have somewhere to live: every fact carries which conversation or tool call produced it, a revision history instead of overwrites, a pending-review queue so agents propose rather than assert, and two kinds of delete: retract with a record, or erase entirely.
Which should you actually use?
Not a rhetorical question; the answers differ.
Use the vault approach if your assistant use is concentrated in filesystem-capable tools, your shared context is mostly project state ("what am I building, what did we decide"), and you're comfortable with git as your only history. It is free, local, and has no moving parts. Its failure modes are annoyances, not disasters, as long as the content is project notes.
Reach for a structured, remote memory when the context is facts about you rather than the current sprint, when you want the same memory in your pocket and your terminal, or when "prove where this came from" is a question you'll ever need to answer. The honest costs: Calmara is a hosted SaaS (there's a trust page that says plainly where data lives), and structure is heavier than prose, because a triple with provenance is more ceremony than a markdown bullet.
The two also compose. Machine-local context like the author's hardware specs and vault layout has no business in a cloud memory and is perfect in a _meta folder; durable facts about you and your decisions are what the structured store is for. The pattern that matters, one place every tool checks first, is the same in both.
FAQ
Can multiple AI assistants share one memory?
Yes, two ways. Filesystem-capable tools (Claude Code, Codex, local models with a filesystem MCP) can share a local folder of markdown files, as the XDA article demonstrates. Any MCP-capable assistant, including web chat surfaces, can share a remote memory server. The local approach is simpler; the remote approach reaches more surfaces and can carry provenance.
Can ChatGPT or claude.ai read my Obsidian vault?
Not directly. Web-based assistants cannot access your local filesystem. They can connect to remote services via custom connectors and remote MCP servers, so a vault only becomes reachable if you run and expose a server for it yourself, at which point you're maintaining infrastructure.
Does Codex support remote MCP servers?
Yes. Per OpenAI's documentation, Codex supports both stdio servers and remote Streamable HTTP servers; a remote entry in config.toml takes a url and an environment-variable name for a bearer token sent in the Authorization header.
How does Claude Code connect to a remote memory server?
Directly over Streamable HTTP with a bearer header; Claude Code can also complete OAuth from the terminal. A personal access token is for clients that have no browser OAuth flow at all (LM Studio, most stdio-only tools), and Calmara issues them for exactly that class of client; the mcp-remote stdio bridge is the fallback when a client cannot speak HTTP itself.
What's the problem with markdown files as AI memory?
Nothing, until you need answers files can't give: which agent wrote a line, what it said before it was rewritten, and whether you ever approved it. Multiple agents writing shared prose means silent overwrites with no provenance, no history, and no review gate.
Doesn't git solve the history problem for a vault?
Partially, if you commit consistently. But commits are yours, not the agents'; a diff doesn't attribute a change to a specific tool or session; and version control records changes after the fact rather than gating what agents may assert in the first place.
Is a local vault more private than a hosted memory?
For pure locality, yes: nothing leaves your machine, which is also why it can't follow you off that machine. Hosted memory trades locality for reach; what matters then is whether the host documents where data lives and what it can prove. That tradeoff deserves an explicit decision, not a default.
---
If you already run a vault setup like the article's, keep it, and try the composition: leave machine-local context in _meta, move the durable facts about you into a store your chat assistants can also reach, and see which questions each one ends up answering. The MCP setup guide is the ten-minute version of getting the second half running.
Written by Dan Hagen