You write a decision down in Cursor at four in the afternoon: the payments service keeps its own retry table, do not fold it into the queue. At six you open Claude Code on the same repository. The memory server is connected in both editors, and the agent proposes folding the retry table into the queue. You read the memory back from Cursor and the note is there. You read it back from Claude Code and the store is empty. Nothing raised an error, and nothing is broken.
Sharing memory across editors over MCP is a simple mechanism, and the trouble lives in the setup step around it. I checked six persistent memory systems, including the one I work on, for one thing: not whether they claim cross-IDE sharing, but the concrete way each one can stop sharing while every client still reports a healthy connection.
One line to carry through the rest: a healthy connection is a fact about the transport, sharing is a fact about the account, and the first tells you nothing about the second.
The mechanism, wherever there is one
Where cross-editor sharing exists in this comparison, it reduces to one sentence: one account, several client applications, all pointed at the same backend. The interesting question was never how the syncing works. It is which setup step, if skipped or done inconsistently, leaves two clients that both connect without sharing anything, and how you would ever notice.
Mnemoverse, ours: sharing is the default, and two ways to defeat it
I will start with the one I work on, because its failure mode is the one that opened this article. Mnemoverse removes the setup step most vendors leave in: one API key, and every connected client already shares, by default rather than as a mode to discover. The editors guide says it in one line: "same key, same memory, every tool". The VS Code path can also connect without a key: it opens your browser to sign in, registers itself, and lands in the same account system every key-based client uses.
The first way to defeat this is that the key is the account. A key created in a different console account connects perfectly and returns that account's store, typically empty, with no error anywhere. The keyless path has the same shape, because it signs into whatever account the browser holds. So the check is not whether each client is connected but whether each is connected as the same account.
The second way is a filter you can turn into a partition. Reads default to your own domains, unfiltered. If a team writes with a separate domain per tool and later filters reads by that same domain, it has built its own partition. Not a product limitation, something a user can do to themselves, and the fix is to stop filtering.
Cognee: two modes, and a catch in the shared one
Cognee names its traps itself, on its own documentation pages, and the first is easy to conflate with a second list on the same page. Its MCP server has two architecture modes that determine sharing, not to be confused with the setup options the page lists for getting it running. In the vendor's words: "The MCP server manages its own database and processing. Each MCP instance maintains separate data." That is Standalone Mode. And: "The MCP server connects to a centralized Cognee backend via API. Multiple MCP instances can share the same knowledge graph." That is API Mode.
Not a bug: it is documented and deliberate, personal development kept separate from team sharing. Team sharing has its own catch, and Cognee names that one too: "Each instance authenticates with a single token, so everything it writes belongs to one Cognee user". Its fix is one process per tenant: "To separate tenants, run one MCP process per tenant, each started with a token for its own backend user, so the permissions system enforces the boundary." Standalone Mode keeps each instance's data separate, the right default for one person in one editor, and with stdio "The client starts the server as a subprocess", so each editor configured that way runs its own instance with its own data. For several clients on one graph, the vendor points to API Mode: "To connect multiple clients to a shared knowledge graph, run MCP in API mode pointing to a centralized Cognee backend". Its cloud connection page says the same: "If you want multiple AI clients to share a single knowledge graph, run a self-hosted Cognee backend and point the MCP server at it using API_URL and API_TOKEN".
Mem0: one plugin across the editors, an identifier for the rest
Mem0 documents cross-tool sharing explicitly, and for editors it is built in. Its changelog says it in one sentence: "The shared Mem0 editor plugin now covers Kimi Code alongside Claude Code, Cursor, Codex, and Antigravity, running on the same scripts, skills, and memory bank, so context written in one editor is available in the others." Project memory in that plugin is one namespace per repository, and personal memory is keyed to a user id the plugin resolves from your local account name unless you set one. That is where the editor path can split, on a second machine, and the Claude Code page says so next to the setting: "Set explicitly to share memories across machines." The gateway integrations, OpenClaw and Hermes among them, are the other place, and there the identifier is the whole boundary: "All memories are scoped to this userId: different values create separate memory namespaces." Each of those integrations names its own default, so two left on their defaults can land in two pools that never merge, and the same pages name the cure, an identifier you set yourself: "Set a user_id and it applies to every gateway, so one person gets a single merged memory store no matter where they talk to the agent."
Supermemory: spaces on MCP, a repository tag in the plugins
Supermemory states the claim plainly on its MCP overview: "Supermemory MCP gives every MCP-compatible assistant a shared memory layer". On the MCP path the mechanism is one account reached by browser sign-in, and the same page says so: "After you connect, your client opens Supermemory in a browser. Sign in or create an account, then choose which spaces the client can access. Supermemory uses OAuth, so no API key is required." There is no shared key to get wrong. What the sentence does contain is the setup step: each client picks the spaces it can access, and unless you name a space in a request, "Supermemory uses your active space or account default". Two clients authorised to different spaces connect and share nothing, and the page presents that as the design for keeping unrelated work apart, which it is.
The coding plugins key on something else, and the vendor states it as a feature: its Cursor plugin page says Cursor shares one repository tag with the other coding plugins it names, "so agents working on the same repo read and write the same memory". The tag is built from the repository and a hash of its Git remote, and a repository without a remote falls back to its local path, so a copy of the same code with a remote and a copy without one carry different tags. On the developer API the container tag is the boundary itself, in the vendor's words "an authorization boundary, not just an organizational one".
Letta, Graphiti and Zep: what the pages say and where they stop
Letta answers for the clients it names, and it names two families. Outside editors, its documentation index says: "A signed-in agent keeps the same memory and identity across the terminal, desktop app, web app, and messaging platforms, and can move between computers." Into editors, its adapter for the Agent Client Protocol puts one agent, memory included, inside editors that support ACP, and the page names them: "The following examples cover Zed, JetBrains IDEs, and Obsidian; other ACP clients use the same adapter and environment variables." Two editors share when both point at the same agent, and the same page says how you get there: set the agent ID in each client to reuse an existing agent, or leave it out and the adapter creates an agent on first use. Leave it out in two editors and you have two agents, which is the Letta version of the same split.
Graphiti, the open-source half of Zep, has its own MCP server, and the vendor calls it an experimental implementation. Its page names three clients: "This enables AI assistants like Claude Desktop, Cursor, and VS Code with Copilot to interact with Graphiti". What no page I read states is what happens when two of them are connected at once. Isolation is by group id, and the namespacing guide leaves queries across namespaces to your application.
Zep's hosted product documents sharing directly, in a sentence worth quoting whole: "A user's in-house agent and their personal MCP client share one user graph, so context written by one is available to the other." Its own pages name the catches: "The selected project is fixed in the signed token.", the server "Uses per-account MCP seats; seat counts vary by plan", sign-in goes through a workspace or enterprise identity provider, and "A connection allows writes by default; an administrator can switch it to read-only". None of that contradicts the sharing claim. It does mean the gate is organisational rather than technical, which is a different thing from no gate.
The table
Six vendors, seven rows, because Zep's hosted product and its open-source half behave differently enough to be read separately. Every quotation above is a contiguous substring of a page the vendor published, re-checked on 2026-09-14 and, for Supermemory, again on 2026-09-18; the pages are the vendors' MCP, plugin and setup pages named in each section, and the comparison lives on the full write-up.
| claims cross-IDE sharing | the concrete way it can fail to happen | |
|---|---|---|
| Mnemoverse | yes, default behaviour | a key issued to a different account (connects, returns that account's store, no error); or a per-tool domain filter the user adds themselves |
| Mem0 | yes, shared editor plugin and hosted MCP | a user id resolved per machine unless you set one; in the gateway integrations, a different default identifier per integration |
| Cognee | yes, in API Mode | Standalone Mode in each client, where every instance keeps separate data; in API Mode, one token is one user unless you run one process per tenant |
| Supermemory | yes, explicit | on MCP, different spaces authorised per client; in the coding plugins, a different repository tag for the same code |
| Zep (hosted) | yes, explicit | the project pinned in the token at sign-in, plan-dependent seats, identity-provider sign-in; a connection an admin can set read-only |
| Graphiti (self-hosted) | three clients named on its MCP page | two clients at once not described; isolation by group id |
| Letta | yes, one agent across its own apps and in ACP editors | no agent ID set, so each editor starts its own agent |
Check your own setup with data, not with a checkmark
Write a marker from one tool and read it back from the other. That is the whole test, and it is the only one that catches every row above, because every row above can happen with the connection working in both editors. For Mnemoverse, confirm every client is on the same account, by the same key or the same browser sign-in, then confirm no per-tool domain filter unless you added one deliberately. For Mem0, the shared plugin in each editor, and a user_id you set yourself once a second machine or a gateway integration joins. For Cognee, API Mode with every client pointed at one Cognee backend, rather than Standalone Mode in each client, and one process per tenant when the clients belong to different people. For Supermemory, the same account and the same authorised spaces in every client, which its own tools report ("Inspect the authenticated account, permissions, scope, and active space"), and in the plugins the same repository with the same Git remote. For Letta, the same agent ID in every ACP client. For Zep, every client signed in to the same project.
If you run two editors against one memory, which pair is it, and did the marker come back? If it split for you in a way none of the seven rows names, that row belongs in the table.
Disclosure: I work on Mnemoverse, one of the six vendors above, so weigh the argument accordingly. The full comparison with every source page is on our library, and the MCP server is open source (MIT): github.com/mnemoverse/mcp-memory-server.
Top comments (5)
"Connected" is the trap, and it is the same trap everywhere in this space: the client is reporting its own successful handshake, not the server's view of who it is talking to.
We hit the identical class on a remote MCP server. Two clients would both report a healthy connection and then behave as if they had different data, because each had completed its own OAuth dance and landed on its own session. The handshake succeeded in both, which is exactly why it told us nothing.
What settled it for us was making the server the witness rather than the client: log the resolved identity on every tool call and compare across clients, instead of trusting either client's status line. If both clients are genuinely one identity, the server says so. If they are not, you find out in one request rather than after a day of config archaeology.
Same principle we ended up shipping in the product itself, where an application only counts as sent when the other side confirms it: aiapplyd.com/mcps
Server as witness is the right move, and one vendor in the table already hands it to the user as a tool: Supermemory's MCP can "Inspect the authenticated account, permissions, scope, and active space". The limit I would add is that a matching identity is necessary but not sufficient. Two clients can resolve to the same account and still read different scopes: a different active space in Supermemory, a different user id in a Mem0 gateway, a different agent ID in Letta. So the server's log should carry the scope it resolved alongside the identity, and even then a read-back of a marker stays the cheapest end-to-end proof, because it tests the exact path the agent will use.
"Connected" and "sharing" being different states is the trap. Each editor opens its own session with the same server, and the store quietly partitions by client identity or scope - so nothing errored because nothing failed; the writes just went to two different rooms of the same building. Your read-back-from-the-other-side test is the only proof that counts. Would be good to know what the server actually keys on: project path, client name, or session.
It differs by vendor, and that spread is the useful part of the answer. On the one I work on, reads key on the account behind the API key or the browser sign-in; a split by project or by tool exists only as a domain you choose to write and filter by. Mem0's editor plugin keys project memory on the repository and personal memory on a user id it takes from your local account name. Supermemory's coding plugins key on a tag built from the repository and a hash of its Git remote, so the repository, in effect. Cognee keys on the server instance, and in API Mode on the token that instance started with. Letta keys on the agent ID, Zep on the project fixed in the signed token. That is also why the read-back test is the one I trust: it does not need to know which of these your setup uses.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.