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." Install the defaults per client, expecting memory to follow you from one editor into the next, and you get Standalone Mode's isolated graphs, one per client. Mem0: scoped by the identifier you pass Mem0 documents cross-tool sharing explicitly, a hosted MCP endpoint with several clients on one URL. It is just as explicit about the mechanism, though it spells it out on its plugin pages rather than on the endpoint page: "All memories are scoped to this userId: different values create separate memory namespaces." Each plugin names its own default identifier, so two tools left on their defaults can land in two pools that never merge. 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, or with different active 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: "Cursor shares one repository tag with the Claude Code, OpenAI Codex, and OpenCode plugins, 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. 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-13; 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, hosted MCP a different identifier per integration; plugin defaults differ unless you set one Cognee yes, in API Mode Standalone Mode left in place per client; in API Mode, one token is one user unless you run one process per tenant Supermemory yes, explicit on MCP, different spaces or active spaces 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 for 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, one identifier you set yourself in every integration. For Cognee, API Mode rather than Standalone the moment more than one client needs the same graph, and one process per tenant when the clients belong to different people. For Supermemory, the same account and the same active space 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.