Por que Cursor e Claude Code dizem estar conectados ao meu servidor de memória e ainda assim não compartilham nada?

Você escreve uma decisão no Cursor às quatro da tarde: o serviço de pagamentos mantém sua própria tabela de tentativas, não a inclua na fila. Às seis, você abre o Claude Code no mesmo repositório. O servidor de memória está conectado em ambos os editores, e o agente propõe incluir a tabela de tentativas na fila. Você lê a memória de volta do Cursor e a nota está lá. Você lê de volta do Claude Code e o armazenamento está vazio. Nada levantou um erro, e nada está quebrado.

Compartilhar memória entre editores via MCP é um mecanismo simples, e o problema reside na etapa de configuração ao redor disso. Eu verifiquei seis sistemas de memória persistente, incluindo aquele em que trabalho, para uma coisa: não se eles afirmam compartilhar entre IDEs, mas a maneira concreta como cada um pode parar de compartilhar enquanto cada cliente ainda relata uma conexão saudável.

Uma linha para levar adiante: uma conexão saudável é um fato sobre o transporte, compartilhar é um fato sobre a conta, e o primeiro não lhe diz nada sobre o segundo.

O mecanismo, onde quer que exista

Onde o compartilhamento entre editores existe nesta comparação, reduz-se a uma frase: uma conta, vários aplicativos clientes, todos apontando para o mesmo backend. A questão interessante nunca foi como a sincronização funciona. É qual etapa de configuração, se pulada ou feita de forma inconsistente, deixa dois clientes que se conectam sem compartilhar nada, e como você perceberia isso.

Mnemoverse, nosso: compartilhar é o padrão, e duas maneiras de derrotá-lo

Começarei com o que trabalho, porque seu modo de falha é o que abriu este artigo. O Mnemoverse remove a etapa de configuração que a maioria dos fornecedores deixa: uma chave de API, e cada cliente conectado já compartilha, por padrão, em vez de como um modo a ser descoberto. O guia dos editores diz isso em uma linha: "mesma chave, mesma memória, cada ferramenta". O caminho do VS Code também pode se conectar sem uma chave: ele abre seu navegador para fazer login, se registra e aterrissa no mesmo sistema de conta que cada cliente baseado em chave usa.

A primeira maneira de derrotar isso é que a chave é a conta. Uma chave criada em uma conta de console diferente se conecta perfeitamente e retorna o armazenamento daquela conta, tipicamente vazio, sem erro algum. O caminho sem chave tem a mesma forma, porque faz login na conta que o navegador possui. Portanto, a verificação não é se cada cliente está conectado, mas se cada um está conectado como a mesma conta.

A segunda maneira é um filtro que você pode transformar em uma partição. As leituras padrão são para seus próprios domínios, não filtradas. Se uma equipe escreve com um domínio separado por ferramenta e depois filtra as leituras por esse mesmo domínio, ela construiu sua própria partição. Não é uma limitação do produto, algo que um usuário pode fazer a si mesmo, e a solução é parar de filtrar.

Cognee: dois modos, e uma pegadinha no compartilhado

Cognee nomeia suas armadilhas, em suas próprias páginas de documentação, e a primeira é fácil de confundir com uma segunda lista na mesma página. Seu servidor MCP tem dois modos de arquitetura que determinam o compartilhamento, não devem ser confundidos com as opções de configuração que a página lista para fazê-lo funcionar. Nas palavras do fornecedor: "O servidor MCP gerencia seu próprio banco de dados e processamento. Cada instância MCP mantém dados separados." Esse é o Modo Autônomo. E: "O servidor MCP se conecta a um backend centralizado da Cognee via API. Múltiplas instâncias MCP podem compartilhar o mesmo gráfico de conhecimento." Esse é o Modo API.

Não é um bug: está documentado e é deliberado, o desenvolvimento pessoal é mantido separado do compartilhamento em equipe. O compartilhamento em equipe tem sua própria pegadinha, e a Cognee nomeia essa também: "Cada instância se autentica com um único token, então tudo o que escreve pertence a um único usuário Cognee". Sua solução é um processo por inquilino: "Para separar inquilinos, execute um processo MCP por inquilino, cada um iniciado com um token para seu próprio usuário de backend, então o sistema de permissões aplica a fronteira." Instale os padrões por cliente, esperando que a memória o siga de um editor para o próximo, e você obtém os gráficos isolados do Modo Autônomo, um por cliente.

