Pick a second brain for Claude on the write path, not the read

For one person on one machine, the best second brain for Claude is a folder of markdown files with Claude Code pointed at it, and Obsidian on top of that folder if you want a nice editor. Nearly every guide ranking for this question says some version of that, and they are right. What none of them says is that the answer is chosen entirely on how Claude reads your notes, and reading is the half that every candidate already does well.

The half that separates them is writing. A second brain that an assistant only reads is a search index. The moment Claude is allowed to change a note, the question becomes what it is handed to change it with: a tool that rewrites the whole file, or one that touches the span that changed and refuses if the text moved underneath it. Baalda, the app this site is for, is built around that second shape, and the honest version of this post has to say where Claude Code's own file tools already do it better than most MCP servers, and where Notion beats us outright.

What actually separates one second brain for Claude from another?

Three questions, all of them on the write path:

1. Does a write touch only what changed, or the whole note? A whole-body rewrite is a delete and a reinsert. Anything a person typed in the meantime goes with it.
2. Can a write be refused when the note moved under it? Without a precondition, a stale write still lands, and nothing tells you.
3. Is the second person's write serialised against the first? Two sessions that both read, both think, and both write produce a note with the text in it twice, or a note missing a paragraph nobody deleted.

Sort the usual candidates by those three and the ranking changes a lot.

How does Claude Code write to a file, exactly?

Better than its reputation. Anthropic's tools reference states that the Edit tool "performs exact string replacement. It takes an `old_string` and a `new_string` and replaces the first with the second. It doesn't use regex or fuzzy matching." Two checks follow: old_string "must appear in the file exactly as written. A single character of whitespace or indentation difference is enough to miss", and it "must appear exactly once", otherwise Claude has to pin the occurrence down or set replace_all.

That is a real anchored edit. It answers question 1 well and question 2 partly: the same page notes that a file changed on disk since the last read can still be edited "when `old_string` matches the current content exactly and unambiguously", because the match runs against the file as it is now, not as it was read.

The tool next to it is blunter. Write "creates a new file or overwrites an existing one with the full content provided. It doesn't append or merge." Whole file, gone and replaced.

So a solo Claude Code setup over a markdown folder is a good second brain, and the Claude Code second brain setup is the right starting point for one person. Question 3 is the one it has no answer to, because a file on a disk has no lock. Two processes can both match exactly and unambiguously, one after the other, and the last one wins in silence.

What does the usual Obsidian MCP route hand the model?

This is where the popular setup gets worse rather than better. The standard route is Markus Pfundstein's mcp-obsidian server talking to the Local REST API community plugin inside Obsidian. Its write tools are obsidian_append_content, obsidian_patch_content, obsidian_put_content and obsidian_delete_file.

obsidian_put_content describes itself to the model in capitals:

Creates a new file, or COMPLETELY OVERWRITES the content of an existing
file. The previous content is lost.

To its credit, the same description steers the model away from it, towards append for additions and patch for a targeted change to a heading, block or frontmatter field. But the tool is in the catalogue, and the model picks.

The sharper detail is what gets lost in the wrapping. The Local REST API's own OpenAPI spec does define optimistic concurrency on PATCH: the document map hands back a version token, the client passes it as ifMatch, and a mismatch returns 412 Precondition Failed without modifying the file. That is question 2, answered, in the HTTP API. It is not in the MCP tool. The schema for obsidian_patch_content requires filepath, operation, target_type, target and content, and has no parameter for a version at all. The precondition exists one layer below the only layer the model can see.

Does Notion handle this better?

On this one axis, yes, and it is worth saying so. Notion's hosted MCP server exposes notion-update-page, which updates a page's properties, content, icon or cover, and whose own documentation states that if a search-and-replace operation's old_str does not match the page, it returns a validation error and leaves the page unchanged. That is an anchored edit with a refusal, shipped by the vendor, on by default.

What it costs is the thing this whole site is about. The page is blocks in Notion's database, not a file you have, so question 3 is answered by Notion's servers and question "where is this when the contract ends" is answered by Notion too. We cover that trade in Baalda vs Notion. If your knowledge genuinely is databases, relations and views rather than prose, Notion is the better second brain for Claude and we are not the right tool.

Claude Projects belongs in the same paragraph for a different reason. Project knowledge is an upload: Anthropic's own description is that you "upload relevant documents, text, code, or other files to a project's knowledge base, which Claude will use to better understand the context." Nothing in that documentation describes Claude writing back into it. It is a good reading surface over copies. It is not a place to keep the original.

