O Claude Code apaga o histórico após 30 dias: como o guardar

Para obter ajuda sobre como utilizar o serviço, consulte a documentação da Ailoot.

O Claude Code apaga mesmo o histórico das sessões?#

Abre o Claude Code para voltar a uma sessão de há dois meses — e ela desapareceu. O ficheiro foi completamente apagado do disco. Não se trata de uma falha nem de um erro raro: é assim que funciona o mecanismo de limpeza predefinido.

Uma definição controla a limpeza: cleanupPeriodDays. O valor predefinido é 30. Sempre que o Claude Code é iniciado, analisa a pasta do histórico e apaga tudo o que for anterior a esse período. Eu nem sequer tinha esta definição no meu ~/.claude/settings.json, o que significava que estava em vigor o valor predefinido e que algumas das minhas sessões mais antigas já tinham desaparecido.

Há vários relatórios de erros sobre o assunto abertos no repositório da Anthropic e nenhum foi corrigido.

Onde guarda o Claude Code o histórico das sessões?#

É fácil encontrar o histórico. Abra um terminal e consulte o conteúdo da pasta:

ls ~/.claude/projects/

Cada subpasta corresponde a um projeto diferente. O nome codifica o caminho: por exemplo, um projeto em /Users/alex/dev/shop fica na pasta -Users-alex-dev-shop. No seu interior encontram-se os ficheiros das sessões:

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← uma sessão = um ficheiro
# a91b7d40-....jsonl

Cada ficheiro .jsonl é um registo linha a linha: cada linha corresponde a um evento da sessão. Contém mais do que o texto da conversa. Guarda a lógica por detrás das suas decisões: por que razão escolheu uma determinada estrutura de base de dados, que opções rejeitou, onde o Claude se enganou e como corrigiu o erro.

Na prática, é um diário de desenvolvimento do projeto. É por isso que a sua perda custa tanto: não perde um «chat», mas o contexto que foi acumulando ao longo de semanas. Expliquei como este contexto está estruturado no guia «Claude Memory vs. CLAUDE.md».

Porque é que a Anthropic apaga as transcrições após 30 dias?#

A eliminação tem uma justificação, e vale a pena compreendê-la antes de a desativar por completo. Uma transcrição é texto simples. Se o Claude leu um ficheiro .env durante uma sessão, inseriu uma chave num comando ou se colou uma palavra-passe num pedido, tudo isso ficou no .jsonl em texto simples. Quanto mais tempo esse ficheiro permanecer no disco, maior será a probabilidade de um dia haver uma fuga de dados.

A Anthropic é explícita: as transcrições podem conter código-fonte, credenciais e outros materiais sensíveis, e mantê-las no disco durante mais tempo do que o necessário cria um risco real para a privacidade. O período de 30 dias foi escolhido como compromisso.

As objeções da comunidade dizem respeito a três aspetos: a eliminação é silenciosa (não há aviso durante a configuração nem no arranque), não há consentimento (não lhe perguntam) e não há recuperação (não é utilizada a reciclagem e não existe uma opção para reverter a eliminação). Na issue #59248, os programadores pedem uma coisa: tornar a limpeza justa — com um aviso, um período de recuperação e um período predefinido menos agressivo.

Porque é que um script de cópia de segurança pode desencadear a eliminação?#

Esta é a parte mais complicada e apanha de surpresa quem tenta proteger os próprios dados. A limpeza consulta o mtime, o carimbo da última modificação do ficheiro. Parte do princípio de que o mtime indica quando trabalhou pela última vez na sessão. Na prática, qualquer coisa pode alterar o mtime: um cliente de sincronização do Dropbox ou iCloud, o rsync, um antivírus, um indexador ou o seu próprio script de cópia de segurança.

Eis a armadilha. Decide guardar o histórico e configura a sincronização na nuvem para ~/.claude/projects/. A dada altura, o serviço de sincronização reescreve um ficheiro e define o respetivo mtime para uma data anterior (isto pode acontecer ao restaurar uma cópia da nuvem). O Claude Code encontra um ficheiro «antigo» no arranque e apaga-o. Queria guardá-lo, mas acelerou a sua eliminação.

