The missing layer in AI tooling: sharing what your assistant already knows

A developer built memshare, an open-source tool that lets users share AI assistant memory between teammates as plain JSON files rather than locking it inside a single chat product. The tool uses the Model Context Protocol (MCP) to work with clients like Claude Code, Cursor, and Windsurf, and enforces four consent gates so private memories never leave a user's machine without explicit approval. The developer notes an honest risk: since MCP cannot force a model to call a tool, memory capture can silently fail, so memshare surfaces capture statistics to make gaps visible.

It took my AI months to learn how I think, code, and ship. When a teammate joined the project, their AI started from zero — same codebase, same conventions, none of the context. So I built memshare https://github.com/kampana/memshare : peer-to-peer AI memory sharing, with consent on both sides. Every AI tool today treats memory as a product feature locked inside one account. Claude remembers things for you . ChatGPT remembers things for you . Nobody else can get at it — not your teammate, not your other tools, not even you in a greppable format. That means: memshare treats AI memory as a data type — plain JSON files you own — not a feature of someone else's chat product. npm install -g memshare-mcp memshare init Connect it to your AI tool once, and capture happens in conversation: "we went with Postgres — the JSONB support decided it" → the AI calls memory set , saved as private "what do you know about this project?" → the AI calls memory get No commands to run. No copy-pasting. Your AI saves what it learns as you work. When you want to share context with a teammate: See exactly what would go out memshare export --tags "project-x,architecture" --for alice --preview Happy with it? Write the bundle memshare export --tags "project-x,architecture" --for alice --expires 30d → ~/.memshare/bundles/bundle-a3f8c2d1.memshare.json Send that file however you want — Slack, email, AirDrop. On Alice's machine: python memshare preview bundle-a3f8c2d1.memshare.json look, import nothing memshare import bundle-a3f8c2d1.memshare.json choose item by item Alice picks each item individually. Everything lands private — receiving context is not consent to pass it on. This is the part I care most about. Sharing someone's AI context without their control is a terrible idea. memshare has four gates: private or shareable . Private items never leave, even if their tags match an export. --preview runs the same code path as the real export — there's no separate preview implementation that can drift. memshare uses MCP https://modelcontextprotocol.io/ Model Context Protocol , which means it works with any MCP client: // Cursor / Windsurf / GitHub Copilot — add to your MCP config { "mcpServers": { "memshare": { "command": "npx", "args": "-y", "memshare-mcp", "serve" } } } Claude Code claude mcp add memshare --scope user -- npx -y memshare-mcp serve A designer in Cursor can hand component conventions to backend devs in Claude Code, and get the API contract back. Different people, different tools, same bundle format. ~/.memshare/memories/ .json the actual product — plain JSON files ▲ ▲ ▲ │ │ │ MCP server CLI future adapters │ Claude · Cursor · VS Code · Windsurf · any MCP client The memory store is the product. The MCP server is one adapter over it, the CLI is another. If MCP disappears tomorrow, your data is still sitting in a folder — human-readable, diffable, git-friendly. ~/.memshare/ ├── config.json ├── memories/ │ └── mem <uuid .json one file per memory └── bundles/ └── bundle <id .memshare.json No database. No server. grep works. diff works. git works. The honest risk: nothing in MCP can force a model to call a tool, so capture can quietly fail. memshare makes that visible: memshare stats 12 memories, 5 in the last 14 days ▂▁▄█▂ ▁▃ 14d ago → today - 9 captured by an assistant, 3 added by hand - 5 shareable, 7 private A flat line means capture isn't firing, and you know within days. js import { MemoryStore, selectForExport, planImport } from "memshare-mcp"; const store = new MemoryStore ; await store.add { content: "Team chose Postgres over MySQL", tags: "db" } ; const { included, blocked } = await selectForExport store, { tags: "db" } ; Preview and the real action share one code path. selectForExport and planImport compute what would happen; the CLI renders that and then acts on it. No parallel implementation for a preview — consent based on a stale preview is not consent. git clone https://github.com/kampana/memshare.git cd memshare && npm install && npm run build bash examples/try-it.sh The script builds two fake stores in a temp directory and runs the full flow — capture, PII blocking, export, per-item import — then cleans up. Nothing touches your real config. Or just install it: npm install -g memshare-mcp memshare init Open source, MIT licensed, no server, no signup. I'd love feedback — especially on the consent model and whether the sharing flow feels right. Issues and PRs welcome.