Zed's context servers can reach the notes your whole team is editing

Zed is one of the few editors where two people typing in the same file is a normal Tuesday rather than a feature request. It was built on a CRDT from the start, so concurrent edits are commutative and merge without a conflict dialog. That solved the hardest half of working together on code. The other half, the written material that explains why the code is the way it is, sat outside the editor the whole time and still does.

What does Zed already share between people?

Three things, and they are genuinely good.

The buffer. Zed's own write-up on CRDTs describes the choice plainly: rather than transforming concurrent operations the way operational transformation does, Zed structures the data so concurrent operations commute and can be applied on any replica directly. Insertions get stable ids and Lamport timestamps, deletions become tombstones so logical anchors still resolve. The result is the thing you feel rather than read about, which is that a remote collaborator's cursor behaves like a local one.

Channels. Zed's channels post calls them a virtual office for software teams, a place to pair actively or watch passively. A channel is persistent, so it outlives the call.

Channel notes. Each channel carries an associated notes document, described in the same post as a free-form space to share ideas and updates, and as the thing that makes handover between several people on the same work frictionless.

That last one is close to what this post is about, and it is worth being precise about where it stops.

Where do channel notes stop being the answer?

Channel notes are one document per channel, held inside Zed, reachable when you are signed in to Zed collaboration. They are excellent for the running state of a piece of work. They are not a knowledge base, and they were not built to be one.

A channel note is not a file in your project, so nothing that reads files reads it. There is one per channel rather than a tree you can organise and search. And it lives on Zed's side of the line rather than on your disk, which matters less for a scratchpad and quite a lot for the decision record your company will still need in two years.

So you end up with the familiar split. The code is shared in real time, under version control, reviewed. The reasoning behind it is in a channel note, a Slack thread, someone's Obsidian vault, or nowhere. Then the agent panel opens and reads the first column only.

What is a context server, and what does Zed do with one?

A context server is Zed's name for an MCP server. Zed's documentation says it currently supports MCP's Tools and Prompts features, and that it handles the notifications/tools/list_changed notification, so a server that changes its tool list at runtime does not need a restart to be noticed.

You get them in two ways. Some are packaged as Zed extensions and installed from the extensions marketplace, the zed: extensions action, or Settings, AI, MCP Servers. Anything not packaged is added as a custom server from the same place, local or remote. Either way the result lands in your settings under the context_servers key, which is worth knowing because it is the one key name people get wrong: Zed does not use mcpServers the way Claude Desktop does, and it does not use servers the way some VS Code extensions do.

Why does Baalda fit an editor that already works this way?

Baalda is a team second brain made of ordinary markdown files on your own disk. Several people can edit the same note at once over a CRDT, access is set per folder and per note, and the core is open source under Apache-2.0 and can be self-hosted. It serves the vault over MCP at /api/mcp, so an agent reads and writes the same files a person does, under that person's permissions rather than a shared service account. Running it locally is free, with an optional managed Team plan for hosted sync.

The overlap with Zed is not a coincidence of marketing. Both of them concluded that if two people are going to work on the same text, the merge has to be structural rather than a prompt you dismiss. Zed reached that conclusion for source files. Baalda reached it for the notes, which is the same argument the multiplayer markdown post makes against file sync. If the category itself is new to you, what a team second brain is covers the idea before any of the configuration.

How do I add Baalda to Zed as a context server?

1. Mint a token. In Baalda, open Vault settings, then MCP, and create one. It is shown once, starts with mcp_, and carries both the user and the vault it belongs to. Everyone on the team mints their own. That is the whole permission model: the agent gets your access, not a wider one.

2. Open the settings file. cmd-, or ctrl-, opens the settings editor, and cmd-alt-, or ctrl-alt-, opens the JSON directly. On macOS and Linux that file is ~/.config/zed/settings.json, or under $XDG_CONFIG_HOME if you have set one. You can also do this without touching JSON at all through Settings, AI, MCP Servers, Add Server, Add Remote Server.

3. Add the server. A remote context server takes a url and a headers map:

{
  "context_servers": {
    "baalda": {
      "url": "https://api.baalda.com/api/mcp",
      "headers": { "Authorization": "Bearer mcp_your_token_here" }
    }
  }
}

Self-hosting, the host changes and the /api/mcp path does not. Running the desktop server on your own machine it is http://localhost:3010/api/mcp. If you ever see a local context server example with command and args and wonder whether you need it, you do not: that shape is for servers Zed launches as a subprocess, and this one is already running.