A conclusão é uma só: a cópia de segurança tem de ficar fora de ~/.claude/projects/. A limpeza atua apenas dentro desta pasta. Uma cópia guardada fora dela fica fora do alcance da limpeza. Vou construir a solução com base neste princípio.

Como pode parar já a eliminação do histórico?#

Pare a eliminação em três passos:

1. Abra o ficheiro de definições: ~/.claude/settings.json (se o ficheiro não existir, crie-o).
2. Adicione a definição cleanupPeriodDays com um valor elevado:

{
  "cleanupPeriodDays": 3650
}

3. Guarde o ficheiro. A definição será aplicada da próxima vez que iniciar o Claude Code.

O valor 3650 corresponde a dez anos: na prática, a eliminação deixará de ocorrer. Se quiser manter a limpeza, mas ganhar mais tempo, defina 365 (um ano); nesse caso, só desaparecerão as sessões com mais de um ano. Pode confirmar se a definição foi reconhecida com este comando:

grep cleanupPeriodDays ~/.claude/settings.json

Há uma ressalva fácil de ignorar: prolongar o período NÃO restaura o que já foi eliminado. A limpeza é executada no arranque e tudo o que foi apagado em execuções anteriores desapareceu para sempre. É por isso que deve começar por fazer esta alteração — impede perdas futuras, mas não recupera o que já foi eliminado. Se quiser evitar perder o histórico do Claude Code, bem como o seu projeto devido a um comando acidental, consulte o guia «Como configurar o Claude Code para não danificar o seu projeto».

O histórico das sessões faz parte do segundo cérebro do seu projeto: contém a lógica das decisões que não registou em mais lado nenhum. cleanupPeriodDays preserva os ficheiros, mas não os transforma num sistema que lhe permita recuperar o que precisa daqui a seis meses.

Como arquivar automaticamente o histórico fora da pasta de limpeza?#

A ideia é simples: deixe o Claude Code fazer o que quiser com a sua pasta e mantenha um arquivo separado fora dela. Está protegido desse mecanismo de limpeza, mas ainda pode perder-se por avaria do disco, eliminação acidental ou falha da cópia. Configure-o assim:

1. Crie uma pasta para o arquivo fora do diretório gerido:

mkdir -p ~/claude-history-archive

2. Copie para aí o histórico atual. A opção -a preserva a estrutura e os carimbos temporais; --ignore-existing mantém inalterados os ficheiros já copiados:

rsync -a ~/.claude/projects/ ~/claude-history-archive/

3. Automatize a execução diária. No macOS, utilize o launchd. Crie o ficheiro ~/Library/LaunchAgents/com.example.claudearchive.plist:

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.claudearchive</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/rsync</string>
    <string>-a</string>
    <string>/Users/YOUR_NAME/.claude/projects/</string>
    <string>/Users/YOUR_NAME/claude-history-archive/</string>
  </array>
  <key>StartInterval</key>
  <integer>86400</integer>
</dict>
</plist>

4. Carregue o agente para que seja executado em segundo plano:

launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist

No Linux, faz-se o mesmo com uma linha no crontab (crontab -e):

0 3 * * * rsync -a ~/.claude/projects/ ~/claude-history-archive/

Porque funciona se a sincronização da secção anterior falha? O arquivo está FORA de ~/.claude/projects/, por isso a limpeza não o consegue ver. A cópia é feita num só sentido (da pasta ativa para o arquivo) e não tocamos no mtime dos ficheiros ativos — assim, o problema do mtime não ocorre. Mesmo que o Claude Code apague uma sessão da sua própria pasta amanhã, a respetiva cópia continuará no arquivo.

Como transformar o arquivo das sessões num segundo cérebro pesquisável?#

Não basta acumular ficheiros — é preciso conseguir aceder-lhes. Dois passos transformam o arquivo numa ferramenta funcional.

Primeiro, mantenha um histórico de versões com git. Inicialize um repositório na pasta do arquivo:

