Feature Request: Shared Team Memory for Claude Code

Following up on this with a design direction I am exploring.

The core idea is a passive MCP server that captures context silently as engineers work. No sharing buttons. No memory promotion. No behavior change. Engineers just use Claude Code normally and the MCP server hooks in and accumulates working context into a collective knowledge store. Investigations, decisions, discoveries, all of it.

Any engineer on the team can then ask their Claude "what do we know about the payment service?" and get back everything the team has ever explored. Without anyone explicitly sharing anything.

Two modes in one system:

1. Collective intelligence. Ambient knowledge available to everyone, always. The brain builds itself from normal work.
2. Directed requests. An engineer can @ a colleague through the MCP server. The recipient sees the request along with full context from the requester next time they open Claude.

How it evolves naturally:

1. Passive collector. Captures context from all sessions.
2. Knowledge map. An expertise map emerges organically. Who knows what, how deeply.
3. Synthesizer. Instead of returning raw fragments, it synthesizes coherent answers using the most relevant engineer's accumulated context.
4. Caching brain. Synthesized answers become instant team knowledge.
5. Agent network. Claude instances consult each other through the server.

Each stage is a byproduct of the previous one. No redesign needed.

Key design choice: store everything raw, summarize on top. The intelligence layer (naming, grouping, compaction, search) runs on the raw data and can be improved without losing anything.

I am actively looking to prototype this. Would love to hear from the Anthropic team on what hooks or APIs would be needed to make passive session capture possible from the MCP side.

Great writeup. The cross-session and cross-client context loss is a real pain point we have been tackling.

We built NEXO Brain — an open-source MCP server (AGPL-3.0) that provides persistent cognitive memory for AI agents. It implements the Atkinson-Shiffrin memory model (sensory to STM to LTM), semantic RAG with trust scoring, learnings that persist across sessions, and decision logging with outcome tracking. Currently 97+ tools.

It solves the individual persistence side of this proposal: one shared brain across Claude Code, Codex CLI, and Claude Desktop — so context built in one client is immediately available in another. Sessions write diaries, learnings compound, and the agent does not start cold.

The team-sharing layer you describe (scoped visibility, read/write permissions, team-level knowledge stores) would be a natural extension on top of this kind of architecture. A shared SQLite or Postgres backend with namespace isolation per team member + a shared namespace could handle most of the use cases you outline (handoffs, domain expertise transfer, incident continuity).

Key patterns from our implementation that might inform the team design:

• Learnings (corrections that persist) are the highest-value shared artifacts — they prevent the same mistake across all sessions/clients
• Decision logs with outcome tracking create institutional memory that survives engineer rotation
• Trust scoring on memories helps surface reliable context vs. stale assumptions
• Diary system captures end-of-session context snapshots that enable warm handoffs

If anyone is exploring this space, happy to discuss architecture. The single-user foundation is solid and running in production.

The team memory angle is the right framing. The immediate blocker though isn't where memory lives — it's that sessions don't travel at all.

