MCP servers that share state across IDEs: one mechanism, six ways it quietly stops
Does the memory follow you when you switch editors? Write something in Cursor, open Claude Code an hour later, and for most persistent memory MCP servers the honest answer is: it depends on a setup step you probably did not know mattered. This article checks six vendors, including our own, Mnemoverse, not for whether they claim cross-IDE sharing, but for the specific way each one can stop sharing while every connected client still reports a healthy connection.
This is the written half of a video, What MCP servers allow sharing state across multiple IDEs?, and the sections below cover its eight chapters, so anyone arriving from the end card can pick up where they stopped.
Correction, 18 September 2026: a second check against each vendor's own pages changed several answers here. Letta is more than an MCP client: its adapter for the Agent Client Protocol puts one agent and its memory inside Zed, JetBrains IDEs and Obsidian. Graphiti's MCP server names three clients, Zep fixes each client's project in its signed token, Mem0's changelog puts five editors on one memory bank, and Supermemory's changelog made every plugin free on 15 August, so this page's 11 September reading of its pricing was wrong. The claim that no vendor does anything more sophisticated than one account and one backend is withdrawn, as are two rankings; Cognee's defaults are now given in its own words, and the Supermemory and Mnemoverse quotations match their current pages. On 4 September this page had already stopped calling Zep's hosted product the one claim with no caveat, and stopped describing Supermemory's MCP install as a shared key.
Further correction, 19 September 2026: two Supermemory pages changed within a day of that check. The product-copy sentence quoted below is no longer on its live page and is cited from a capture of 9 September. Late on 18 September the vendor corrected its billing table, which had disagreed with its changelog for a month; the paragraph below dates both states.
TL;DR
- The mechanism is identical everywhere. One account, several client apps, one backend.
- The failure mode is what differs. A key from the wrong account or a domain filter on Mnemoverse; mismatched IDs across Mem0 integrations; Cognee left in Standalone Mode instead of API Mode; on Supermemory, a different space on its OAuth-only MCP install, a different repository tag across the five coding plugins its Cursor page names, or inconsistent container tags on its developer API; clients signed in to different Zep projects; ACP clients without the same Letta agent ID; and for Graphiti, no cited page that says what happens with two clients connected at once.
- The connected indicator never catches any of these. Every failure in the bullet above happens with every client reporting a healthy connection, which is why the check at the end is a data check, not a status check.
- Disclosure: Mnemoverse is one of the six vendors compared, built by this site's publisher. Every fact here, ours included, comes from a page the vendor published, fetched the week this article was checked, except two statements cited from archived captures and linked as such.
Published by Mnemoverse, a persistent-memory API for AI agents. To try it with your own agent: free key.
The mechanism is the same everywhere
Strip the marketing off any of these products and cross-IDE sharing reduces to one sentence: one account, several client applications, all pointed at the same backend. The interesting question was never how the syncing works, because the answer is always the same. The interesting question is which setup step, if skipped or done inconsistently, leaves two clients that both report a healthy connection without sharing anything, and how you would ever notice.
Mnemoverse: sharing is the default, and the two ways to defeat it
Mnemoverse removes the setup step most vendors leave in. One API key, and every connected client already shares, by default rather than as a sharing mode to discover: "If you already have a key from Claude Code or another editor, use the same one" (editors guide). The VS Code path can also connect without a key: on VS Code 1.102 or newer, over a remote URL with OAuth sign-in ("This is verified working on VS Code Desktop", VS Code guide), and it lands in the same account system as every key-based client.
Two ways to defeat this, named directly because they are ours.
The key is the account. A key created in a different console account connects perfectly and returns that account's store, typically empty, and none of your shared rooms, with no error anywhere: the client says connected, the memory is simply someone else's. The same holds for the keyless path, which signs into whatever account the browser holds. Cross-tool sharing is a property of the account, so the check is not whether each client is connected but whether each is connected as the same account. This is the failure mode we found on our own setup while checking this article, and the Claude Code guide's troubleshooting section now names it.
Domains are a filter you can turn into a silo. Reads default to your own domains, unfiltered. If a team adopts the convention of writing with a separate domain per tool and later filters reads by that same domain, it has built its own partition. The fix is to stop filtering, or to use the same domain in every client (agent frameworks guide).
Cognee: two modes, one word apart
Cognee names its traps itself, on its own documentation pages, and the one about modes is easy to conflate with a second list on the same page. Its MCP server has two Architecture Modes, which Cognee assigns by need, isolated or shared, not to be confused with the three Setup Options the same page lists for how you get it running: Docker Quickstart, API Mode (Shared), Local Setup.
The two architecture modes, verbatim from docs.cognee.ai/cognee-mcp/mcp-overview: "Standalone Mode: The MCP server manages its own database and processing. Each MCP instance maintains separate data." And: "API Mode: The MCP server connects to a centralized Cognee backend via API. Multiple MCP instances can share the same knowledge graph."
This is a documented, deliberate design, personal development kept separate from team sharing, not a defect. With stdio, which Cognee's local setup page calls the "Default mode for most MCP clients", each client starts its own server as a subprocess, standalone unless it is given the URL of a running Cognee backend, and the same page warns that "several MCP server processes sharing one SYSTEM_ROOT_DIRECTORY", for example separate editor windows, "contend for the same graph file. Neo4j is the recommended upgrade path for that setup." For one graph across clients, the quickstart says "To connect multiple clients to a shared knowledge graph, run MCP in API mode pointing to a centralized Cognee backend". Team sharing has its own catch, which Cognee names with its fix: everything one instance writes belongs to one Cognee user, "any client connected to the process can name any dataset", and the answer is to "run one MCP process per tenant".
Mem0: scoped by you, not by them
Mem0 documents cross-tool sharing explicitly: a hosted MCP endpoint, several clients on one URL, and, in its changelog, a shared editor plugin for Claude Code, Cursor, Codex, Antigravity and Kimi Code "running on the same scripts, skills, and memory bank, so context written in one editor is available in the others". The scoping is equally explicit, in the vendor's own words, once more than one participant writes into the same memory: "You control which speaker a memory belongs to by scoping each add() call with user_id, agent_id, and run_id; Mem0 does not infer that scope automatically from the conversation" (group chat docs). For one person with several tools, the plugin pages carry it: memories are scoped to the identifier you pass, and "different values create separate memory namespaces" (OpenClaw plugin). Three plugin pages name three different defaults, local account name for Claude Code, $MEM0_USER_ID or "default" for Pi Agent and hermes-user for Hermes, so the fix is one user id you set yourself: the Claude Code page says "Set explicitly to share memories across machines.", and the Hermes page says "it applies to every gateway" and files the symptom under "Memories not appearing".
Supermemory: OAuth and spaces on MCP, tags in the plugins and on the API
Supermemory stated the claim in its own product copy: "The personal supermemory: one memory across every AI you use, so what you teach one, the others remember" (supermemory.ai/product, captured 9 September 2026); on 19 September the sentence was no longer on the live page. On the MCP path the mechanism is one account reached by browser sign-in, and its MCP docs say so in as many words: "Sign in or create an account, then choose which spaces the client can access.", and "Supermemory uses OAuth, so no API key is required." There is no shared key to get wrong; what has to match is the account and the space each client may use, which its who_am_i tool reports and its memory tools take as a containerTag.
The tag matters on the other two surfaces too, and there it is strict. On the developer API, the vendor's own docs call it "an authorization boundary, not just an organizational one" and state that a memory under one tag lives "completely separate" from memories under another unless you explicitly query across both (container tags). In the coding plugins, its Cursor plugin page makes the tag the thing editors share: "Cursor shares one repository tag with the Claude Code, Muse Code, OpenAI Codex, and OpenCode plugins, so agents working on the same repo read and write the same memory". Its Codex and OpenCode pages document a tag prefix of their own, and the Cursor, Claude Code, Muse Code, Codex and OpenCode pages each let you set the tag explicitly. So the split here belongs to inconsistent tags, in code you write against the API or across plugins, not to two clients on the same MCP account and space. On plan access, its changelog entry of 15 August says "No Supermemory plugin sits behind a paid plan any more." The feature table in its billing docs lagged that entry by a month: an archived capture of 15 August shows plugins as not included on Free, and the vendor corrected the table on 18 September (the commit). Read live on 19 September, the table marks coding plugins Yes on every plan, and the page states beneath it: "Coding plugins are available on every plan, including Free." So for the plugins, what Free limits is metered rather than gated: usage draws on the plan's credits, and the pricing page answers "What happens when I run out?" with "Usage requires an available credit balance."
Letta, Graphiti and Zep: what the pages say and where they stop
Letta answers for the clients it names. Its MCP tools guide describes Letta as a client: agents register remote MCP servers and attach those tools, so "MCP tools execute on external MCP servers". Beyond that, its docs 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.", and its adapter for the Agent Client Protocol puts one agent, memory included, inside editors with ACP support: "The following examples cover Zed, JetBrains IDEs, and Obsidian; other ACP clients use the same adapter and environment variables." All three examples set the backend to cloud-oauth, where the page says the agent and its memory stay on the Letta Platform, and its App Server adds an OpenAI-compatible endpoint for clients such as Open WebUI. Its FAQ names the catch: "Repeated errors can mean that multiple clients or letta server processes are sending turns to the same conversation." On the Letta pages cited here, Claude Code appears for porting skills and importing its history (subagents), and Cursor is never named as a client.
Graphiti, the open-source half of Zep, has its own MCP server, which its page calls "an experimental implementation", and that page names three clients, each with its own transport: "This enables AI assistants like Claude Desktop, Cursor, and VS Code with Copilot to interact with Graphiti’s Context Graph capabilities". What no page cited here states is what happens when two of them are connected at once. Isolation is by group id, and cross-namespace queries are left to your application (namespacing).
Zep's hosted product states cross-client sharing directly: one URL serves every MCP client, and "Each connected user can always read their own user graph." Its own Memory MCP Server pages also name the catches: "The selected project is fixed in the signed token." (connecting a client); it uses "per-account MCP seats; seat counts vary by plan", and "When seats are exhausted, new users cannot connect (403)" (authentication); the user "signs in through Google Workspace or your enterprise identity provider" with "Custom OIDC requires the Enterprise plan"; an administrator manages rollout; and a connection "allows writes by default; an administrator can switch it to read-only". In Cursor, its plug-in, which bundles the server with the Zep Memory Skill, "Requires a Cursor plan with team marketplace support.", and in any client, "Without the Zep Memory Skill, the client has Zep Memory MCP Server tools but not the workflow that uses those tools well." (use Zep in Claude, ChatGPT and Cursor). None of that contradicts the sharing claim. It does mean every client has to sign in to the same project, and the rest of the gate is organisational rather than technical.
The table
Six vendors, seven rows: Zep's hosted product and its open-source half behave differently enough to be read separately.
| claims cross-IDE sharing | the concrete way it can fail to share | |
|---|---|---|
| Mnemoverse | yes, default behavior | a key issued to a different account (connects, typically empty, no error); or a separate domain per tool with reads filtered by it |
| Mem0 | yes, hosted MCP and a shared editor plugin on one memory bank | user_id, agent_id, run_id scoped inconsistently across integrations; Claude Code, Pi Agent and Hermes default to different user ids |
| Cognee | yes, mode-dependent | Standalone Mode left in place per client instead of API Mode |
| Supermemory | yes, explicit | on MCP, a different account or space (one OAuth account, no key); across the five plugins its Cursor page names, a different repository tag; on the developer API, inconsistent container tags |
| Zep (hosted) | yes, explicit | clients signed in to different projects (the project is fixed in the signed token); plan-dependent MCP seats, IdP sign-in and admin rollout; a connection an admin can set read-only |
| Graphiti (self-hosted) | its MCP server names Claude Desktop, Cursor and VS Code with Copilot as clients | no stated failure mode: no cited page says what happens with two clients connected at once |
| Letta | yes, across its own apps when signed in, and through its ACP adapter in Zed, JetBrains IDEs and Obsidian | ACP clients without the same agent ID (the adapter creates a new agent on first use); or several clients sending turns to one conversation |
Check your own setup
Same account, and the same key or the same browser sign-in, across every client, checked with data rather than with a green checkmark: write a marker from one tool and read it back from the other. For Mnemoverse: confirm every client is on the same account, then confirm no per-tool domain filter unless you added one deliberately. For Mem0: its changelog says the editors its shared plugin covers use one memory bank; across machines, as the Claude Code page says, or once any other integration joins, the same user id, set by you in every integration, because Claude Code, Pi Agent and Hermes do not default to the same one. For Cognee: API Mode, not Standalone, the moment more than one client needs the same graph. For Supermemory: on the MCP connector, the same account and the same space in every client, which its who_am_i tool reports; in the Cursor, Claude Code, Muse Code, Codex and OpenCode plugins, the same repository tag in each; if you built on the developer API, the same container tag everywhere. For Letta: the same agent ID in every ACP client, since without it the adapter creates a new agent on first use. For Zep: every client signed in to the same project, since the signed token pins the project chosen at sign-in.
Related
- Best Persistent Memory APIs Compared: the same six vendors on price, licence and self-hosting
- Cross-IDE context platforms for engineering teams: the team catalog built on this mechanism, with who writes the store, who sees what, and from which plan
- Claude Code guide: troubleshooting for the failure this article opens with
- Editors guide: the setup this article assumes
- Best AI agent memory in 2026: our own roundup of the same field, written to sell, so read it against this page rather than instead of it
Every vendor page this article cites was read live between 13 and 19 September 2026 with full browser headers; the two archived captures are linked as captures. Mnemoverse's own facts come from its editors guide, VS Code guide, Claude Code guide and agent frameworks guide. No performance or benchmark number appears in this article, for any system.
Mnemoverse is a persistent-memory API for AI agents. Free key: console.mnemoverse.com · Plans and limits · Docs: Getting Started