cd ~/claude-history-archive
git init
git add -A && git commit -m "First snapshot of Claude Code history"

Adicione git add -A && git commit à mesma execução diária que o rsync. Passa a ter um histórico de versões: pode ver o que surgiu e quando, e desfazer uma substituição acidental com um único comando.

Segundo, pesquise. Os ficheiros .jsonl são JSON delimitado por linhas, por isso pode utilizar ferramentas conhecidas. Encontre as sessões em que foi abordado determinado tema:

grep -rl "database migration" ~/claude-history-archive/

Extraia apenas o texto dos seus pedidos de uma sessão (com jq, uma vez que se trata de JSON):

jq -r 'select(.type=="user") | .message.content' session.jsonl

A partir daqui, o histórico das sessões começa a funcionar como o segundo cérebro de um projeto: uma base de dados onde pode recuperar em segundos «como decidimos isto em março». Para uma explicação separada sobre onde fica o contexto numa sessão e como o gerir, consulte «Para onde vão os tokens no Claude Code».

É possível recuperar sessões que já foram eliminadas?#

A resposta honesta: provavelmente não. O Claude Code não tem uma funcionalidade de recuperação, uma Reciclagem nem um registo para anular a eliminação de transcrições. O ficheiro simplesmente desaparece do disco.

Há uma possibilidade: as cópias de segurança do sistema, se tiverem sido ativadas antecipadamente:

1. macOS Time Machine — se um instantâneo tiver capturado ~/.claude/projects/ antes da eliminação, pode recuperar o ficheiro a partir da cópia de segurança da data pretendida.
2. Histórico de versões do OneDrive / Dropbox — se a pasta estava sincronizada com o histórico de versões ativado, procure o ficheiro no histórico de versões da nuvem (mas lembre-se da armadilha do mtime: a sincronização também pode ter desencadeado a eliminação).
3. Cópias manuais — qualquer rsync/cp que tenha executado manualmente para um local fora da pasta gerida.

Se nenhuma destas opções existia, a sessão desapareceu. E não é um caso raro: um dos autores de um erro no repositório da Anthropic tinha 26 de 38 registos corrompidos, correspondentes a meses de trabalho. A única proteção fiável é aquela que está implementada ANTES da perda. Configure hoje cleanupPeriodDays e o arquivamento automático, enquanto ainda há algo para guardar.

Que valor deve escolher para cleanupPeriodDays?#

Há uma definição, mas pode ter vários significados. Compare as opções e escolha uma para o seu caso de utilização:

Uma ressalva de segurança importante: se definir 3650 e guardar tudo, aceita armazenar no disco transcrições que podem conter chaves e código. É uma escolha consciente entre a conveniência do arquivo e o risco. Reduza o risco: mantenha o arquivo num disco encriptado (FileVault no macOS), não o coloque numa nuvem pública e não o envie para um repositório git público. Preparei um guia separado sobre os dados que podem ser expostos através do Claude Code: «Segurança dos dados no Claude Code».

O que fazer hoje: lista de verificação#

Configure a proteção passo a passo:

1. Defina cleanupPeriodDays: 3650 em ~/.claude/settings.json — a eliminação fica interrompida.
2. Crie ~/claude-history-archive fora da pasta gerida e execute o primeiro rsync -a.
3. Agende uma execução diária com launchd (macOS) ou cron (Linux).
4. Inicialize o git no arquivo e adicione git add -A && git commit à mesma execução.
5. Confirme que o arquivo está num disco encriptado e não está sincronizado com uma nuvem pública.
6. Confirme o sucesso de cada cópia agendada, inspecione uma sessão recente arquivada e restaure periodicamente uma amostra para uma pasta temporária separada, verificando a legibilidade.
7. Se precisar de proteção contra perda do dispositivo ou disco, mantenha uma cópia de segurança independente com controlo de acesso adequado e teste também o restauro. O histórico Git no mesmo disco não é uma cópia independente.

O histórico das sessões é apenas uma camada do contexto que torna o Claude fiável.

Conheça a Ailoot.