Shared project memory for Claude Code, Codex and Cursor

What is shared project memory?

Shared project memory is a durable record of what a project currently understands. It can explain why a design was chosen, which approach was rejected, what evidence supports a decision, and what still needs an answer.

In Klypix, the record lives with the project. A supported agent can retrieve relevant context through the Model Context Protocol (MCP), then record new findings in the same brain. An explicit correction can supersede an older decision while preserving its history.

The Windows workspace lets a person inspect and edit that understanding beside files, notes and evidence. The free, Apache-2.0 klypix-mcp engine connects coding tools to the brain and works without the optional proprietary Windows app.

The same Klypix workspace can hold a project’s files, links, images and PDFs beside the recorded decisions. Klypix for iPhone shares selected photos, files and links into the Windows workspace through the cloud. Those capture features are optional; a team can use the brain engine on its own.

How do the common approaches compare?

Teams usually combine more than one of these. The useful question is which kind of context each one keeps, and whether it travels with the project. For specific products, see our comparison of Klypix, Knowit, Klio, agent-parity and shared-agent-memory.

Ways to carry project context between coding sessions and tools
Approach	What it keeps and how tools reach it	Portability	Main limitation
Rules files (`AGENTS.md`, `CLAUDE.md`, Cursor rules)	Stable conventions and instructions, loaded by tools that read that file.	Plain text in Git.	Different tools read different files. Git retains edits, but reasons and supersession must be recorded deliberately.
A tool’s own memory (for example Claude Code’s auto-memory)	Notes one tool writes for itself between its own sessions.	Outside the repo, per user and per machine.	Sharing with other tools or teammates requires an explicit export, link or integration.
Specs and decision records in the repo	Agreed designs and their rationale. Agents read them when pointed at them.	Plain text in Git.	Written and superseded by hand; an agent consults them only when instructed.
Agent task trackers	Work items, dependencies and handoff status, usually through a CLI or MCP.	Varies by tool; some store data in the repo.	Centred on tasks rather than decisions, corrections and evidence.
Memory MCP servers	Facts or conversation memory, often as a knowledge graph or vector store, over MCP.	Depends on where the store lives: a local database or a hosted service.	Often scoped to a user or machine rather than committed with the project.
Shared project brain (Klypix)	Decisions, explicit corrections, evidence, open questions and active work, over MCP on supported hosts, with lifecycle hooks in Claude Code.	One `brain.klypix` file committed with your code; a documented ZIP you can inspect. The MCP server runs locally; context supplied to a cloud coding agent can still reach its provider.	Starts with what you capture; live session presence is limited to one machine.

How does a coding-tool handoff work?

Consider a hypothetical authentication change. A Claude Code session records that refresh tokens must stay on the server and links the decision to its evidence. Later, a Codex session starts work on sign-in in the same project.

Declare the task. The new session calls brain_sync with the project path, its intent and the exact files it expects to touch.
Retrieve the reasoning. Task-relevant context comes back. The session can ask brain_ask for the earlier authentication decision and its correction history.
Check a proposed change. brain_challenge can surface conflicting prior decisions or standing rules. An empty result does not prove the proposal is correct.
Record what changed. The session captures a useful finding or explicit correction with brain_note, then marks its task complete with brain_sync.

The next session receives the understanding that was captured. It still needs to inspect the current code and verify that the evidence applies.

Which tools can use the same brain?

Integration depth varies by host. This is the distinction to check when choosing how to connect a project:

Klypix integration paths
Coding tool	Integration path
Claude Code	MCP tools and lifecycle hooks for automatic context and capture.
Codex	MCP tools and the `brain_sync` gateway; native hooks are optional.
Cursor, Cline, VS Code / Copilot, Gemini CLI, Antigravity	Project MCP configuration and rules that instruct the agent to use the brain. Retrieval and capture depend on tool calls.
Windsurf	Global MCP configuration plus project rules.
Aider	Project rules and a CLI path.

Use the current setup documentation for the host you run. A configured connection and a successful task-context retrieval are useful checks before relying on a handoff.

How does a small team share one brain?

The brain is a project file, so it moves between developers the same way the code does.

