31 arquivos. Incidentes documentados, decisões de arquitetura, runbooks de deploy, preferências pessoais, histórico de bugs. Tudo em Markdown, tudo construído ao longo de meses de trabalho real. E tudo preso em uma única máquina.
Esse era o meu problema. Eu uso o Claude Code em 4 contextos diferentes — um bot no Telegram rodando no servidor, SSH direto no terminal, e dois computadores diferentes. Cada instância começava do zero. Eu ensinava algo no servidor e, quando abria o terminal no outro computador, tinha que ensinar tudo de novo.
O problema não é a memória — é o isolamento
O Claude Code já tem um sistema de memória decente. Ele salva tudo em ~/.claude/projects/<path>/memory/ como arquivos .md com frontmatter YAML. Funciona bem. O problema é que cada máquina tem seu próprio diretório, com seus próprios arquivos, sem conexão entre eles.
No meu servidor de produção, o Claude Code sabe que o Redis escuta na porta 6379 com autenticação, que o MySQL tem usuários por aplicação, que houve incidentes de segurança em fevereiro, que o deploy do Sistema Reino usa PHP 8.4. São meses de contexto acumulado.
No meu outro computador? Ele não sabe nada disso. É um Claude Code amnésico.
A epifania: os arquivos já são uma base de conhecimento
Um dia, olhando a estrutura dos arquivos de memória, percebi algo óbvio. Arquivos .md com frontmatter YAML, organizados em pastas, com referências cruzadas entre eles. Isso já é uma base de conhecimento pronta para o Obsidian — um app gratuito pra organizar notas em Markdown, tipo um segundo cérebro digital.
Bastava abrir a pasta no Obsidian e tudo funcionava — graph view, backlinks, tags, tudo. A pasta de notas (que o Obsidian chama de "vault") já existia. Eu só não sabia.
A partir disso, a solução se montou sozinha.
Transformando memória local em repositório Git
Primeiro passo: transformar os arquivos de memória em um repositório Git.
mkdir /root/brain
cp -r ~/.claude/projects/-root/memory/* /root/brain/
cd /root/brain
git init
git add -A
git commit -m "initial: import claude code memory files"
git remote add origin git@github.com:billy/brain.git
git push -u origin main
Depois, o pulo do gato: substituir o diretório original por um symlink.
rm -rf ~/.claude/projects/-root/memory
ln -s /root/brain ~/.claude/projects/-root/memory
O Claude Code continua lendo e escrevendo nos mesmos caminhos de sempre. Ele nem percebe a diferença. Mas agora tudo está dentro de um repositório Git.
Sync automático: cron a cada 5 minutos
Um cronjob simples resolve a sincronização:
*/5 * * * * cd /root/brain && git add -A && git diff --cached --quiet || (git commit -m "auto-sync $(date +\\%F-\\%H\\%M)" && git push) 2>/dev/null
A cada 5 minutos, ele verifica se houve mudança. Se houver, commita e faz push. Sem barulho, sem notificação, sem overhead. Git sync é grátis, robusto, e todo dev já sabe usar.
Conector MCP: a base de conhecimento funciona sem interface gráfica
No servidor, não tem Obsidian instalado. É um Ubuntu headless. Mas eu queria que o Claude Code pudesse buscar, ler e escrever na base de conhecimento com ferramentas estruturadas, não só lendo arquivos brutos.
É aí que entra um conector chamado MCP (Model Context Protocol) — um protocolo que permite que a IA use ferramentas externas, como acessar arquivos, bancos de dados ou APIs. O mcpvault (@bitbonsai/mcpvault) é um servidor MCP que expõe 14 ferramentas: busca por palavras-chave, leitura, escrita, patch, manipulação de frontmatter, tags.
O Claude Code pode pesquisar "qual foi o incidente de segurança?" e encontrar o arquivo certo sem eu precisar dizer o caminho.
{
"mcpServers": {
"vault": {
"command": "npx",
"args": ["-y", "@bitbonsai/mcpvault", "/root/brain"]
}
}
}
No servidor, isso é tudo que precisa. Sem interface gráfica, sem Electron, sem 500MB de app. Só um processo Node que expõe a base de notas via protocolo MCP.
Nos computadores pessoais: Obsidian + Git plugin
Nos meus computadores pessoais, a história é diferente. Eu clono o mesmo repositório e abro no Obsidian.
git clone git@github.com:billy/brain.git ~/brain
O plugin Obsidian Git faz auto-pull e auto-push a cada 5 minutos. A mesma lógica do cron, mas integrada na interface.
O resultado visual é satisfatório. O graph view do Obsidian mostra as conexões entre os arquivos — como um incidente de segurança se relaciona com o hardening do MySQL, como o deploy do HubNews referencia as configurações do Supervisor, como as decisões de billing conectam com o gateway de pagamento.
E o Claude Code nos outros computadores? Mesmo truque: symlink do diretório de memória para o repositório clonado.
O problema dos caminhos absolutos
Tem um detalhe que quase me travou. O Claude Code indexa memória pelo caminho absoluto do projeto. No servidor, o projeto fica em /home/deploy/api.hubnews.ai/. No outro computador, fica em /Users/billy/projects/api.hubnews.ai/.
São paths diferentes, então o Claude Code trata como projetos diferentes e cria diretórios de memória separados.
A solução mais simples: um script pós-sync que copia os arquivos para os paths corretos de cada máquina. Nada elegante, mas funciona. Outra opção é manter tudo sob um único diretório de projeto genérico e usar o mcpvault como interface principal de acesso.
# post-sync.sh
rsync -a ~/brain/ ~/.claude/projects/-Users-billy/memory/
O resultado: 4 cérebros sincronizados
Agora, quando o Claude Code no servidor documenta um incidente de madrugada — em 5 minutos essa informação está disponível em todas as outras instâncias.
Quando eu tomo uma decisão no computador pessoal sobre a arquitetura de um projeto, o bot no Telegram já sabe dessa decisão na próxima interação.
31 arquivos de memória, sincronizados entre 4 máquinas, acessíveis tanto via CLI quanto via interface gráfica no Obsidian. O custo total da solução: zero. Git é gratuito. Obsidian é gratuito. O mcpvault é open source.
Bônus: busca semântica com RAG
Para quem quiser ir além, existe o caminho do RAG (Retrieval-Augmented Generation) — uma técnica que combina busca inteligente com geração de texto por IA. Em vez de busca por palavras-chave, o RAG entende o significado da sua pergunta. Você pergunta "como lidar com alta carga de CPU" e ele encontra o runbook de incidentes mesmo que o arquivo não contenha exatamente essas palavras.
O MCP server knowledge-rag implementa exatamente isso sobre os arquivos da sua base de notas. Ainda não implementei em produção, mas está na lista.
O que importa aqui
A memória do Claude Code é poderosa, mas só se for portável. Se o conhecimento morre quando você troca de máquina, ele tem metade do valor.
A beleza dessa solução é que ela usa ferramentas que todo dev já conhece — Git, Markdown, cron, symlinks. Não tem vendor lock-in, não tem SaaS intermediário, não tem mágica. É infraestrutura básica aplicada a um problema novo.
Se você usa o Claude Code em mais de uma máquina, monta isso. Leva 20 minutos. E a primeira vez que você abrir o terminal em outra máquina e o Claude Code já souber o que você fez ontem, você vai entender por que eu escrevi esse post.