What breaks when the second person's Claude writes to the same note?

Everything above is still one person. Add a colleague with their own Claude and the three questions collapse into one: who serialises the writes, and against what.

On a folder synced between two laptops, nothing does. Two sessions read the same note, both match their anchor exactly and unambiguously against their own copy, both write, and the sync layer resolves it as a file conflict or as a silent overwrite depending on which sync you use. The failure mode is covered at length in what breaks when the second person arrives.

There is a second thing none of these paths does, which is check what this particular person's assistant is allowed to see. A local MCP server over a vault folder reaches every file in the vault, because a folder on a disk has nothing in the path that can refuse. That is the subject of per-file permissions in Obsidian, and it is the other half of why a shared second brain needs a server in it.

What a write path with all three answers looks like

Baalda's AI access is one endpoint, POST /api/mcp, speaking JSON-RPC over Streamable HTTP, with 22 tools behind a per-person mcp_ bearer token minted in the desktop app's vault settings. The three answers are all in the write tools rather than in the pitch.

Question 2, the precondition. read_note returns the note's revision, which is the sha256 of its current body. Hand it back on the write:

{
  "name": "edit_note",
  "arguments": {
    "docId": "…",
    "expectedRevision": "9f2c…",
    "edits": [
      { "type": "replace", "find": "Ship date: 14 Nov", "replace": "Ship date: 28 Nov" }
    ]
  }
}

If the note is no longer that text, the call fails with stale_revision and nothing is written. The check is not a read followed by a write. The server's own comment on it says it "runs inside the doc's write lock ... so 'checked' and 'applied' cannot straddle a concurrent edit."

Question 1, the span. edit_note takes anchors rather than a body: replace exact text, insert before or after an anchor, delete exact text. An anchor that matches zero times or more than once refuses the whole call as anchor_not_found or anchor_ambiguous, with nothing written. And update_note, the tool that does replace a whole body, is not implemented as a whole-body write. It runs the old text and the new text through a function that computes the smallest single replacement between them, leaving the shared prefix and suffix untouched. The comment above it is the reason this matters: a 20 KB note where one paragraph changed touches one paragraph's worth of the document, so "a concurrent edit elsewhere in the note merges instead of being clobbered by a delete-all."

Question 3, the ordering. Writes are chained per note, and they go down the same path a person's keystrokes take. If anyone has the note open, the server mutates the live document, which persists it and broadcasts it to every connected editor, so an AI edit appears in a teammate's open note as it happens and is written out to the markdown file on disk. The code says plainly that this is deliberate: "this write must persist exactly like a human's." If nobody has it open, the server hydrates the stored state, applies the change and persists the one incremental update.

One more thing falls out of that. The edit is attributed. The MCP token's user rides along as the actor, so an AI write shows up as edited by that person, in the same history as everything they typed themselves. There is no separate robot audit log to go and read.

Where Baalda is the wrong pick here

Four places, and three of them are common.

• One person, one laptop, no server. Obsidian plus Claude Code is the better answer and costs you nothing. The serialisation and the revision check described above live in the sync server, so they apply to a vault that has one, managed or self-hosted. If you are never going to run one, you are carrying weight you will not use.
• You want the plugin ecosystem. Obsidian's is enormous and ours does not exist. Dataview, Templater, the graph plugins, the community themes: none of that has an equivalent here.
• Your knowledge is structured, not written. Relations, rollups, board views, a request tracker. Notion is built for that and we are a markdown store.
• You want Claude to reach it from your phone with no setup. A hosted vendor connector is a few clicks. Ours needs a vault with a server behind it before a remote client has anything to connect to.

So what should you pick?

• Alone, and happy in a terminal: markdown folder, Claude Code, Obsidian for the editor. Use Edit over Write, and do not add an MCP server that only gives the model a blunter tool than the one it already has.
• Alone, and living in databases: Notion with its own MCP connector. The write path is sound. Read Baalda vs Notion for what you are trading for it.
• A team, on notes you want to keep as files: you need a server in the path, because questions 2 and 3 cannot be answered by a folder. That is the case Baalda is built for, and it is free to run locally or self-host under Apache-2.0, with a paid plan only for managed sync.

The question underneath "what is the best second brain for Claude" is not which app has the better AI features. It is which one is still correct after the model has written to it fifty times, while somebody else was typing.