Short answer
Yes. Devin Desktop, the editor Windsurf became in June 2026, is an MCP client. Its config still sits at `~/.codeium/windsurf/mcp_config.json`, and a remote server takes a `serverUrl` with a `headers` map. Point it at a Baalda vault's `/api/mcp` endpoint and the agent reads and writes your team's markdown.
On 2 June 2026 the editor updated itself overnight and came back wearing a different name. Cognition's FAQ is blunt about it: "On June 2, 2026, Windsurf is becoming Devin Desktop." Settings ported over, extensions survived, keybindings survived. What also survived is the thing this post is about, which is that the agent in that editor still keeps what it learns about your project in a folder only you can read.
What actually changed when Windsurf became Devin Desktop?
Less than the name suggests, and that is deliberate. The transition shipped as an ordinary over-the-air update rather than a migration you had to run. Cognition's FAQ says "All of your Windsurf settings will be ported to Devin Desktop automatically" and, on the editor itself, "The Windsurf IDE, your extensions, your workflows and everything is still there."
The agent is the part with the real change. Cascade is "being brought under the Devin brand and will be called Devin Local", and the FAQ notes that "The existing Cascade agent remains available through July." So depending on when you last opened it, the panel on the right is either Cascade or Devin Local, and a fair amount of writing on the internet still calls it the former.
The practical upshot for anything you are about to configure: the directories did not move. Your MCP config is still under .codeium, which is the name of the company before the one before this one. That is worth knowing before you go hunting for a devin folder that your editor is not reading.
Where does Cascade keep what it learned about your project?
This is the part that matters more than the rebrand.
Cascade has two mechanisms for carrying context between conversations. The docs describe them as "Memories, which can be automatically generated by Cascade, and rules, which are manually defined by the user." Memories are the automatic half: the agent "can automatically generate and store memories if it encounters context that it believes is useful to remember", and you can ask it to remember something directly.
Then the limit, stated plainly in the same docs: "Cascade's autogenerated memories are associated with the workspace that they were created in" and "Memories generated in one workspace will not be available in another."
Workspace-scoped means scoped to a directory on one machine. The memory store sits under ~/.codeium/windsurf/memories/, it is keyed to where the repository happens to live on your disk, and it is not committed to anything. So three people on the same repository have three different memory stores, and if you clone the repo to a second path on your own laptop you have a fourth. A new machine starts empty.
None of that is a bug. It is a reasonable design for a per-developer convenience feature. It is just not a team's memory, and it quietly behaves as though it were, which is the expensive part. The agent sounds like it knows why the retry logic is the way it is, and what it knows is something you told it in March that nobody else can see.
What do rules cover, and where do they stop?
Rules are the half that does travel. They live in global_rules.md for everything, and in a workspace-level .windsurf/rules directory (newer installs use .devin/rules) for rules "tied to globs or natural language descriptions". A rules directory committed to the repository is loaded by every person who opens that workspace, which makes it genuinely shared.
So the usual advice is right as far as it goes: if you want the agent to remember something durably across a team, write it as a rule or into AGENTS.md rather than hoping a memory sticks.
Where it stops is the shape of the thing. A rule is an instruction to the agent. "Use tabs." "Never touch the generated client." "Prefer the repository pattern in this folder." That is a good format for policy and a terrible one for the reasons behind the policy. Nobody wants to read a decision record phrased as an imperative, nobody is going to put the customer call that caused a constraint into a globbed rules file, and a rules directory is scoped to one repository anyway. The decision that spans three services has no repository to live in.
Which leaves the familiar gap. Policy is in rules and travels. Context is in memories and does not. Everything else is in a Slack thread.
Why point the editor at a vault instead of another docs folder?
Because the material that goes missing is not code-adjacent, and because more than one person has to be able to write it.
Baalda is a team second brain made of ordinary markdown files on your own disk. Several people can edit the same note at the same time over a CRDT, so two cursors in one paragraph is a normal situation rather than a conflict dialog. Access is set per folder and per note. The core is open source under Apache-2.0 and can be self-hosted. It serves the vault over MCP at /api/mcp, which means an agent reads and writes exactly 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 contrast with the memory store is the whole point. A memory is one person's, invisible, tied to a path, and unreadable without the editor. A note is a file, readable by anyone you have given access to, editable by a human when the agent gets it wrong, and still there when you buy a new laptop or the product changes its name again. If the category is new to you, what a team second brain is covers the idea before any of the configuration.
How do I add a Baalda vault to Devin Desktop over MCP?
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, which is the entire permission model: the agent gets your access and not a wider one.
2. Open the config file. Click the MCP icon at the top right of the Cascade panel, then Configure. That opens mcp_config.json in the editor. On macOS and Linux it is at ~/.codeium/windsurf/mcp_config.json, on Windows at %USERPROFILE%\.codeium\windsurf\mcp_config.json. The editor does not create the file for you, so if it is not there yet, make it.
3. Add the server. Cascade supports three transports, documented as stdio, Streamable HTTP and SSE. Baalda is a remote HTTP server, so it takes a URL and a headers map rather than a command:
{
"mcpServers": {
"baalda": {
"serverUrl": "https://api.baalda.com/api/mcp",
"headers": {
"Authorization": "Bearer mcp_your_token_here"
}
}
}
}Note the field name. The docs say a remote MCP "requires a serverUrl or url field", and serverUrl is the one every official example uses. It is also the one most other clients do not use, so a config block copied from a Claude Desktop or Cursor write-up will have url in it and may well work, but serverUrl is the safer paste.
4. Press refresh. The MCP panel has to re-read the file before the tools appear.
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.
One thing not to do: 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 that 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 protection that matters once 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 typed. In a vault where other people are editing live, that is not a theoretical case.
edit_note works on anchors, and each anchor has to match exactly once unless you deliberately set all. An anchor that matches zero times, or more than once, refuses the entire call and writes nothing. There is no half-applied edit to find 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 nothing in mcp_config.json widens that.
How do I keep it from writing something it should not?
Three layers, and they stack.
The first is the token, covered above. It is yours, so the blast radius is your own access rather than the whole vault.
The second is the MCP panel. Cascade lets you enable and disable individual tools per server, so you can expose search_notes and read_note while leaving delete_note switched off entirely. Start there and turn on the write tools once you have watched it work for a week.
The third is approval. Tool calls surface in the panel before they run, which is the moment to read what it is about to do.
One caveat I cannot source officially. Several third-party setup guides report that Cascade caps the number of MCP tools it will load at once, somewhere around a hundred, and that tools past the cap fail silently rather than raising an error. I could not find that number in the official documentation, so treat it as community folklore rather than a specification. It is unlikely to bite you here either way: Baalda's vault tools number in the low twenties, so the only realistic way to hit a ceiling is to have a lot of other servers enabled at the same time. If tools go missing after you add a server, that is the first thing I would look at.
What belongs in rules, and what belongs in the vault?
Keep the split clean and both get easier.
Rules are for instructions to the agent that apply inside one repository. Style, structure, the files it must not touch, the pattern it should follow in a given folder. They are short, they are imperative, they version with the code, and they belong in the repo.
The vault is for the written material with no file to sit beside. The decision that spans three services. The customer conversation that is the reason a constraint exists. The runbook touching infrastructure that lives in two other repositories. The postmortem. The thing someone worked out last March that is now load-bearing and recorded nowhere.
That second list is also what the agent is worst at without help, because none of it is inferable from the source. An agent that can call search_notes before it proposes a refactor is working from the context a senior engineer on the team has. An agent that can call create_note afterwards leaves the next person something, which is the same argument the post on pointing Cursor at a vault makes about a repository that explains what but never why.
When is this the wrong setup?
If you work alone, it mostly is. A docs/ folder in the repository plus Cascade's own file tools already cover you, memories being private costs you nothing when there is nobody to share them with, and adding a network hop to reach your own markdown is a moving part earning its keep.
Obsidian deserves a fair mention. Its plugin ecosystem is far larger than ours, community MCP servers for it exist and work well, and for one person it is better software than we are. 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 you are one person with a sync subscription, stay put. The full comparison is honest about where each of us wins.
Baalda is also wrong for you if you want database views and typed properties, or if plain files you can still read without the app are not something you would pay anything to keep.
It is right when several people are writing the context rather than one, when the agent should be held to the same access as the person who opened it, and when you would rather your team's reasoning outlive the next time an editor changes its name. The layer underneath all of this is covered in the MCP documentation if you want it without the configuration.
