Your Obsidian Vault Is Now an Agent Tool in Open Free Max

Open Free Max 3.0 connects the Obsidian vault you currently have open to your coding agents through MCP. The change ships in the 3.0 release, and it applies to both agents that Open Free Max drives: Claude Code and Codex. Once the connection is live, an agent can search your notes, read them, and write to them, using the same vault you already keep in Obsidian.

This is a small feature with a specific promise. It does not reinvent your workflow.

If you already store your specifications, meeting notes, architecture decisions, and personal knowledge in Obsidian, this release lets your agents reach that material directly instead of asking you to copy and paste it into a chat. The vault stays where it is. Open Free Max does not import it, does not duplicate it, and does not fold it into any of its own storage. The connection is a live bridge to the running Obsidian application, nothing more and nothing less.

What changed in the 3.0 release

Before this release, an agent working inside Open Free Max could see the files in your project directory and whatever you typed into the conversation. Your Obsidian vault, if it lived outside the project folder, was invisible to the agent. That is the ordinary situation for most people: the vault is a separate place, curated over months or years, that has little to do with the specific repository you happen to be editing today.

The 3.0 release closes that gap. Open Free Max now connects the vault that is currently open in Obsidian to the agents as a Model Context Protocol source. Model Context Protocol, usually shortened to MCP, is the open standard that lets an agent talk to external tools and data sources through a common interface. Instead of Open Free Max writing a bespoke Obsidian integration from scratch, it connects to an MCP server that Obsidian itself can expose, and the agent treats your vault as one more tool it can call.

The practical result is direct. Ask an agent a question, and it can look through your notes for the answer.

This behaviour is part of the public 3.0 release and does exactly what it says: it connects an Obsidian vault to the agents by MCP. The feature is available now in the public 3.0 release. It is not an experiment behind a flag, it is not a preview limited to one operating system, and it is not something scheduled for a later build. It works on the platforms Open Free Max supports, Windows and macOS, wherever you can run Obsidian and the required plugin side by side with the IDE.

Who benefits from this

The clearest beneficiary is the person who already lives in Obsidian. If your second brain, your project documentation, or your daily notes are in a vault, you have probably felt the friction of re-explaining context to an agent that cannot see any of it. You paste a design note into the chat, the agent uses it, the conversation ends, and the next session starts from nothing again. With the vault connected over MCP, the note is not something you paste; it is something the agent can go and find on its own.

Consider a few concrete situations where this matters.

A developer keeps architecture decision records in a vault folder. While refactoring a module, they ask the agent to check whether a proposed change conflicts with a decision recorded months ago. The agent searches the vault, finds the relevant record, reads it, and factors the constraint into its suggestion instead of blindly rewriting code that was deliberately shaped a certain way.

A technical writer maintains a glossary and a set of style rules in Obsidian. When drafting new documentation inside a project, they ask the agent to align terminology with the glossary. The agent reads the glossary notes and applies the preferred terms, rather than inventing its own vocabulary that a human then has to correct line by line across a long document.

A solo founder tracks product requirements, customer feedback, and half-formed ideas in a sprawling personal vault. They ask the agent to summarise everything they have written about a particular feature. The agent searches across notes, gathers the scattered fragments, and produces a summary the founder can turn into a task, all without the founder having to remember which of two hundred notes mentioned the topic.

In each case the common thread is the same: your knowledge already exists, and the agent can now use it where it lives.

How the connection works

The bridge between Open Free Max and your vault is not something Open Free Max builds by reaching into Obsidian's internals. It goes through a community plugin. The requirement is the Obsidian Local REST API plugin, installed and enabled inside Obsidian. That plugin exposes a local endpoint, and recent versions of it ship a built-in MCP server that speaks the Model Context Protocol. Open Free Max connects to that MCP endpoint, and through it the agents reach your vault.

The chain is short and worth stating plainly, because every link has to be in place for the feature to function.

First, Obsidian runs on your machine with a vault open. Second, the Local REST API plugin is installed and enabled in that Obsidian instance, and its MCP server is running. Third, Open Free Max connects the agents to that MCP server. Fourth, when you ask a question inside Open Free Max, the agent can call the vault as an MCP tool to search, read, or write notes. Remove any one of those links and the agent simply falls back to the context it had before, without your vault.

Because the plugin exposes a local server, the connection stays on your own computer. The Local REST API plugin serves its interface on the loopback address, and it protects access with a bearer token that the plugin generates for you. That token is what authorises a client to talk to the vault, which is why an arbitrary program cannot read your notes just because the plugin is installed. Your vault content moves between Obsidian and the agent on your machine; it is not being shipped off to a third-party service by this integration.

Setting it up, step by step