Built claude-handoff to unblock the handoff case today via git: [https://github.com/NeoAcar/claude-handoff](url)

Exports the full session bundle (transcript, subagent logs, memory files) into .claude-shared/, scrubs secrets + rewrites absolute paths, reconstructs under the receiver's ~/.claude/projects/. claude --resume picks it up with the original title and history intact. Memory files ship with --memory.

Not a replacement for proper team memory infra, but it covers the "engineer picks up where teammate left off" case without waiting for server-side support.

npm i -g @neoacar/claude-handoff

Excellent request and I would highlight something you said in your opening paragraph - "knowledge flows constantly between people". To that point, I would suggest adding a real-time awareness across active sessions feature to this request.

Even something lightweight would help:

• A shared project-level memory store that all active instances read/write in real time (separate from personal user memory)
• Awareness of which files/areas other sessions are actively working on
• Decisions and context updates visible immediately, not after commit-push-pull

Along the same lines as multiple people collaborating in real-time on a google doc.

Strong +1 on the team-memory framing. One boundary I would add: shared memory and live/current coordination state probably need to be separate surfaces.

Team memory is good for durable decisions, gotchas, investigation notes, and reusable learnings. Active handoff state needs a more operational shape: owner, source, observed_at, status, expires_or_recheck_by, supersedes, and needs_verification. Otherwise the receiving Claude can inherit a stale investigation as if it were still current truth.

For ticket, PR, and incident handoffs, I would treat the unit of transfer less like "all prior memory" and more like an evidence-backed handoff packet: what changed, what was tried, what is assumed, what is blocked, and what the next person or agent must re-check first.

I had a similar idea while collaborating with a teammate. The pain point for me was that our individual Claude Code sessions weren’t synced, so two agents could easily start editing the same file or area in ways that were obviously going to conflict later in a PR.

So I've been building a small Claude Code plugin PoC around this idea for almost 2 weeks: https://github.com/RubiYH/teamem

It uses MCP and Claude Code's experimental 'Channels' to give Claude Code shared team context like active scope claims, briefings, decisions, risks, progress, and handoff notes.

It’s still early, but this issue describes exactly the kind of problem I was trying to explore.

Would love to hear others' experiences and see what people are building here!

I think I built exactly what this thread is describing.

Context Cloud is an MCP server designed around the team memory problem. Your team's AI sessions (across Claude, Cursor, Codex, Windsurf) share a persistent knowledge layer. Engineer A commits a decision from Claude Code, Engineer B recalls it from Cursor the next morning with full attribution. No export, no copy paste, no re explaining.

What's live today:

• Shared workspaces with role-based access and email invites
• Typed knowledge chunks :( decision, finding, convention, state, question, reference ) so the receiving session knows how to interpret what it's getting, not just a raw text dump
• Attribution on every chunk (who committed what, when, from which session)
• Cross-tool via MCP : works in Claude (web/desktop/Code), Cursor, Codex, Windsurf
• Dashboard to browse, search, edit, and curate your team's knowledge with a graph view of how chunks relate
• Automatic dedup and supersession : conflicting context gets resolved, not stacked
• Two-layer retrieval: LLM KB selection + hybrid vector/BM25/RRF fusion search
• Zero server-side LLM cost : extraction happens on your AI tool's side (so its free!!!)

Benchmarks from our eval suite:

99.4% weighted product readiness (detail preservation 98.5%, cross-session continuity 100%, cross-tool portability 100%)
94/100 on a realistic 20-session stress test simulating evolved facts, outdated context, and adversarial phrasing
Detail capture: 95.7–97.1% across proper nouns, numbers, URLs, technical IDs, and temporal facts
Retrieval: 0 ranking failures, 0 embedding failures across all test runs

I built the product using the product itself Every architecture decision and convention in the codebase lives in a shared Context Cloud workspace that any session on any tool can recall.
It's free. Would love for anyone in this thread to try it and tell me what's missing: contextcloud.pro
GitHub: github.com/abhinavala/cntxtv2
npm: @contextcloud/mcp-client

### I think I built exactly what this thread is describing.

@abhinavala - your repo link is giving a 404

This framing matches the part of team memory that feels hardest to make safe: once memory crosses people/agents, the first debugging questions are provenance questions, not retrieval questions.

For a shared pool, I'd want a privacy-safe receipt for each handoff that can answer:

• who/which agent promoted or corrected this memory?
• what order did corrections happen in?
• which memories were candidates vs selected vs suppressed for this receiving agent?
• which selected memories actually hydrated into context?
• are selected memories fully accounted for by known/unknown author and decisive/supporting/unused/unknown buckets?

I put together a small executable fixture for that shape here: https://github.com/caioribeiroclw-pixel/pluribus/commit/c66c3f9

Raw trace example: https://raw.githubusercontent.com/caioribeiroclw-pixel/pluribus/main/examples/context-input-evidence/memory-provenance-otel-trace.json

The important constraint: don't log raw memory bodies, tickets, private paths, incident notes, or customer data. Hash identities + role/scope/sequence/relevance counts are usually enough to debug "why did this Claude know this?" or "why did this stale memory get reused?" without turning shared memory into another data leak surface.

So +1 to shared team memory, but I think auditable who/when/order/hydrated needs to be part of the minimum viable shape, not a later enterprise feature.

Hey there,

Try the link directly, it’s completely free. Open sourcing it doesn’t work
too well especially because it’s collaborative and synced across the cloud.

URL is contextcloud.pro

Thanks,
Abhi Ala

On Fri, May 22, 2026 at 2:06 AM Adrian Cockburn @.***>
wrote:

netclectic left a comment (anthropics/claude-code#38536) <https://github.com/anthropics/claude-code/issues/38536#issuecomment-4516145601> I think I built exactly what this thread is describing. @abhinavala <https://github.com/abhinavala> - your repo link is giving a 404 — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/38536#issuecomment-4516145601>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BEKJKNKULQVT4O5ULTI6ZRT4374BFAVCNFSM6AAAAACW6KD4OWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMJWGE2DKNRQGE> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: @.***>

We've been running shared team memory as an MCP server in production for a few months (data-mcp, MIT) and want to share two categories of findings that this thread keeps circling — access control and context cost — because both turned out to be harder than the retrieval part.

1. Access control needs to be enforced below the MCP layer.

Our first version scoped private vs shared records inside the MCP server (every record has an owner_id; tools filter by it). That's enough against accidents but not against a teammate whose agent queries the database directly — and agents will do that when given a connection string. What actually closed it:

• per-member JWTs with owner_id claims, checked by Postgres RLS — the database fails closed, not the proxy
• per-member revocation via a jti claim + denylist consulted in the RLS policies. The "engineer leaves the team" case is the headline scenario for team memory, and rotating one shared secret to handle it (killing everyone's tokens) is painful enough that in practice nobody does it — departed members keep access
• the denylist itself must not be readable by members (who-was-revoked is itself sensitive), so the RLS predicate goes through a SECURITY DEFINER function

@caioribeiroclw-pixel's provenance framing matches what we converged on for handoffs: we ended up making handoffs a first-class typed record (what_changed, tried: [{approach, outcome}], next_steps, from/to member, status lifecycle) rather than free-text memory, precisely because the receiving agent otherwise inherits a stale investigation as current truth — the failure mode @carltonawong described.

2. Team memory has a per-session context tax, and it's larger than the storage problem.

A memory server with one tool per collection/operation is the natural design and it's wrong: ours grew to 44 tools ≈ 10K tokens of schemas injected into every teammate's every session before any work happens. Two things fixed it:

• consolidating CRUD into 4 generic record_* tools driven by a server-side schema registry (44 → 21 tools, ~46% context cut). Validation errors return the expected field spec so the model self-corrects instead of needing the full schema up front
• keeping instructions under ~2KB and prefix-organized — long server instructions get truncated, and the model handles "tools are grouped by prefix: knowledge_, record_, handoff_*" better than an exhaustive inventory

If first-party team memory ships, I'd argue the minimum viable shape is: owner-scoped records enforced at the storage layer, per-member credentials that are individually revocable, typed handoffs with provenance rather than free-text context transfer, and a deliberately small tool surface. Happy to share more implementation detail if useful — everything above is in the repo including the live RLS bypass/revocation test suites.

One angle I haven't seen in this thread yet: most teams already operate a shared memory — the task tracker / wiki / vault everyone maintains because the team runs on it. The missing piece isn't creating a shared store, it's that agents can't query the existing one well.

I built an MCP layer over exactly that (pluggable storage adapters; TickTick and Obsidian-vault today). The Obsidian adapter is just files on disk — no plugin, no running app — so a vault in a shared git repo gets you team memory with the access model you already have: branches, PR review for memory edits, history for free. Every retrieval result carries provenance (which note, which search branch surfaced it), which matters more in a team setting — you want to know whose memory you're trusting.

Trade-off vs. automatic capture: someone has to write things down. In practice that's also the feature — curated entries stay trustworthy in a way auto-captured session logs don't, and the upkeep already happens because the team needs the tracker anyway.

https://github.com/renezander030/agentic-task-system

This thread seems to be converging on an important distinction: team memory is not just a shared database; it is a governed memory substrate.

The Obsidian / shared-git angle resonates with me because git gives a few things that pure retrieval systems usually have to rebuild later:

• human review before promotion
• version history and rollback
• branchable context
• visible ownership of memory edits
• provenance for why a piece of context exists

For team memory, I think the hard part is deciding when a local observation becomes durable shared context. Automatic capture is powerful, but without promotion boundaries it can spread stale assumptions faster than documentation ever did.

I’ve been experimenting with a smaller personal version of this pattern: markdown + git as an AI-collaborable memory vault that stays portable across tools/models.

https://github.com/hegu-1/personal-memory-vault-starter

The same shape may scale upward: personal continuity first, then team memory with review, provenance, and scoped promotion.

The newer comments here changed my take a bit: the hard part is no longer just shared memory exists; it is proving which shared memory actually crossed into the receiving agent and keeping the tool/context surface small enough that teams leave it enabled.

The production note above about 44 MCP tools costing ~10K schema tokens is a useful constraint. For team memory, I would now treat these as minimum receipts alongside provenance:

• candidate memories returned vs selected vs suppressed for this task;
• selected memories that actually hydrated into the model context;
• tool/schema inventory made visible for the session vs deferred behind search/generic tools;
• promotion boundary: who/what turned a local observation into shared authority;
• freshness/owner/revocation signals, without raw memory bodies or private ticket text.

That gives reviewers two falsifiable checks:

1. Did the receiving agent really get the handoff/team-memory context it claims it used?
2. Did the memory substrate add a hidden always-on context tax that will make users disable it later?

I added small executable Pluribus fixtures for those two checks after watching this thread and adjacent memory-MCP launches:

• memory provenance / authority receipt: https://github.com/caioribeiroclw-pixel/pluribus/tree/main/examples/memory-provenance-authority-receipts
• context budget receipt, including loaded vs suppressed sources and tool schema counts: https://github.com/caioribeiroclw-pixel/pluribus/tree/main/examples/context-budget-receipts
• dynamic MCP tool-surface diff: npx --yes pluribus-context@latest demo tool-surface-diff --json

Not proposing Pluribus as the shared-memory store. The sharper role seems to be a neutral audit layer next to stores like Context Cloud, Obsidian/git vaults, or MCP memory servers: prove what was promoted, retrieved, hydrated, suppressed, and how much context/tool budget it consumed, without logging the raw memory.

Full disclosure: I maintain Data Olympus, a git-native governance knowledge base plus MCP server for coding agents: https://github.com/knaisoma/data-olympus

This is the right problem area. The boundary I would add is that "shared team memory" probably needs at least two surfaces, not one.

One surface is collaborative/session memory: handoffs, current investigations, active ownership, recent discoveries, and working state. That content often needs freshness, ownership, expiry, and privacy controls.

The other surface is governed project knowledge: accepted standards, architectural decisions, migration choices, operational rules, and known superseded guidance. That content needs review, stable identity, lifecycle status, and history. It should not be updated just because one agent inferred something during a task.

Data Olympus is aimed at the second surface. The bundle is markdown in git, each entry has a stable id, controlled type/status/tier, and explicit supersedes links. The MCP read path can ask for currently in-force guidance only, while the write path can route agent-suggested changes into proposals instead of silently changing team truth.

For Claude Code, I think this distinction matters because team memory that is useful for handoff can be actively harmful if treated as governing truth six weeks later. A shared memory implementation should let the agent tell the difference between "someone observed this during an investigation" and "the team has accepted this as the rule for this repo."

Full disclosure: I built BaseThread, an MCP server for this.

The distinction between session/collaborative memory and governed project knowledge that's come up in this thread matches what we landed on too, but our angle is slightly different: most teams already use more than just Claude Code (Cursor, ChatGPT, other MCP clients), so a Claude-only shared memory still leaves the rest of the team's tools blind to it.

BaseThread models this as company/team/project scoped context that any MCP client reads and writes over MCP, so a handoff written from one person's Claude Code session is immediately visible to a teammate's Cursor or ChatGPT session too, not just other Claude Code sessions.

Happy to share more on how we're handling the promotion-boundary problem (local observation vs accepted team truth) if useful, it's a real design challenge once multiple tools are writing to the same store. https://basethread.ai

@navbuildz yes — the promotion boundary is the part I would most like to understand, especially because BaseThread also advertises local/offline mirrors and automatic agent write-back.

A concrete two-writer test would make the semantics much clearer than another storage diagram:

1. Claude records an observation A for project P.
2. Cursor is offline on an older mirror and records conflicting observation B.
3. A human (or an authorized workflow) promotes A to accepted project guidance.
4. Cursor reconnects and uploads B.
5. A third MCP client asks for the current guidance.

I would expect the test to pass only if:

• B cannot silently overwrite or supersede accepted A;
• the stale writer gets an explicit conflict/rebase result rather than a successful-looking write;
• the third client receives A as governing context, while B remains inspectable as an unaccepted observation;
• the audit trail can identify the source client, base revision, promoter, and supersession/conflict decision without storing a raw session transcript.

How are you representing that today: separate record types/authority states, an append-only event stream, or last-write-wins plus synthesis? And does promotion require a human action, or can an agent cross that boundary automatically under scoped policy?

That answer would help distinguish cross-tool availability from cross-tool authority — the latter seems to be where shared-memory systems become trustworthy or dangerous.