Set up each machine. Run npx klypix-mcp install inside the project. It gives the project a brain if it has none, wires the supported editors it detects on that machine, and verifies that the MCP tools answer.
Commit the brain with the code. brain.klypix and the managed configuration and rules files are ordinary files in the repository.
Let Git merge brain changes card by card. In a Git repository, install registers the .klypix merge driver; npx klypix-mcp git-driver install does it for any clone. When two people change the brain, cards added on both sides are kept, and a card edited differently on both sides keeps both versions instead of silently overwriting one.
Review brain changes. npx klypix-mcp diff main lists the cards added, updated and removed.

A clone without the merge driver gets an ordinary binary conflict on brain.klypix, and merging happens when someone pulls, not as live sync. Live session presence and file-overlap warnings stay on each developer’s machine.

When is a rules file enough?

A short AGENTS.md or CLAUDE.md file can be enough for stable conventions in a small project. It is easy to review and version in Git.

Klypix becomes useful when the record includes changing decisions, rejected approaches, supporting evidence and open questions across sessions. Rules can tell a supported agent to consult the brain; the brain supplies task-relevant context and preserves explicit corrections. Git continues to version the code and the brain file.

What are the limits?

It starts with what you capture. A new brain does not reconstruct the project’s missing history.
Live coordination is local. Default session presence and exact-file overlap warnings apply to connected sessions for the same OS user on the same machine. Warnings are advisory and rely on declared file paths.
Teammates share durable context through Git. Committing and pulling brain.klypix carries the record between computers. It does not make their live sessions visible to one another.
You choose and run the agents. Klypix does not launch, route or supervise them.
Check the privacy boundary. The brain file is local, but an AI provider can receive context supplied to its agent. See the privacy policy before using sensitive project information.

What has been verified?

On 24 September 2026, we ran the published klypix-mcp 1.86.2 conformance runner on Windows with Node 24.13.1. All 15 checks passed. The raw result and test scope are public, alongside the versioned runner source.

npm exec --yes --package=klypix-mcp@1.86.2 -- klypix-conformance --json

The runner creates a temporary project and two isolated MCP clients. It checks task-context retrieval, peer visibility, exact-file overlap detection and coordination-note delivery. Additional checks use in-process finding fixtures and simulated cross-machine relay primitives.

Scope matters: this is an author-run protocol check, not an independent benchmark, a Claude Code/Codex/Cursor UI test, or a live two-computer test. It does not measure recall quality or prove automatic capture in those hosts. An overlap labeled “blocking” in the raw output describes severity; the warning remains advisory. The desktop relay bridge is a separate boundary.

A decision and its correction in fresh sessions

We also ran a separate, reproducible smoke test of klypix-mcp 1.86.2 on 24 September 2026. It starts with an empty disposable brain and uses actual brain_note calls. All 11 assertions passed across four fresh MCP processes with separate empty home directories.

Capture SQLite for an offline prototype. A fresh process retrieves the decision and its rationale.
Explicitly correct it to PostgreSQL for concurrent writers. Another fresh process retrieves the new rationale, while the old decision remains labeled as superseded and linked to its correction.
Copy only brain.klypix to another local project path. A fresh process there retrieves the current decision.

Inspect the actual assertions and returned context and download the reproduction script. Save the script in an empty directory, then run:

npm install --ignore-scripts --no-audit --no-fund klypix-mcp@1.86.2
node verify-memory-handoff.mjs --engine ./node_modules/klypix-mcp --out result.json

This author-run fixture uses one synthetic decision, one correction and lexical retrieval with a shared subject. It checks persistence and correction handling; it does not measure paraphrase recall, large-project accuracy, automatic host capture, an LLM acting correctly, or a teammate on another computer. It is not a comparative product benchmark. The receipt includes source hashes, package provenance, the fixture text and these limits.

Use the cross-tool handoff trial to evaluate capture, retrieval, corrections and a teammate’s clone in your own workflow.

Try it on one project

For installation and a first-session walkthrough, follow the klypix-mcp setup guide.

Follow the klypix-mcp installation instructions for your coding host. Start in a project you can use for a small trial:

npx klypix-mcp install

Capture one real decision and the reason behind it. Start a new supported session, ask what was decided, and inspect the returned evidence. Then record an explicit correction and repeat the question. This checks the handoff against your own workflow.

For the visual workspace, download Klypix for Windows. For current availability and plan details, see pricing.