Getting the connection running is a matter of preparing Obsidian first and then pointing Open Free Max at it. The steps below describe the shape of the setup. The exact wording of menus in the plugin may shift between plugin versions, so treat these as the sequence to follow rather than a pixel-perfect script.

Start in Obsidian. Open the community plugins section of the settings, browse for the Local REST API plugin, and install it. Community plugins have to be enabled explicitly, so turn the plugin on after installing it. Once it is enabled, open its settings. There you will find the API key, the bearer token the plugin uses to authorise connections, and the controls for the server, including its MCP capability and the local port it listens on.

Note the token and confirm the server is running. You will need both facts to connect a client.

The Local REST API plugin uses a self-signed certificate for its secure endpoint. A client connecting over that secure endpoint has to trust the certificate, or it will refuse the connection, which is the correct default behaviour for anything using a certificate it does not recognise. The plugin also offers a plain local endpoint you can enable if trusting the certificate is inconvenient in your environment. Which path you take depends on how you prefer to handle local certificates, and either way the traffic stays on the loopback interface of your own machine.

With the plugin enabled and its server confirmed, move to Open Free Max. Configure the MCP connection so that the agents point at the plugin's MCP endpoint, and supply the bearer token from the plugin settings so the connection is authorised. Keep the same vault open in Obsidian that you want the agents to use, because the connection targets the vault that is currently open. Once Open Free Max is connected to the endpoint, the agent gains the vault as a tool it can call during a conversation.

From that point on, the workflow is ordinary. You talk to your agent the way you always have. The difference is that the agent now has one more place to look, and one more place it can write to, when a task calls for it.

What the agent can actually do

Three verbs describe the capability precisely: search, read, and write.

Search means the agent can look across your notes to find material relevant to what you asked, without you naming the exact file. This is the capability that turns a large, messy vault from a liability into an asset, because you no longer have to remember where you put something for the agent to use it.

Read means the agent can open a note and take its full content into account. When the agent has found the right note, or when you point it at a specific one, it can pull the whole thing into its reasoning rather than working from a fragment. That is what lets it respect a decision record, follow a style guide, or reuse a definition faithfully.

Write means the agent can create or modify notes in the vault. This is the most consequential of the three, and it is the one to approach with the most care. An agent that can write to your vault can add a new note summarising a session, append a finding to an existing note, or update a document you asked it to revise. It can also, if instructed carelessly, change something you did not intend to change.

Because writing is powerful, treat the vault the way you would treat any directory an agent can modify. Keep your vault under version control, or at least keep backups, so that any edit an agent makes is reversible. Review changes before you rely on them. The agent is a capable assistant with access to your notes; it is not a reason to stop paying attention to what happens to them. This caution is not specific to Open Free Max or to Obsidian. It is the ordinary discipline of giving any automated tool write access to files you care about, and it applies here exactly as it applies anywhere else.

The honest limits

There are three limits worth being clear about, because misunderstanding any of them would leave you with the wrong expectation.

The first limit is scope. The connection targets the vault that is currently open in Obsidian. It is not a connection to every vault you have ever created, and it is not a background index of your entire notes collection that persists whether or not Obsidian is running. If Obsidian is closed, or if the plugin is disabled, or if you switch to a different vault, the agent's view of your notes changes accordingly. The feature reflects the live state of Obsidian rather than a separate copy.

The second limit is the requirement. Nothing works without the Local REST API plugin installed and enabled. Open Free Max does not read Obsidian's files on disk directly, and it does not ship its own copy of the plugin. The plugin is the thing that exposes the MCP endpoint, and Open Free Max connects to that endpoint. If you never install the plugin, the feature is simply not present, and the agent behaves as it did before 3.0.

The third limit is the boundary between this integration and Open Free Max's own memory.

Two separate knowledge sources

Open Free Max already has a knowledge base of its own. Each project it works on can accumulate local memory, stored in its own database on your machine, which is how the IDE remembers useful context about a project across sessions. That local memory is a distinct thing from your Obsidian vault, and this release does not merge the two.

The distinction is deliberate and it is worth internalising. Your Obsidian vault stays in Obsidian. Open Free Max does not copy the vault into its local memory, does not import your notes into its own database, and does not blur the line between the two stores. When an agent reads a note, it is reaching into Obsidian through the plugin at that moment; it is not pulling from a cached duplicate that Open Free Max has quietly ingested. When Open Free Max remembers something in its own project memory, that memory lives in its database and does not appear in your vault unless an agent explicitly writes a note there.

Keeping the two separate is a feature, not an oversight. Your vault is yours, curated by you, and it should not silently swell with machine-written material you never asked for. Equally, Open Free Max's per-project memory is scoped to the work it is doing and should not leak your entire personal knowledge base into every project. By treating the vault as a live MCP source rather than an import, the release lets each store keep its own purpose while still letting the agent draw on both when a task genuinely benefits from it.

