Mods made Claude Code's instruction loader replaceable. Your team's conventions never fitted one repo

Every coding agent reads something before it starts work. The interesting question was never what that file says. It is who else on your team can see it, and which one of your repositories it happens to be sitting in.

What did Anthropic ship on 1 October 2026?

Mods. Anthropic's announcement calls them "small TypeScript functions that change how Claude Code works". A mod runs inside Claude Code rather than beside it, so each time the agent calls a tool, receives a prompt or draws part of the screen, a mod's handler can watch that event, rewrite it, or answer it instead of letting the usual behaviour run. Mods need Claude Code v2.1.287 or later, they are on by default, and they install as plugins with /plugin install <name>@<marketplace>.

The part worth stopping on is not in the headline. Anthropic moved several of Claude Code's own features into mods, and one of them is cc-plugin-agents-md, which the documentation describes as the built-in that "loads AGENTS.md as project instructions". Its source is public, in the mods directory of the anthropics/claude-code repository, next to the /diff pane, the telemetry mod and an organisation security mod. You can turn it off from /plugin.

So the component that decides where your project instructions come from is now a named, readable, replaceable piece of software. That is a modest change to how Claude Code is built and a much larger change to what it is reasonable to ask about it.

Why does a swappable loader become a question about your team?

Because until now it did not look like a decision. Instructions came from a file next to your code, the way they always had, and the only live argument was whether the file was called CLAUDE.md or AGENTS.md. Make the loader a component and the real question surfaces: of everything your team knows about how it works, how much of it is actually about one repository?

For most teams the answer is: not much. Deployment conventions, the review rules, which services are deprecated, who has to be asked before a schema changes, the decision you reversed in March and keep re-litigating. None of that belongs to a checkout. All of it is what you would tell a new engineer in their first week, and all of it is what the agent needs before it writes a line.

This is the gap Baalda is built around. Baalda is a team second brain made of plain markdown files on your own disk, where several people edit the same notes at once and an AI reads and writes those same files over MCP. Its unit is a vault, not a repository, and that difference is the whole point of this post: a vault is a place for the knowledge that spans your repositories, with its own permissions, reachable from whichever directory the agent happens to be running in.

Where can a team's instructions actually live today?

Claude Code's own memory documentation answers this plainly, and it is worth reading its "Shared with" column rather than paraphrasing it. These are the places instructions load from, with the audience the docs give each one.

Exactly one row is both team-shared and writable by the team, and it is scoped to a single repository. The managed row reaches everyone, but it ships through managed settings at a path like /Library/Application Support/ClaudeCode/CLAUDE.md, which is a deployment, not a document your staff engineer edits on a Tuesday.

The last row is the one that gets overlooked. Auto memory is the part that actually learns: Claude writes it itself, in four types the docs name as user, feedback, project and reference, recording your corrections and the decisions it cannot derive from the code. It lives at ~/.claude/projects/<project>/memory/ as a MEMORY.md index plus topic files, and the documentation is direct about its reach. "Auto memory is machine-local. All worktrees and subdirectories within the same git repository share one auto memory directory. Files are not shared across machines or cloud environments."

Read those two facts together. The instructions a team writes can be shared, but only inside one repository. The learnings the agent writes are shared with nobody at all. Five engineers correcting the same agent about the same deprecated service correct it five times, on five laptops, into five files none of them will ever read.

What does a vault give instructions that a repository cannot?

An audience you choose, and an address that does not depend on where you are standing.

Connecting it is one command. Mint a token in the Baalda app under Vault settings → MCP, then register the endpoint:

claude mcp add --transport http baalda https://api.baalda.com/api/mcp \
  --header "Authorization: Bearer mcp_your_token_here"

For a local vault that address is http://localhost:3010/api/mcp, and for a self-hosted server it is your own URL plus /api/mcp. The agent then has list_vaults, list_folders, search_notes, read_note and the write tools, and it reaches the same conventions note from any working directory on the machine, because the note is addressed by vault and folder rather than by its distance from the current checkout.

The permissions are the part a repository genuinely cannot do. A file in git has one audience: everyone with access to that repository, all of it, read and write. In a vault, access is set per folder and per file. manage_access takes a mode of open (can edit), readonly (can view) or private (no access), applied either to everyone or to named people, and list_resource_access shows every member's effective access to one folder before you change anything. So Conventions/deploys.md can be readable by the whole company and writable only by the platform team, which is how the rule is actually governed, and no arrangement of files in a repo expresses that.

Those permissions bind the agent too. An MCP token carries one person and one vault and runs under that person's access, so a folder a developer cannot open is a folder their agent cannot read. That is the difference between pointing an AI at the team's knowledge and pointing it at a service account that can see everything.

And because a vault is a real document surface rather than a config file, correcting the agent is an ordinary edit. read_note returns a revision you pass back as expectedRevision, so a write against a note someone changed in between is refused instead of landing on top of their work. If the concept is new, a second brain over MCP covers the mechanics, what a team second brain is covers the category, and the MCP docs cover the server itself.

Should you write a mod to load your notes?

No, and Anthropic's own documentation says why. Its comparison table puts mods and MCP servers in different jobs: a mod is what you pick when "you want a pane, a band above the prompt, a custom command, or to rewrite an event", and an MCP server is what you pick when "Claude needs to reach an external system". Reaching a vault is the second thing. A mod that fetched notes over the network at session start would be doing an MCP server's work, in an unsupported place, with a worse failure mode.

There is a second reason to leave it alone. Mods are not sandboxed, and the docs are unusually frank about the blast radius: an installed mod can "act on your machine as you", read your environment variables and API keys, see every prompt you send and every tool call Claude makes, and approve a tool call before you are asked. The docs note that a mod which approves tool calls can approve one your own PreToolUse hook blocked. Before installing one from anywhere, run claude plugin validate ./some-mod and read the hooks: and calls: lines, which list what it handles and what it asks Claude Code to do without running it.

Mods are a good thing, and cc-plugin-agents-md existing as one is a good thing. Treat them as the occasion to ask the question, not as the answer to it.

Where a vault is the wrong answer

Three places, and they matter.

A vault does not replace CLAUDE.md, and you should not try to make it. Project instructions load into context at the start of every session with no tool call and no network. An MCP vault is a set of tools the model chooses to call, which means the rules that must be in front of Claude every single time, the build command, the test command, the two conventions it keeps breaking, belong in the file in the repo where they already are. The vault is for the larger body of written context that a repo file has no room for and no right to hold. Claude Code's second brain is a folder, not an integration makes the same split for a vault that is already on your disk, where no MCP server is needed at all.

A vault also needs a server reachable from wherever the agent runs. That is your own machine for a local vault, which is fine for a terminal session and no use at all to a cloud session running while your laptop is shut. Repository files have no such problem: they are already wherever the checkout is. A self-hosted or managed instance closes that gap, but it is a thing you have to run.

And a folder of conventions nobody prunes becomes the same stale wiki your company already abandoned once. The agent will read it faithfully and act on last year's rule. The fact that you can edit a note is the same fact as: somebody has to.