TL;DR: Claude Code shares exactly one kind of memory across a team: the project CLAUDE.md checked into source control, which carries coding conventions to anyone who clones the repo. Auto memory is machine-local by design, and nothing in the memory hierarchy is built to hold account context, meaning what was promised to a customer, what was decided, and what's at risk. With 90% of developers now using AI at work, that gap compounds weekly. Aircall closed it with a team memory Claude Code queries over MCP, and now runs 3x rollouts per engineer.

A forward deployed engineer who works in Claude Code all day builds up real memory. The project CLAUDE.md knows the build commands and the architecture quirks. Auto memory has quietly learned which test suite is flaky and how you structure a migration. After a few months, the tool feels like it knows the account.

Then a second person touches the work. An engineer picks up an integration you scoped, or a new FDE joins the account, and almost none of that memory comes with them. A head of FDEs at a workflow-automation platform put it plainly: "there's been several, several dozens of sessions that I've had with Claude code. And I'm just starting to realize there's no, like, centralization to those sessions."

This article maps what Claude Code memory actually shares across a team, what never leaves your machine, and where the account's business context should live instead. The short version: git ships your conventions. Nothing ships your context.

How Claude Code memory is organized

Claude Code's memory system is a set of markdown files loaded when a session starts. Four levels stack from company-wide down to machine-specific, and each level has a different answer to the question that matters here: who else sees it?

The four file levels

  • Managed policy. Deployed by administrators to every machine in the organization. It carries org-wide instructions that individuals don't override.
  • User memory. Your personal CLAUDE.md in ~/.claude, applied to every project you open. Preferences about how you like to work, visible to you alone.
  • Project memory. The CLAUDE.md at the repo root. The docs describe project instructions as "Shared with: Team members via source control," and that clause is the entire team story.
  • Local project memory. CLAUDE.local.md, kept out of version control for per-project notes that shouldn't reach teammates, like your sandbox URLs.

Auto memory, the part Claude curates

Alongside the files you write by hand, Claude Code keeps auto memory: a MEMORY.md and topic files it maintains itself as it learns your projects. The docs are direct about its scope: "Auto memory is machine-local … Files are not shared across machines or cloud environments." There's also a budget. Only the first 200 lines or 25KB of MEMORY.md load into context, so even your own machine holds less than you'd guess.

Does CLAUDE.md share across a team?

One level of it does, and it's worth doing well. Anthropic's own best-practices guidance says to "Check CLAUDE.md into git so your team can contribute. The file compounds in value over time." Conventions, build commands, testing gotchas, architectural decisions about the codebase: all of that travels to anyone who clones the repo, and edits arrive at pull-request speed with review attached.

That is genuine team memory for code context. If your team hasn't committed a shared CLAUDE.md yet, start there this week. The rest of this article is about everything that file was never designed to carry.

What never carries across people or machines

Session learnings die with the session

The docs advise running /clear between tasks because the context window fills fast. Sessions are treated as disposable by design, which is fine for code and terrible for decisions. A founding FDE at a vertical fintech described the workaround habit half the field has adopted: "whenever my claude code […] gets at 76% […] I have a ledger." A hand-maintained migration file lets the next session pick up where the last one compacted. It works for one person on one machine, and for nobody else.

Auto memory stays on the machine

Everything Claude Code learned about your project through auto memory is yours alone. Swap laptops and it starts from zero. A teammate running the same repo on the desk next to you gets none of it, because the memory belongs to the machine, not the project and not the team.

Nothing crosses surfaces

An open feature request on the Claude Code repo asks for "a shared layer where at minimum: project memory and skills are accessible across Claude Code, Cowork, and Claude.ai Projects." Until something like it ships, memory files, skills, and MCP connections are configured per surface. The chat products mirror the problem from the other side: ChatGPT's project memory lives inside the chat product, isolates context per project, and none of it reaches a terminal.

Why account context has no home in CLAUDE.md

The account's business context fits nowhere in this hierarchy, and the docs effectively say so by scoping CLAUDE.md to project conventions and instructions. What was promised on the kickoff call, why you dropped the webhook approach for polling, which cutover date the customer's IT team froze: that's account state, not code state. Three properties make it a bad fit.

It changes at call speed, not pull-request speed. A commitment made on Tuesday's call is stale in the file until someone remembers to open a PR, and nobody opens PRs after customer calls.

The people who need it most never clone the repo. The same founding FDE told us "the number one thing is I cannot share the Obsidian brain with other people […] the salespeople don't use the Claude code." Sales, managers, and customer success need answers about the account, and a markdown file behind git access is invisible to all of them. This is the shared context problem in miniature, and it has a working definition worth internalizing: what was promised, what was decided, what's at risk, what's next.

And even for engineers, meeting notes aren't account state. Pasting call summaries into CLAUDE.md burns the file's small context budget on unreconciled prose. What belongs in a project brain is reconciled facts with sources, which is a different artifact with different plumbing.