Open the agent panel afterwards and the vault's tools appear alongside Zed's own.

Do I have to paste a token, or will Zed do OAuth?

Both routes exist. Zed's documentation says a remote server configured without an Authorization header falls back to its standard OAuth flow. Baalda is built for that case: an unauthenticated request to /api/mcp comes back 401 with a WWW-Authenticate header pointing at /.well-known/oauth-protected-resource, which is the RFC 9728 discovery mechanism an OAuth-capable client follows to find the authorisation server. Consent then records which vault the client was granted, so an OAuth connection resolves to a vault the same way a minted token does.

The honest version: the token header is the route I would set up first, because it is one line and it fails loudly if it is wrong. OAuth is the better experience across a team that keeps rotating credentials, and both sides of it are documented, but if you are the first person in your company to wire these two together, start with the header and move once it works.

One thing not to do either way. The endpoint will also accept the token as a ?key= query parameter. It works, and it is worse, because URLs end up in logs and shell history in a way headers do not.

What can the agent reach once it is connected?

The vault arrives as tools rather than as a folder: list_folders, list_notes, read_note, search_notes, create_note, update_note, append_note, edit_note, move_note, delete_note, plus list_attachments and read_attachment_text for the things that are not markdown. search_notes reaches the text extracted from attached documents and spreadsheets too, and every hit says whether it came from a note or a file.

Two of them carry the safety that matters when the agent is writing rather than reading.

read_note returns a revision. Pass it back as expectedRevision on a write and the write is refused if the note changed in the meantime, rather than landing on top of whatever a teammate just did. In a multiplayer vault that is not a theoretical case, which is precisely why it is there.

edit_note works on anchors, and each anchor has to match exactly once unless you deliberately set all. An anchor matching zero times, or more than once, refuses the entire call and writes nothing. There is no half-applied edit to discover later.

Under both, every call goes through the same per-folder and per-note permissions as the person whose token it is. A folder you cannot open is a folder the agent cannot read, and no flag in settings.json widens that.

How do I keep the agent on a short leash?

Zed gives you two levers above the vault's own permissions.

The first is approval. Zed documents agent.tool_permissions.default with three values: confirm, which is the default and asks before each tool action, allow, which runs without prompting, and deny, which blocks tool actions outright. MCP tools are addressed as mcp:<server>:<tool_name>, so mcp:baalda:read_note and mcp:baalda:delete_note can be treated differently rather than as one undifferentiated permission.

The second is profiles. A Zed agent profile can switch off built-in tools, set enable_all_context_servers to false, and then list the specific context server tools it is allowed, which is how the documented container-use profile works. The same structure gives you a reading profile that can call search_notes and read_note and nothing else, and a separate one for the sessions where you actually want it writing.

The combination worth starting with is a read-only profile plus confirm, then relax it per tool as you find out what the agent is actually good at in your vault.

What belongs in the vault rather than in the repo?

Not everything. The repo is already the right home for anything that has to version with the code, which is most README files, most docs/ folders, and every architecture decision record that only makes sense next to the module it describes. Moving those into a vault buys nothing and costs you the review.

What the vault is for is the material with no natural file to live beside. The decision that spans three services. The customer conversation that is the reason a constraint exists. The runbook that touches infrastructure living in two other repos. The thing someone worked out in a channel last March that is now load-bearing and written down nowhere.

That is also the material the agent panel is worst at without help, because none of it is inferable from the code. An agent that can call search_notes before it proposes a refactor is working from the same context a senior engineer on your team has. An agent that can call create_note afterwards is leaving the next person something, which is the whole argument in the post about pointing Cursor at the same kind of vault, applied to an editor that was already thinking in terms of more than one person.

When is this the wrong setup?

If you are one person, the honest answer is that a docs/ folder in the repo and Zed's own file tools already do this, and adding a network hop to reach your own markdown is a moving part with nothing behind it.

Obsidian deserves a fair mention too. Its plugin ecosystem is far larger than ours, community MCP servers for it exist and work, and for a single person it is excellent software. What it does not do is several people in the same note at the same time, or permissions below the level of the whole vault. If your situation is one person and a sync subscription, stay where you are.

Baalda is also the wrong answer if you want database views and typed properties, or if plain files you can read without the app are not something you would pay anything to keep. It is the right one when several people are writing the context, when the agent should be held to the same access as the person who opened it, and when you want the notes to behave the way Zed already made the code behave. The protocol underneath all of this is covered in the MCP documentation if you want the layer below the config.