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."
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 connect over stdio through the
mcp-remotebridge with a personal access token: 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/mcpand the third tool from the article is covered too. - 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?
Through the mcp-remote stdio bridge with a token, since these CLI tools can't complete a browser OAuth flow. Calmara issues personal access tokens for exactly this class of client.
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