Toda conversa sobre o Claude Code esquecer tudo termina nas mesmas respostas: Obsidian, algum servidor MCP de memória ou um CLAUDE.md de duas mil linhas. Saber como criar memória persistente para Claude Code sem complicar a infraestrutura ficou mais fácil com um relato publicado nesta semana em comunidades como r/ClaudeCode e r/BuildWithClaude. O autor diz ter testado as três opções e ficado com algo mais simples, que, segundo ele, sobreviveu a três máquinas e a alguns meses de uso diário. Os detalhes abaixo vêm dos posts dele; não testamos a estrutura.
O que foi relatado
- A memória é feita de três repositórios Git com arquivos Markdown e cinco hooks.
- Não usa Obsidian nem banco vetorial.
- A ideia em uma linha, nas palavras do autor: separar como eu trabalho de o que aconteceu, manter os dois no Git, fazer o Claude ler a fatia certa no início da sessão e escrever de volta no fim.
- O primeiro repositório guarda regras e preferências de trabalho. Os posts resumidos que consultamos não detalham o conteúdo dos demais, por isso não descrevemos o que não está nas fontes.
- Outro post na comunidade r/ClaudeWorkflows descreve uma variação com Obsidian e Git, com skills, regras datadas, quadros de tarefas e hooks personalizados.
O princípio: separar regra de histórico
A parte mais reaproveitável do relato não é a ferramenta, e sim a separação. Regras de trabalho mudam pouco: padrão de código, como você quer os commits, o que o agente nunca deve fazer. Histórico muda o tempo todo: decisões de um projeto, bugs resolvidos, próximos passos. Quando os dois ficam no mesmo arquivo gigante, o agente carrega ruído em toda sessão e você perde o controle do que é válido hoje. Separar permite carregar as regras sempre e o histórico só do projeto em andamento.
Como criar memória persistente para Claude Code: 6 passos
- Crie um repositório de regras. Um arquivo curto por tema (código, testes, segurança, comunicação). Mantenha o CLAUDE.md como índice enxuto que aponta para eles.
- Crie um repositório de histórico por contexto. Uma pasta por projeto, com decisões, pendências e aprendizados em Markdown, sempre com data.
- Leia no início da sessão. Use um hook para carregar as regras e o resumo do projeto atual, e não o histórico inteiro.
- Grave no fim da sessão. Outro hook (ou um passo combinado) pede ao Claude um resumo curto do que mudou e do que ficou pendente, e salva no arquivo do projeto.
- Versione tudo no Git. Cada alteração de memória vira um commit: dá para revisar, reverter e sincronizar entre máquinas.
- Revise periodicamente. Apague o que ficou obsoleto e promova aprendizados recorrentes do histórico para as regras.
Comparação: as abordagens mais comuns
| Abordagem | Vantagem | Ponto de atenção |
|---|---|---|
| CLAUDE.md muito grande | Simples de começar | Consome contexto em toda sessão e mistura regra com histórico |
| Obsidian como memória | Boa navegação e edição humana | Mais uma ferramenta para manter e sincronizar |
| Servidor MCP de memória | Recuperação automática | Infraestrutura extra e menos transparência sobre o que foi guardado |
| Markdown + Git + hooks | Transparente, auditável e portátil | Exige disciplina de revisão e boa estrutura de pastas |
Para equipes: o que muda
Para uma pessoa só, repositórios pessoais bastam. Em uma empresa, entram perguntas novas: quais regras são do time e quais são individuais, quem aprova mudanças na memória compartilhada e o que nunca pode ser gravado. Uma divisão simples é um repositório de regras do time (revisado como código), e um histórico por projeto, com acesso limitado a quem trabalha nele. Isso se conecta ao que já tratamos em como controlar permissões de agentes de programação.
Limites e cuidados
- O relato é de um único desenvolvedor, sem avaliação independente que tenhamos verificado. Trate como ponto de partida, não como padrão.
- Não grave senhas, chaves de API nem dados pessoais nos arquivos de memória. Use repositórios privados.
- Revise o que o agente escreve: uma memória com informação errada será repetida em sessões futuras.
- Memória demais também atrapalha. Carregue só o necessário para a tarefa, o que ajuda inclusive a reduzir o consumo de tokens.
O que fazer agora
- Liste o que o seu agente repete toda sessão: são candidatos a regra.
- Separe, mesmo que em duas pastas, regras de histórico de projeto.
- Comece com um projeto piloto e um hook de leitura; só depois automatize a gravação.
- Continue a leitura: como usar Claude Code para desenvolver software com IA, como criar memória para agentes de IA, memória persistente sem embeddings e base de conhecimento para IA com Markdown.
Quer ver onde a IA gera retorno na sua operação? No diagnóstico gratuito, mapeamos seus processos e indicamos o que automatizar primeiro.
Quero meu diagnóstico gratuito →Conclusão
Memória persistente não precisa de ferramenta complexa nem de prompt enorme: precisa de estrutura, de um fluxo claro de leitura e escrita e de regras de acesso. A Yggra ajuda empresas e profissionais a desenhar essa estrutura, os fluxos de atualização e as permissões para equipes. Conheça nosso serviço de agentes de IA e de software sob medida, ou fale com a Yggra.
Fontes
- r/BuildWithClaude, my claude code memory is 3 git repos of markdown and 5 hooks. no obsidian, no vector db. here's the structure, copy it.
- r/ClaudeCode, my claude code memory is 3 git repos of markdown and 5 hooks.
- r/ClaudeWorkflows, [Workflow] Obsidian & Git-Backed Claude Code Workflow.
Perguntas frequentes
Como criar memória persistente para Claude Code?
Separe o que é regra de trabalho (como você prefere trabalhar) do que é histórico (o que aconteceu em cada projeto), guarde os dois como arquivos Markdown em repositórios Git e configure hooks para que o Claude leia a parte relevante no início da sessão e grave o aprendizado no fim.
Preciso de Obsidian ou banco vetorial para dar memória ao Claude Code?
Não necessariamente. Um desenvolvedor relatou em comunidades no Reddit que Obsidian, MCPs de memória e um CLAUDE.md enorme não foram o que funcionou para ele; ele passou a usar três repositórios Git de Markdown e cinco hooks. É um relato individual, e vale testar no seu contexto.
Um CLAUDE.md grande resolve o problema de memória?
Costuma piorar: o arquivo é lido por inteiro, consome contexto e mistura regras estáveis com histórico que muda. É melhor manter as regras enxutas e carregar o histórico por projeto, só quando necessário.
Quais cuidados de segurança tomar com a memória de IA?
Nunca grave senhas, chaves ou dados pessoais nos arquivos, use repositórios privados, revise o que o agente escreve antes de aceitar no histórico e defina quem pode ler e alterar cada repositório.
