Vale a pena versionar o vault no Git antes de deixar o Claude Code editar suas notas?

Fala aí, beleza? Soltar um agente de IA dentro de uma pasta com anos de anotação é uma decisão diferente de soltar ele num projeto de código

E muita gente esquece de um detalhe: o vault do Obsidian é só uma pasta de arquivos Markdown no seu computador, sem formato proprietário, com a pasta de configuração .obsidian ali junto dos seus .md

Ou seja: qualquer ferramenta que edita arquivo edita suas notas DE VERDADE, sem camada mágica no meio

Daí a pergunta do post: vale versionar vault no Git antes de deixar o Claude Code mexer nas suas notas?

A resposta curta é que existem três redes de proteção diferentes em jogo aqui, e elas cobrem coisas diferentes… bora destrinchar cada uma 🙂

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

O que exatamente está em risco quando o Claude Code edita seu vault

Num projeto de código, quando a IA faz besteira, alguma coisa grita: o build quebra, o teste fica vermelho, a tela não abre

No vault não tem nada gritando

Uma reescrita ruim numa nota antiga pode ficar lá, quietinha, por semanas, até o dia em que você abre pra consultar e percebe que o trecho que importava sumiu

E tem o agravante do acúmulo: vault não é sprint, é sedimento de anos. O prejuízo não é "refazer 2 horas de trabalho", é perder uma anotação que você nunca mais vai conseguir reconstruir

Que é justamente por isso que Git funciona bem aqui. Como as notas são texto puro em arquivo local, o Git enxerga cada alteração linha a linha, igual faria com código. Vault não vira código nessa história, ele vira o que sempre foi: um repositório de texto

E presta atenção na régua, porque ela é o ponto central do post: a régua NÃO é "impedir que o agente edite". Se você não quer que ele edite, é só não rodar ele ali

A régua é conseguir ver o que ele mudou e conseguir voltar atrás

Se você quer segurar o agente num passo anterior, antes de qualquer escrita, vale conhecer o modo plano do Claude Code, que é outra camada da conversa

Git, checkpoint do Claude Code e Recuperação de arquivos do Obsidian: o que cada rede cobre

Lendo a tabela de cima pra baixo, o desenho aparece sozinho: o checkpoint é curto prazo e vive DENTRO da sessão, a Recuperação de arquivos é um resgate pontual de uma nota que você percebeu na mesma semana, e o Git é o único que atravessa mês

Repara também numa diferença de comportamento: o checkpoint restaura, a Recuperação de arquivos te entrega o texto na área de transferência pra você colar de volta na nota, não restaura o arquivo automaticamente

São coisas bem distintas na hora do aperto, beleza?

Três situações em que o /rewind não te salva (e o Git salva)

Sintoma: o arquivo sumiu e o rewind não traz de volta

Causa: o checkpointing rastreia as edições feitas pelas ferramentas de edição de arquivo do Claude, e não o que passou pelo terminal

Se rolou rm, mv ou cp no bash, o /rewind não desfaz. Os rm -rf da vida seguem sendo os rm -rf da vida 😛

Sintoma: voltei o estado dos arquivos, mas o estrago já saiu de casa

Causa: efeito externo não volta atrás. Instalação feita, push pro remoto, chamada de API: tudo isso persiste depois do rewind

O rewind cuida do seu diretório, não do mundo lá fora

Sintoma: percebi a bagunça semanas depois e não tem mais nada pra restaurar

Causa: prazo. Os checkpoints são apagados junto com as sessões (30 dias por padrão) e o snapshot do Obsidian tem retenção padrão de 7 dias

Esse é o caso mais comum em vault, exatamente porque não existe teste vermelho pra te avisar no dia

Como prevenir: commit antes de abrir a sessão

É chato? é. Mas é o único movimento que transforma "descobri semanas depois" em "comparo com o commit de antes e resolvo"

E tome cuidado com um detalhe silencioso: dá pra desabilitar o checkpointing por variável de ambiente, o CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING. Se alguém deixou isso setado no seu ambiente, você acha que tem rede e não tem

Quem gosta de amarrar verificação automática em volta do agente pode olhar também os hooks antes e depois da edição, que atacam o problema por outro ângulo

Como fica a rotina com o vault versionado

A mudança prática é bem simples de descrever

Você para de aceitar alteração no escuro: dá pra abrir o diff e ler o que mudou nota por nota antes de dar o ok

Dá pra olhar o histórico de commits e saber o que entrou em cada nota e quando, o que é útil demais quando o agente reorganizou meia dúzia de arquivos de uma vez

E dá pra desfazer só UM arquivo, sem jogar fora as outras 40 alterações boas da mesma leva

Se você não quer sair do Obsidian pra isso, existe um plugin da comunidade chamado Git, o obsidian-git, listado no diretório oficial em community.obsidian.md/plugins/obsidian-git

Ele traz commit, pull, push, stage e unstage por arquivo e leitura do histórico de commits pra dentro da interface do Obsidian, além de commit-and-sync agendado e auto-pull na inicialização

Crédito de quem construiu isso: o desenvolvimento inicial é de denolehov, e o Vinzent03 é o desenvolvedor desde março de 2021, com o repositório movido pra conta dele em julho de 2024

Quando versionar o vault compensa e quando é exagero

Vault grande e antigo, com reorganização em massa. Aqui compensa MUITO. Renomear, mover, reescrever frontmatter em lote: é o cenário clássico de estrago que você só vê depois, e o histórico de commits é o que te dá o antes e o depois

Uma nota só, sessão curta. Se o pedido é pontual e você vai revisar na hora, o checkpoint da própria sessão já resolve. Esc Esc e pronto, sem cerimônia

Quem guarda anexo e arquivo que não é nota. PDF, imagem, planilha, aquele monte de coisa que mora no vault junto: a Recuperação de arquivos só cobre .md e .canvas, então esses arquivos ficam sem rede nenhuma por ali. O Git não faz essa distinção

Quem vive mudando a pasta do vault de lugar. Os snapshots da Recuperação de arquivos ficam nas configurações globais, fora do vault, e são gravados com o caminho absoluto da nota. Mudou o vault de lugar, a recuperação pode simplesmente não acontecer. O repositório Git viaja junto com a pasta

Veredito: as redes se somam, não se substituem

Minha leitura honesta é que não existe escolha entre as três, existe empilhamento

O checkpointing é a rede de curto prazo, dentro da sessão, pra quando você leu a resposta e pensou "não era isso"

A Recuperação de arquivos é o resgate de emergência de UMA nota, com aquele fluxo manual de copiar pra área de transferência e colar de volta

E o Git é a memória longa, a única das três com diff revisável e sem prazo de validade em cima

Pra quem NÃO vale: vault pequeno, uso esporádico do agente, e principalmente quem não quer lidar com conflito de merge nem com mais um ritual no meio do caminho. Nesse cenário, checkpoint ligado e Recuperação de arquivos configurada já entregam bastante

Pra quem vale claramente: vault com anos de acúmulo, sessões longas, edição em massa e anexo que não é .md

Conclusão

Se eu fosse te dar um único próximo passo, seria esse: versione ANTES da primeira sessão em que o agente vai escrever no vault, não depois

E aproveita pra fazer duas conferidas rápidas antes de começar: se o checkpointing está mesmo ativo no seu ambiente e qual retenção está configurada por aí

É pouca coisa e muda completamente o tamanho do risco de soltar um agente em cima de anos de anotação =)

Agora me conta nos comentários: qual das três redes já salvou o teu vault? 😀

até o próximo post!