I Gave Claude Access to My Entire Second Brain

Somewhere north of Lyon, our TGV train stopped moving. It was day four of a fifteen-day trip through France and Italy with my mom, the delay kept growing with no explanation, and my laptop was packed inside a suitcase in the luggage rack. I pulled up Claude on my phone and typed: "Our train is delayed."

It read the day's itinerary from my Obsidian vault, figured out which train we were on, and reminded me that our taxi in Avignon was booked for 17:30, gave me the booking reference and the dispatcher's number so I could push the pickup, and when I wrote back that we'd stopped again and it was looking like another hour, it did the arithmetic, warned me we were about to miss our hotel's 20:00 check-in cutoff, and handed me the front desk's phone number and email so I could give them a heads-up. My vault was sitting on a server in us-east-1, roughly 6,000 kilometres away, and Claude was reading it for me from a train seat in southern France.

That moment is what this post is about. Vault Cortex is a self-hosted MCP server that gives AI persistent access to your Obsidian vault from anywhere, on any device, without Obsidian running. I've spent over a year trying to give my AI tools a memory that actually works, and this trip was the first time I really had to depend on the result. This post covers what I built, why the current state of AI memory pushed me to build it, and how it held up over 15 days of real use.

The Problem

The problem in 2026 isn't that AI tools lack memory. Almost every assistant ships some form of it now, and there's a whole funded industry racing to add more. The catch is where all that memory lives. Claude's memory covers the Claude apps but not Claude Code, which keeps its own auto-memory scoped to each project folder on each machine, and the API offers a third mechanism that developers wire up themselves. ChatGPT's memory is a ChatGPT feature. Gemini's personalization doesn't even reach every part of Gemini. Each project I set up gets its own hand-curated context on top of all that. And the dedicated memory startups (mem0 raised $24 million and became the memory provider for AWS's agent SDK, with at least a half-dozen serious frameworks behind it) are building for app developers, storing your memories in vector and graph databases behind an API. Everyone is trying to solve this problem, which tells you how real it is. But every one of these systems stores context in a different place, in a format I don't control, and the most portability any of them offers is a copy-paste export of a synthesized summary.

So the day-to-day experience is still amnesia. Ask a new chat about a decision you made yesterday in a different tool and you're starting from zero, pasting in context, or maintaining some giant prompt document that drifts out of date. I've come to think the memory shouldn't live inside any one assistant or any one vendor's database. It should live in plain files you own, in one place, with every assistant reading and writing the same store. (Even Anthropic seems to be arriving at the same place: the memory for their newest managed agents is stored as plain, exportable files.)

For me that place was already Obsidian. I had the Obsidian app on my phone for the whole trip, so my notes were technically never out of reach, but reading your notes and having an AI that understands your notes are different things. I didn't want to dig through twenty documents to reconstruct a travel day. I wanted to ask "what's the plan for tomorrow?" and get an answer pulled together from the itinerary, the restaurant guide, the booking confirmations, and the activity notes. There are dozens of MCP servers that connect Claude to an Obsidian vault. Some need Obsidian running with a REST API plugin, some read the markdown files directly, a couple offer remote access through network tunnels. Almost all of them still need your machine powered on and reachable. Close the laptop and the connection dies, and switching to your phone means starting over.

The wider industry has been circling the same conclusion. "Context engineering" overtook "prompt engineering" in mid-2025, and the emerging architecture keeps landing on markdown files plus structured retrieval. Almost every implementation still assumes you're sitting at your desk. I wanted my knowledge base reachable from any device, anywhere, with nothing running at home, so I built that.

What I Built

Vault Cortex is a standalone, self-hosted MCP server for your Obsidian vault. It gives Claude, or any MCP client, structured access to your notes, indexed into SQLite, exposed through 26 tools and 3 guided prompts, and secured with OAuth 2.1. Run locally, it takes about two minutes and involves no cloud at all, just Docker and a folder of markdown files. That alone replaces the usual three-part local chain of Obsidian open, a REST API plugin installed, and a separate MCP server wrapping it. But the real power comes from the remote setup, where the server sits on a small VPS next to a headless Obsidian Sync client, so the same vault that syncs to my laptop and phone is also readable and writable by Claude from anywhere, including claude.ai on mobile, which can never reach a localhost server.

• Plugin-free. It reads and writes the .md files directly. Nothing gets installed in Obsidian, Obsidian never needs to be open, and technically any folder of markdown files works.
• 26 tools, 3 prompts. Search, read, write, surgical patching, memory files, task queries, properties, tags, links, daily notes, plus guided workflows for vault health, memory review, and daily reconciliation.
• Hybrid search. Keyword search (SQLite FTS5 with BM25 ranking) fused with semantic vector search and reranked by a cross-encoder, so a natural-language question finds the right note even when the exact words don't match. The embedding models run locally inside the container, so no note content ever leaves your server, and search falls back to keyword-only while the vectors build.
• OAuth 2.1. PKCE, dynamic client registration, refresh token rotation, JWT verification. For a server with write access to your personal notes this is not optional, and the ecosystem is worse at it than you'd hope: one 2026 analysis found only 8.5% of MCP servers implement OAuth and 41% have no authentication at all. The reasoning behind the implementation gets its own post.
• Streamable-http transport. It works as a Claude.ai remote connector or on localhost, with no stdio required.
• Always current. In the remote setup, a headless Obsidian Sync client (built on @Belphemur's obsidian-headless-sync-docker) runs beside the server, so edits from any Obsidian app reach the server in seconds and Claude's writes flow back to every device.

The remote setup: cyan is the MCP request path, purple is the Obsidian Sync path.

Here's a real interaction from the trip. I needed a Paris restaurant booking I'd consolidated in my vault, and this is the actual response from the search layer, trimmed for length:

vault_search({ query: "Semilla restaurant" })

→ {
    "results": [{
      "path": "Trip Planning/guides/paris-restaurants.md",
      "title": "Paris — Restaurant Guide",
      "snippet": "...Primary: Semilla / Address: 54 Rue de Seine, 75006 /
                  Walk: ~7 min from hotel. Flat. / What to expect:
                  Wine-forward bistronomic restaurant, creative..."
    }],
    "total": 3
  }

One tool call returned the restaurant guide with everything I needed. The trip's Claude project did have my planning docs uploaded as project knowledge, but those copies dated from March and this booking was made weeks later, so project search came up empty. The booking confirmation was in my email too, but the vault had the full restaurant guide, everything I'd pulled together while planning, in one search result.

15 Days, 216 Tool Calls

I travelled with my mom for 15 days in May and June 2026, through Paris, Avignon, Verona, and Venice. The vault held everything for the trip: city-by-city itineraries, restaurant guides with booking confirmations, a multi-leg travel day guide, a luggage strategy document, and a running task board. Over those 15 days I had just over 30 Claude chats, and when I audited them after the trip, five out of every six had leaned on the vault. I also went back through the server logs while writing this post, so these are actual counts rather than my memory of the trip: 216 tool calls, 89 note reads, 79 surgical edits, 16 searches, every one of them from my phone. My laptop stayed in the suitcase.

Most sessions were read-only, pulling up booking references, phone numbers, opening hours, day plans. The writes were small and deliberate. When I moved a lunch reservation in Verona from 13:00 to 14:00, Claude cascaded the change through four places across two guides so nothing went stale. When I noticed the luggage guide described our setup wrong, it made four corrections from my phone on the last travel day. A few moments from the trip stuck with me:

The 84-call night in Avignon. The evening before a four-train, 12.5-hour travel day, I sat in our hotel room sorting out logistics with Claude, and the logs show what that evening turned into: 84 tool calls and 55 vault edits. The travel day guide got its ticket formats corrected (our confirmation emails insisted two trains needed printed A4 tickets, but Claude checked SNCF's own FAQ and confirmed phone barcodes were fine for all four), the departure taxi reference was added, the packing checklist was updated, and the payment tables were reconciled. Not everything went our way that night. I also tried to cancel two redundant train segments and learned I'd missed the refund cutoff by a day, which cost us about CA$190, and the refund estimate in my own planning notes turned out to be optimistic. No memory system saves you from fine print. What it did do was keep every document accurate for the next morning, when a completely different chat session read the same travel guide to answer luggage questions on the way to the station. The edits from the night before were just there, in a new chat, with no effort from me. That's what I actually built this for.

Reading the wrong board in Torino. During our transfer at Torino Porta Nuova, I photographed a departure board and asked Claude how to interpret it. It explained the Italian board conventions, then pointed out that I'd photographed the arrivals board and needed the departures board instead, and pulled our exact train from the vault so I knew what to look for: Frecciarossa 9753 to Verona Porta Nuova at 17:05, carriage 1, seats 6A and 6B. All of that came from a travel guide written in Obsidian weeks earlier, which beat scrolling through email confirmations in a crowded station with our luggage in tow.

A church itinerary card, fixed on the go. In Verona, Claude built me a phone-sized HTML itinerary card for a day of church visits, working from the vault's activity guide. I noticed the walking route doubled back on itself, so I asked, and it checked the geography, reordered the stops into one clean north-to-south loop, and adjusted the schedule so we'd be inside a church during a forecast storm window. Then I had it tighten the layout until the whole card fit in two iPhone screenshots, because that's how I used it for the rest of the day, straight from my camera roll.

The information was never perfect, and I want to be honest about that. I caught a wrong day-of-week label, an incorrect luggage count, and a wrong assumption about when our museum cards activated, and some of those errors were Claude's own. What changed is that corrections became cheap and durable enough that I actually made them, from wherever we happened to be standing. That saved me a lot of sifting through my own detailed planning docs to figure out what was still true.

One thing I didn't expect: the same system ran my project work too. One evening in Avignon I closed out a work session on the Vault Cortex project itself from my phone, writing the session log, moving task cards, appending to my memory files, and later in the trip I prepped the project's registry submissions from a hotel room in Venice. And a handful of chats never touched the vault at all, because not everything needs it.

Vault Cortex in action: a 60-second demo from Claude mobile

Asking Claude to save trip lessons from my phone, and the note it wrote, synced back to Obsidian.

Vault Cortex is open source: github.com/aliasunder/vault-cortex

How I Got Here

Vault Cortex is the fifth iteration on a problem I've been working at for over a year: how do you give an AI assistant a memory it can keep?

OpenMemory/mem0. I started with their open-source memory layer. It advertised support for non-OpenAI providers, and in practice that support was broken, so I forked it, fixed the environment variable bugs, patched its categorization to work with providers beyond OpenAI, and fought Qdrant crash-loops on macOS. After months of patching someone else's codebase, the recalls were still shallow and the categorization still unreliable, and saving was so slow that calls regularly looked like they'd failed when they hadn't. I ended up keeping a standing instruction for my agents: a failure doesn't mean the memory wasn't saved.

NeuralComposer and LightRAG. It started as an Obsidian plugin, so Obsidian had to be running for any of it to work. The graph RAG retrieval was genuinely good when it worked, but in daily use it was slow and finicky, calls failed often, and the operational weight was unsustainable: 385 MB of working data, three forked repos, and a launchd daemon I built to decouple it from Obsidian just to keep it all running."

The obsidian-vault plugin. If Claude was going to write into my vault, it needed to understand frontmatter, wikilinks, callouts, Kanban boards, and a dozen community plugins, so I codified those conventions into an AI-readable skill. It became a standalone open-source plugin that I still use in every session.

CLAUDE.md protocols. I built a three-layer memory architecture (semantic for who I am, episodic for what happened, working for what's current) with session start and end protocols, so every conversation picks up where the last one left off. This is the layer that makes Claude feel like it actually knows me.

Vault Cortex. The piece that made all of it reachable from anywhere, on any device, in any client.

I tried the off-the-shelf solution, forked it when it broke, and after months of patching the output still wasn't good enough, so I built my own. Each of these stages gets its own deep dive later in the series.

Try It

Vault Cortex is open source, self-hostable, and works today.

• Repo: github.com/aliasunder/vault-cortex
• Quick start: npx vault-cortex@latest init
• What you need: an Obsidian vault (or any folder of markdown files) and Docker. For remote access, add a small VPS and an Obsidian Sync subscription.
• Costs: my remote setup runs about $30 a month, made up of a $24 Lightsail instance (2 vCPU / 4 GB, which gives comfortable headroom for the local embedding models and concurrent search), under a dollar of API Gateway, and $5 for Obsidian Sync. A smaller instance (1 vCPU / 2 GB, $12/mo) handles semantic search fine for a typical vault, bringing the total closer to $18. If you skip semantic search entirely you can go smaller still, and a local-only setup is free.

The architecture decisions in Vault Cortex are mine, and the implementation happened in conversation with Claude across hundreds of sessions over several months. I think that's worth being transparent about. Working with AI well is an engineering skill in its own right, and this whole project exists to make that collaboration work better.

If this sounds like a problem you have, the repo is at github.com/aliasunder/vault-cortex and stars genuinely help a new project get found. The next post in the series covers the OAuth 2.1 implementation, and later ones dig into the search layer and the memory architecture that makes Claude feel like it actually knows me.