Mem0: escopado pelo identificador que você passa

Mem0 documenta o compartilhamento entre ferramentas explicitamente, um endpoint MCP hospedado com vários clientes em uma URL. É igualmente explícito sobre o mecanismo, embora o explique em suas páginas de plugin em vez de na página do endpoint: "Todas as memórias são escopadas para este userId: valores diferentes criam namespaces de memória separados." Cada plugin nomeia seu próprio identificador padrão, então duas ferramentas deixadas em seus padrões podem cair em duas pools que nunca se fundem. As mesmas páginas nomeiam a cura, um identificador que você define: "Defina um user_id e ele se aplica a cada gateway, então uma pessoa obtém um único armazenamento de memória mesclado, não importa onde converse com o agente."

Supermemory: espaços no MCP, uma tag de repositório nos plugins

Supermemory afirma a reivindicação claramente em sua visão geral do MCP: "Supermemory MCP dá a cada assistente compatível com MCP uma camada de memória compartilhada". No caminho do MCP, o mecanismo é uma conta acessada por login no navegador, e a mesma página diz isso: "Depois de se conectar, seu cliente abre o Supermemory em um navegador. Faça login ou crie uma conta, então escolha quais espaços o cliente pode acessar. Supermemory usa OAuth, então nenhuma chave de API é necessária." Não há chave compartilhada para errar. O que a frase contém é a etapa de configuração: cada cliente escolhe os espaços que pode acessar, e a menos que você nomeie um espaço em uma solicitação, "Supermemory usa seu espaço ativo ou padrão da conta". Dois clientes autorizados a espaços diferentes, ou com espaços ativos diferentes, se conectam e não compartilham nada, e a página apresenta isso como o design para manter trabalhos não relacionados separados, o que é.

Os plugins de codificação se concentram em algo diferente, e o fornecedor declara isso como um recurso: "Cursor compartilha uma tag de repositório com o Claude Code, OpenAI Codex e plugins OpenCode, então agentes trabalhando no mesmo repositório leem e escrevem a mesma memória". A tag é construída a partir do repositório e um hash de seu remoto Git, e um repositório sem remoto recai em seu caminho local, então uma cópia do mesmo código com um remoto e uma cópia sem um carregam tags diferentes. Na API do desenvolvedor, a tag do contêiner é a própria fronteira, nas palavras do fornecedor "uma fronteira de autorização, não apenas uma organizacional".

Letta, Graphiti e Zep: o que as páginas dizem e onde param

Letta responde pelos clientes que nomeia. Seu adaptador para o Protocolo de Cliente Agente coloca um agente, memória incluída, dentro de editores que suportam ACP, e a página os nomeia: "Os seguintes exemplos cobrem Zed, IDEs JetBrains e Obsidian; outros clientes ACP usam o mesmo adaptador e variáveis de ambiente." Dois editores compartilham quando ambos apontam para o mesmo agente, e a mesma página diz como você chega lá: defina o ID do agente em cada cliente para reutilizar um agente existente, ou deixe-o de fora e o adaptador cria um agente na primeira utilização. Deixe-o de fora em dois editores e você tem dois agentes, que é a versão Letta da mesma divisão.

Graphiti, a parte de código aberto do Zep, tem seu próprio servidor MCP, e o fornecedor o chama de implementação experimental. Sua página nomeia três clientes: "Isso permite que assistentes de IA como Claude Desktop, Cursor e VS Code com Copilot interajam com Graphiti". O que nenhuma página que li afirma é o que acontece quando dois deles estão conectados ao mesmo tempo. A isolação é por ID de grupo, e o guia de namespacing deixa consultas entre namespaces para seu aplicativo.

O produto hospedado do Zep documenta o compartilhamento diretamente, em uma frase que vale a pena citar inteira: "Um agente interno do usuário e seu cliente MCP pessoal compartilham um gráfico de usuário, então o contexto escrito por um está disponível para o outro." Suas próprias páginas nomeiam as pegadinhas: "O projeto selecionado é fixo no token assinado.", o servidor "Usa assentos MCP por conta; contagens de assentos variam por plano", o login passa por um provedor de identidade de workspace ou empresarial, e "Uma conexão permite gravações por padrão; um administrador pode mudar".