Where each kind of memory lives, compared

  • Spreadsheets + Slack. What it holds: Status rows, decisions buried in threads. Who else can read it: Anyone with access, if they know where to look. How it stays current: Hand-updated, varies by team.
  • Project CLAUDE.md in git. What it holds: Coding conventions, commands, architecture notes. Who else can read it: Teammates who clone the repo. How it stays current: Pull requests.
  • Auto memory (MEMORY.md). What it holds: Claude's learnings about your projects. Who else can read it: Nobody, it's machine-local. How it stays current: Claude curates it, per machine.
  • Claude Projects / ChatGPT Projects. What it holds: Files, instructions, chat-side memory. Who else can read it: Collaborators, within plan and file limits. How it stays current: Whoever tends each project.
  • Team memory (account brain). What it holds: Commitments, decisions, risks, each with sources. Who else can read it: The whole team and its agents, from Claude Code, Claude chat, or Slack. How it stays current: Teammates push updates they choose, alert recipients configurable.

The first row is the real incumbent. Most teams don't lose to a rival memory product, they lose to a tracker nobody updates and a Slack scroll nobody finishes.

How teams give Claude Code a shared memory

The pattern that holds keeps the division of labor clean. CLAUDE.md holds how this team writes code. A team memory outside the repo holds what's true on each account. Claude Code reaches the second one over MCP, the same way it reaches any external system.

Tandem, the AI workspace for implementation and deployment teams, is built as that second memory. The account brain stores source-linked facts about each customer, and querying it from a session via Tandem MCP takes one connection rather than one paste per session. When a session produces something worth keeping, you push it to the brain yourself, choosing what goes. Decisions made in Claude Code sessions stop dying at /clear.

Aircall runs exactly this split. Engineers query rollout context (commitments, porting dates, integration decisions) through Claude via MCP. Paul Yi, a senior software engineer there, described the effect: "Same question, same answer, whoever asks." Several people push to one brain, and the brain is edited through an AI chat interface rather than through file gardening, which matters to anyone who has kept a wiki alive. An FDE at an industrial-AI company gave us the requirement in one line: "I don't want to babysit another system."

For teams staffing up around this role, Tandem's workspace for FDE teams covers the rest of the loop: briefs on demand or scheduled, delivered anywhere including Slack, and managers or sales querying the same brain from Claude chat instead of pinging you.

What stays manual

Honesty about the edges, because they exist.

Your shared CLAUDE.md still needs tending. It compounds in value only if people actually open PRs against it, and someone has to prune it when it bloats.

Syncing a session to team memory is a deliberate act. You trigger it and you choose what's worth keeping. An automatic resync at every checkpoint is something users ask for, and it isn't shipped. Every agent action against the brain runs with a human choosing or approving what happens.

And judgment doesn't transfer. Memory tells the next engineer what was decided and why. It doesn't tell them what to decide next, which is why senior FDEs stay valuable after the context problem is solved.

Keep git for the code, get a memory for the account

A shared CLAUDE.md solved convention-sharing years ahead of every other AI tool, so use it fully. What it will never hold is the account's memory, because auto memory stops at your machine and business context was excluded from the design on purpose. Teams that split the two cleanly get what Aircall got: any engineer asking "what's blocking the cutover" and getting the same sourced answer the FDE would give. See Tandem answer that question on one of your own live accounts, in a demo.

FAQs

Can my teammate see my Claude Code auto memory?

No. The docs state auto memory is machine-local and not shared across machines or cloud environments. To hand a learning to a teammate, either commit it to the project CLAUDE.md through a PR or push it to a team memory outside the repo that they can query too.

Should I put customer commitments in CLAUDE.md?

No. Commitments change at call speed while the file changes at PR speed, the people who need commitments mostly can't see the repo, and the memory files have a small context budget better spent on conventions. Keep code context in CLAUDE.md and account context in a queryable team memory.

Does Claude Code memory follow me across my own machines?

Only what's in git. The project CLAUDE.md travels with the repo, while auto memory and CLAUDE.local.md stay on each machine. A new laptop starts with an empty MEMORY.md no matter how much the old one knew.

Is a shared CLAUDE.md enough for a two-person FDE team?

For code conventions, yes, and it's the right first move. The gap appears the first time you onboard a second FDE onto a live account and they ask what was promised, why a decision was made, and what's at risk. None of that lives in the repo.

How do teams actually give Claude Code account context?

Over MCP. Tandem MCP exposes the account brain to Claude, Claude Code, or ChatGPT, so engineers and their coding agents pull commitments, decisions, and risks mid-session. At Aircall that pattern supports 3x rollouts per engineer, with the same sourced answer going to whoever asks.

Key terms

Shared context: the account-level memory a whole team and its AI tools can query. It answers what was promised, what was decided, what's at risk, and what's next, with sources.

Team memory: a synonym for shared context that stresses the point of failure, which is memory that survives crossing from one person to another.

Project brain: the category artifact. A maintained, source-linked store of a project's real state, as opposed to scattered notes and threads.

Account brain: Tandem's product part. A project brain per customer account, plus risk detection, Tandem agents, and a customer workspace.

CLAUDE.md: Claude Code's instruction file. The project-level copy is shared with teammates through source control and is the one team-shared piece of Claude Code memory.

Auto memory: the memory Claude Code curates for itself (MEMORY.md plus topic files). Machine-local, never shared across machines, people, or surfaces.

Tandem MCP: the MCP server that lets Claude, Claude Code, or ChatGPT query the account brain and push chosen updates back to it.