Shared Team Memory for Claude Code: What Works Today

Claude Code does not ship shared team memory: its memory features are per-person, so what one engineer's session learns never reaches a teammate's. The practical fix is a shared knowledge base with a built-in MCP server, like Hjarni. Each engineer runs one claude mcp add command, and every session on the team reads and writes the same notes.

The feature Claude Code users keep asking for

Look at the Claude Code issue tracker and a pattern jumps out. Shared team memory is an open feature request. So are team-shared configuration and memory that spans projects. The stories in those threads are the same story.

An engineer picks up a task mid-sprint. The teammate who started it already walked their Claude through what was tried, what failed, and what the blocker was. None of that transfers. The second engineer's session starts from zero, and a human spends an hour reconstructing context an AI already had.

Or: one engineer is the expert on the billing subsystem. Their Claude knows it cold. Everyone else's Claude does not, so every question still routes through the expert.

Knowledge moves between people all day. At the agent level, nothing moves at all.

What Claude Code gives you today, and where it stops

CLAUDE.md is genuinely shared, because it lives in the repo. It is the right place for short, stable rules: build commands, code style, test conventions. But it is configuration, not memory. It only changes when someone commits, it is scoped to one repo, and it does not accumulate. Yesterday's debugging session does not write itself into CLAUDE.md.

Claude Code's memory accumulates, but it is personal. What your sessions learn stays yours. There is no team scope.

Claude Projects do not close the gap either: a Project is built around one assistant and a focused task, not a shared writable base for a team.

So teams end up with the worst split: shared knowledge that is static, and accumulating knowledge that is siloed.

The fix: memory that lives outside the assistant

The reason this problem is hard inside Claude Code is that memory is attached to the tool. Attach it to the team instead.

A shared knowledge base with a built-in MCP server inverts the ownership. The notes belong to the team. Claude Code is one of the clients that reads and writes them. So is a teammate's Claude Code. So is Claude.ai, ChatGPT, or Cursor, if that is what someone prefers. Nobody's memory depends on which tool they opened.

In Hjarni that looks like this: a team with shared folders of Markdown notes. Decisions, runbooks, incident notes, conventions. Notes, folders, tags. Every engineer connects once, and every session after that starts with the team's context available on demand. (Comparing dedicated team memory servers? See Hjarni vs Context Cloud.)

Set it up in about ten minutes

1. Create a team in Hjarni and invite your engineers. The first 25 team notes are free.
2. Add a few folders: Decisions, Runbooks, Conventions is a solid start.
3. Each engineer connects. In any project directory, run claude mcp add --transport http hjarni https://hjarni.com/mcp (add --scope user to make it available in every project). Claude Code opens a browser for OAuth. Sign in once, done.
4. Seed it. Ask Claude Code to write up the last architecture decision you made and save it to the Decisions folder. That one note is the demo: tomorrow, a teammate asks their own session "why did we switch queue libraries?" and gets your answer, cited from the note.

Two upgrades once the loop works:

• Folder instructions. Put rules on the folder itself, like "when asked about deploys, search this folder first and follow the steps verbatim." Every teammate's assistant follows them automatically.
• Auto-capture. A Claude Code Stop hook can write a session summary to Hjarni when you finish. Handoffs stop being a thing someone has to remember to write.

Memory a team can actually trust

Shared write access raises a fair question: if everyone's assistant can edit the team's memory, how do you keep it honest?

By making every change visible. In Hjarni, each note keeps a full revision history that records whether a person or a specific assistant wrote each version. An edit from a teammate's Claude Code session shows up attributed to it. If an agent writes something wrong, anyone can read the diff and revert it in one click. Deleted notes sit in a recoverable trash for 30 days.

This is the part native assistant memory cannot offer: memory you can read. Not a hidden profile summarized somewhere on a server, but Markdown documents with names, versions, and authors. When your team's context is also your team's documentation, silent corruption stops being a failure mode you have to take on faith.

The honest limits

This is asynchronous sharing, not Google-Docs co-editing: notes update when someone saves, and that is the right grain for decisions and runbooks. The memory is deliberate, so a note exists because someone, human or agent, decided it should. You still curate, and the folder instructions and history make that cheap. Anthropic may eventually ship native team memory. If they do, your notes are plain Markdown you can export whole, so nothing about this setup traps you. That is the standard any team memory should meet: useful now, portable always.

One more thing worth saying plainly: because the memory lives outside the assistant, it is not even Claude-specific. The teammate who lives in Cursor and the founder who lives in ChatGPT read and write the same brain. Write once, you all remember.