To put the comparison in one place:

Aspect	Obsidian vault (via MCP)	Open Free Max local memory
Where it lives	In Obsidian, on your machine	In Open Free Max's own database
Who curates it	You, in Obsidian	Open Free Max, per project
How the agent reaches it	Live, through the Local REST API plugin's MCP server	Directly, as project memory
Requirement	Plugin installed and enabled, vault open	Built into Open Free Max
Copied or imported into the other	No	No

The table is not a marketing scorecard. It is a reminder that these are two doors into two different rooms, and the 3.0 release opens the Obsidian door without knocking down the wall between them.

How this fits the rest of Open Free Max

It helps to place this feature in the context of what Open Free Max is. Open Free Max is a lightweight native desktop IDE, built with Tauri, Rust, and TypeScript, that drives the official coding-agent command-line tools interactively. It runs on Windows and macOS. Its purpose is to give those agents a comfortable, native home rather than a terminal window, while staying out of the way of how the agents authenticate and run.

One consequence of that design matters here. Open Free Max never touches your API keys. The official agent command-line tool handles authentication through your own subscription, and the IDE drives that tool interactively rather than calling any billed programmatic interface. The Obsidian integration follows the same spirit. The vault connection is a local bridge through a plugin you control, authorised by a token the plugin generates, running on your own machine. The feature adds a data source for the agents; it does not add a new place where your credentials or your billing are exposed.

That consistency is the point. A tool that respects the boundary around your subscription should also respect the boundary around your notes, and this release was built to keep both boundaries intact.

A short worked example

Picture a normal afternoon of work to see how the pieces fit together in practice.

You open Open Free Max on the repository for a service you maintain. Obsidian is already running in the background with your engineering vault open, and the Local REST API plugin has been enabled for weeks, so its MCP server is quietly running. You have configured Open Free Max to connect the agents to that endpoint, so the moment you start a conversation, the vault is available as a tool. You do not have to think about any of this; the plumbing is already in place from your one-time setup.

You ask the agent to implement a new endpoint. Partway through, you remember that you once wrote a note about the error-handling convention this service uses, but you cannot recall the file name. So you ask the agent to check the vault for anything about error handling in this service. The agent searches your notes, finds the convention, reads it, and shapes the new endpoint's error handling to match. You never opened Obsidian yourself during the exchange.

When the work is done, you ask the agent to write a short note in the vault recording what the new endpoint does and why. The agent creates the note. Later, in Obsidian, you review it, tidy the wording, and link it to the service's index page. The machine did the tedious part; you kept the final say. The two knowledge sources stayed separate the whole time: your vault gained one deliberate note, and Open Free Max's project memory kept its own record of the session, neither one bleeding into the other.

Verifying the connection is live

If you set everything up and you are not sure the agent is actually seeing your vault, a quick test settles it. Ask the agent to search for a phrase that you know appears in exactly one note, something distinctive enough that a guess would not produce it. If the agent comes back with the note that contains the phrase, the connection is working end to end: the plugin is running, the MCP endpoint is reachable, and Open Free Max has wired it to the agent as a tool.

If the agent cannot find it, work back along the chain. Confirm Obsidian is open on the vault you expect. Confirm the Local REST API plugin is enabled and its server is running. Confirm the bearer token you gave Open Free Max matches the one in the plugin settings, since a stale or mistyped token will be rejected. Confirm that the certificate situation is resolved, whether by trusting the plugin's self-signed certificate or by using the plain local endpoint the plugin offers. Each of those is a single, checkable fact, and the failure almost always sits in one of them rather than in something mysterious.

A working connection is quiet. You will not see fireworks; you will just notice that the agent can answer questions about your notes and, when you ask, write to them. That quietness is the intended experience.

Getting started

If you keep your knowledge in Obsidian and you use Open Free Max, this release is worth trying today. Install and enable the Local REST API plugin in Obsidian, confirm its MCP server is running, note the bearer token, and connect Open Free Max to the endpoint. Keep the vault you care about open, and start a conversation. The agent will have your notes within reach.

If you are new to Open Free Max, start with the download and the documentation. You can get the current release from the download page and follow the setup guides in the docs, which cover how the IDE drives the official agents and how to configure connections like this one.

The feature is available now in Open Free Max 3.0. It targets the vault open in Obsidian, it needs the Local REST API plugin, and it stays separate from Open Free Max's own memory. Within those honest limits, it does exactly what it says: it lets your agents search, read, and write the notes you already keep.

Download Open Free Max at /#download, and read the setup guides in the /docs.