Por qué Cursor y Claude Code reportan conexión sana y aun así no comparten memoria
Un repaso a seis sistemas de memoria persistente sobre MCP concluye que el fallo se repite: todos los clientes dicen estar conectados, pero compartir depende de la cuenta, no del transporte.

Un servidor de memoria MCP puede figurar como conectado en Cursor y en Claude Code y no compartir nada entre los dos. Es lo que se desprende de una comparación de seis sistemas de memoria persistente —incluido el del propio autor del análisis— centrada no en si prometen compartir entre editores, sino en la forma concreta en que cada uno puede dejar de hacerlo mientras todos los clientes siguen reportando una conexión sana. La idea que atraviesa el texto: que la conexión esté viva es un hecho del transporte; compartir es un hecho de la cuenta, y lo primero no dice nada de lo segundo.
Una cuenta, varios clientes
Cuando hay compartición entre editores, todo se reduce a eso: una cuenta y varios clientes apuntando al mismo backend. Así que la pregunta útil es qué paso de configuración, omitido o hecho de forma inconsistente, deja a dos clientes conectados sin nada en común, y cómo te enteras.
En Mnemoverse, el producto del autor, compartir es el comportamiento por defecto: una clave de API y todos los clientes conectados comparten. Su documentación lo resume en una línea: «la misma clave, la misma memoria, en todas las herramientas». La ruta de VS Code puede conectarse sin clave, abriendo el navegador para iniciar sesión y registrándose en el mismo sistema de cuentas. Hay dos formas de romperlo. La primera: la clave es la cuenta. Una clave creada en otra cuenta de la consola conecta perfectamente y devuelve el almacén de esa cuenta, normalmente vacío, sin ningún error. La segunda: convertir un filtro en una partición. Las lecturas van por defecto a los dominios propios sin filtrar; si un equipo escribe con un dominio por herramienta y luego filtra las lecturas por ese mismo dominio, se ha construido su propia partición. El arreglo es dejar de filtrar.
Cognee documenta sus trampas él mismo. Su servidor MCP tiene dos modos de arquitectura que determinan si hay compartición, y no hay que confundirlos con las opciones de instalación. En modo Standalone cada instancia mantiene sus propios datos. En modo API se conecta a un backend centralizado y varias instancias comparten el mismo grafo de conocimiento. No es un fallo, es deliberado. En el modo compartido queda otra trampa: cada instancia se autentica con un único token, así que todo lo que escribe pertenece a un solo usuario de Cognee. La solución que propone es un proceso MCP por inquilino, cada uno con el token de su propio usuario.
En Mem0 el alcance lo fija el identificador que pasas: las memorias se agrupan por userId y valores distintos crean espacios separados. Cada plugin trae su propio identificador por defecto, de modo que dos herramientas sin tocar nada acaban en dos almacenes que no se fusionan. El remedio es fijar un user_id propio que valga para todos los clientes.
Supermemory usa OAuth y navegador, sin clave de API, así que no hay clave que equivocar. El paso de configuración es otro: cada cliente elige a qué espacios puede acceder y, si la petición no nombra ninguno, se usa el espacio activo o el de la cuenta. Dos clientes autorizados a espacios distintos comparten cero. En los plugins de programación la referencia es una etiqueta de repositorio: Cursor comparte una con los plugins de Claude Code, OpenAI Codex y OpenCode, construida a partir del repositorio y un hash de su remoto de Git. Un repositorio sin remoto cae a su ruta local, así que la misma copia con remoto y sin él llevan etiquetas distintas.
Al final, ninguno de estos fallos levanta un error. Por eso la comprobación que sirve no es si el cliente está conectado, sino si lo está como la misma cuenta, con el mismo identificador o en el mismo espacio. La comparación la firma el responsable de uno de los productos analizados, así que lo que dice de Mnemoverse es suyo, no de un tercero.


