How Claude Code, Cursor and Codex Can Share Project Context
Claude Code, Cursor, and Codex do not share chat history or local memory by default. They can, however, query the same project-owned context layer so decisions, active work, code impact, proof, and handoffs survive a switch of client or model.
Connect each authorized client to the same project-scoped MCP endpoint. Keep client-specific instruction files local, and share reviewed project state through the common layer.
What can actually be shared
The useful shared layer is not a merged chat transcript. It is project-owned state: reviewed decisions, current work, source-backed documentation, code impact, verification evidence, and handoffs. Each coding client can retrieve that state when a task starts and keep its own private conversation separate.
This separation matters. Claude Code can keep CLAUDE.md, Cursor can keep its rules, and Codex can keep AGENTS.md and config.toml. Those client-specific instructions remain local inputs. The shared layer carries the working truth that should not change merely because the team changed editor or model.
The architecture: one project, several clients
Each client authenticates to the same project-scoped MCP endpoint. The endpoint resolves the same indexed sources, reviewed memories, workflow state, and code graph for every authorized client. A Start Work Brief or context query therefore begins from the project rather than from one editor's private history.
Sharing does not mean that every agent receives every stored item. Retrieval remains bounded by the question, token budget, source authority, project permissions, and freshness. The common layer should return the smallest useful evidence set, not replay the entire repository into every prompt.
Three boundaries that keep shared context useful
All clients connect to the same project ID or slug, so durable state stays attached to the repository rather than an editor account.
CLAUDE.md, Cursor rules, and AGENTS.md remain useful client-specific inputs; sharing does not require flattening them into one file.
The shared unit is reviewed project context with sources and freshness, not another agent's raw private conversation.
Private client state vs shared project state
| Criterion | Inside one coding client | Inside the shared project layer |
|---|---|---|
| Chat history | Private to the current client and session | Not copied into the shared project layer by default |
| Stable instructions | CLAUDE.md, Cursor rules, or AGENTS.md per client | Can be indexed as sources, while the original files remain under repository control |
| Reviewed decisions | Easy to lose in a prior chat or local note | Stored with project scope, provenance, and review state |
| Active work and handoffs | Usually invisible when another tool starts | Retrieved through Start Work, What Changed, and handoff surfaces |
| Code impact and proof | Reconstructed independently by each client | Shared graph context and verification evidence, checked against the local working tree |
How Snipara provides one Project Brain
Snipara is the Project Brain for AI coding agents. Its shared Project Intelligence layer gives Claude Code, Cursor, Codex, and other MCP clients the project's reviewed decisions, active work, code impact, verification evidence, and handoffs before they edit.
Hosted MCP keeps the access contract consistent across clients. Start Work Briefs, What Changed For Me, reviewed memory, Code Graph impact, and handoffs remain project-scoped, while the chosen coding client still owns reasoning and execution.
Limitations
- Each client still needs valid project-scoped authentication and correct MCP configuration.
- Shared context does not synchronize private chat histories or silently ingest every session.
- Indexed sources and code graph results expose freshness metadata; uncommitted local edits still require local reads and tests.
- Reviewed memories and decisions are evidence inputs, not autonomous approval or guaranteed project truth.
- Snipara does not replace the coding model, code review, CI, or security review.
FAQ
Do Claude Code, Cursor, and Codex share memory by default?
No. Their chat histories, local rules, and session state are separate. They need a project-owned layer outside the individual client if the same reviewed decisions and active work should be available to all three.
Does shared context mean sharing private chat transcripts?
No. The useful shared unit is selected project state — decisions, sources, active work, impact, evidence, and handoffs. Raw private conversations do not need to become project memory.
How does MCP help?
MCP gives each compatible client the same tool contract and project endpoint. The endpoint can return the same project-owned context even though the clients, models, and local instruction files are different.
Can every client still use its own model?
Yes. Snipara supplies project context; Claude Code, Cursor, Codex, or another client still supplies the model, reasoning, editing, and execution.
What if the hosted code graph is behind the working tree?
Treat the graph as indexed through its reported commit, then read local files and run tests for uncommitted edits. Shared context improves the starting map but does not replace current local verification.