# O Claude Code apaga o histórico após 30 dias: como o guardar > Onde são guardadas as sessões do Claude Code, como configurar cleanupPeriodDays e como organizar um arquivo externo com rsync, launchd ou cron. Source: https://ailoot.ai/blog/pt-pt/claude-code-history-30-days/ Canonical: https://ailoot.ai/blog/pt-pt/claude-code-history-30-days/ Language: pt-PT Publisher: Ailoot (https://ailoot.ai/) Translation: guide-056 Revision: sha256-9f9121e222de98720377a0d5a692cdb661469c4087664961d57f2001435eca1b Para obter ajuda sobre como utilizar o serviço, consulte a [documentação da Ailoot](https://ailoot.ai/docs/). ## O Claude Code apaga mesmo o histórico das sessões?
Principais conclusões Sim. Sempre que o Claude Code é iniciado, apaga os ficheiros das sessões com mais de 30 dias. A definição `cleanupPeriodDays` em `~/.claude/settings.json` é responsável por isso; o valor predefinido é `30`. A eliminação ocorre sem aviso, sem pedir consentimento e sem qualquer forma de recuperar os ficheiros.
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?
Principais conclusões O histórico de cada sessão é guardado em `~/.claude/projects//.jsonl`. O nome da pasta corresponde ao caminho absoluto do diretório de trabalho onde executou o Claude Code, com as barras substituídas por hífenes. O ficheiro `.jsonl` contém toda a conversa, uma linha de cada vez: os seus pedidos, as respostas do modelo, as chamadas de ferramentas e as edições de ficheiros. É precisamente esta memória que a limpeza apaga.
É fácil encontrar o histórico. Abra um terminal e consulte o conteúdo da pasta: ```bash 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: ```bash 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»](https://ailoot.ai/blog/pt-pt/claude-memory-claude-md-auto-memory/). ## Porque é que a Anthropic apaga as transcrições após 30 dias?
Principais conclusões A posição da Anthropic assenta na privacidade e na segurança. Os ficheiros das sessões são guardados em texto simples no disco e podem conter código-fonte, palavras-passe e chaves de API. Guardá-los para sempre representa um risco: se o portátil for roubado ou alguém obtiver acesso ao disco, terá acesso a todos esses dados sensíveis. O período de 30 dias procura equilibrar «retomar o trabalho recente» com «não manter segredos no disco durante mais tempo do que o necessário».
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?
Principais conclusões A limpeza decide o que deve apagar com base na hora de modificação do ficheiro (mtime). Não verifica a atividade mais recente da sessão. Qualquer processo que toque num ficheiro `.jsonl` — sincronização na nuvem, rsync, um editor ou um script — pode alterar o respetivo mtime, fazendo com que uma sessão recente pareça desatualizada. No arranque seguinte do Claude Code, a sessão será considerada antiga e apagada. O paradoxo: uma tentativa ingénua de fazer uma cópia de segurança do histórico dentro da pasta gerida acelera a sua perda.
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?
Principais conclusões Basta uma definição. Abra `~/.claude/settings.json` e defina `cleanupPeriodDays` com um valor elevado — por exemplo, `3650` (dez anos). Na prática, isto desativa a eliminação automática: nada será mais antigo do que o limite. Importante: esta definição protege apenas o que ainda não foi eliminado. Não é possível restaurar o histórico que a limpeza já apagou. Por isso, o primeiro passo é agir antes de perder outra sessão.
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: ```json { "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: ```bash 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»](https://ailoot.ai/blog/pt-pt/claude-code-safe-overnight-setup/). 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?
Principais conclusões Copie as sessões para um arquivo FORA de `~/.claude/projects/`, onde a limpeza não se aplica. Um simples `rsync -a` diário para um diretório separado é suficiente: os ficheiros novos são adicionados e os antigos permanecem. Como o arquivo está fora da pasta gerida, não é afetado nem por `cleanupPeriodDays` nem pelo problema do mtime. Automatize a execução com launchd (macOS) ou cron (Linux) e o seu histórico irá acumular-se por si só.
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: ```bash 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: ```bash 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 Label com.example.claudearchive ProgramArguments /usr/bin/rsync -a /Users/YOUR_NAME/.claude/projects/ /Users/YOUR_NAME/claude-history-archive/ StartInterval 86400 ``` 4. Carregue o agente para que seja executado em segundo plano: ```bash launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist ``` No Linux, faz-se o mesmo com uma linha no crontab (`crontab -e`): ```bash 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?
Principais conclusões Coloque o arquivo sob controlo de versões com git e terá uma base de dados versionada e totalmente pesquisável de todas as suas sessões. Execute `git init` na pasta do arquivo e, diariamente, `git add -A && git commit` para obter um histórico de alterações e proteção contra substituições acidentais. Pode pesquisar sessões antigas com um grep normal e extrair conteúdo estruturado com jq, uma vez que `.jsonl` é JSON delimitado por linhas. Assim, o arquivo transforma-se numa ferramenta prática.
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: ```bash 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: ```bash 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): ```bash 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»](https://ailoot.ai/blog/pt-pt/where-claude-code-tokens-go/). ## É possível recuperar sessões que já foram eliminadas?
Principais conclusões Não existe um método integrado. O Claude Code não coloca os ficheiros eliminados na Reciclagem nem mantém uma opção para reverter a eliminação; o ficheiro é apagado de vez. A única possibilidade são cópias externas feitas ANTES da eliminação: um instantâneo do Time Machine no macOS, o histórico de versões do OneDrive ou do Dropbox, ou uma cópia de segurança manual. Se não existir nenhuma destas opções, a sessão perdeu-se. É por isso que a proteção tem de ser configurada antecipadamente — antes de haver algo a perder.
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?
Principais conclusões Para a maioria das pessoas, utilize `3650` (dez anos, o que praticamente desativa a eliminação) e um arquivo automático externo. Mantenha o valor predefinido `30` apenas se não precisar do histórico e for mais importante não guardar segredos no disco. O valor `365` é um meio-termo razoável, com limpeza anual. Outra possibilidade é não guardar histórico: utilize a variável de ambiente `CLAUDE_CODE_SKIP_PROMPT_HISTORY` ou a opção `--no-session-persistence`, mas isso serve o propósito oposto.
Há uma definição, mas pode ter vários significados. Compare as opções e escolha uma para o seu caso de utilização: | Valor | O que faz | A quem se destina | |----|----|----| | `30` (predefinição) | Apaga no arranque as sessões com mais de 30 dias | Não precisa de histórico; é mais importante evitar guardar dados sensíveis no disco | | `365` | Mantém um ano de histórico e depois limpa-o uma vez por ano | Precisa de histórico recente, mas não de um arquivo permanente | | `3650` | Praticamente desativa a eliminação | Quer guardar tudo + ter um arquivo externo (recomendado) | | `CLAUDE_CODE_SKIP_PROMPT_HISTORY` | Não guarda qualquer histórico no disco | Privacidade máxima; não precisa de histórico | 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»](https://ailoot.ai/blog/pt-pt/claude-code-data-access-safety/). ## O que fazer hoje: lista de verificação
Principais conclusões Estas medidas reduzem a perda de histórico: alargue a retenção com `cleanupPeriodDays: 3650`, copie sessões para fora de `~/.claude/projects/` e mantenha versões do arquivo. Só os ficheiros copiados com sucesso ficam protegidos da limpeza do Claude Code. Uma execução diária bem-sucedida deixa até um dia de alterações recentes por arquivar; execuções falhadas ou omitidas aumentam o intervalo. Uma cópia no mesmo disco não protege contra avaria do disco.
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.
### Fontes - [Documentação do Claude Code - definições de settings.json (cleanupPeriodDays)](https://code.claude.com/docs/en/settings) - [Documentação do Claude Code - novidades](https://code.claude.com/docs/en/whats-new)
Conheça a [Ailoot](https://ailoot.ai/). ## Perguntas frequentes ### Um arquivo diário garante que nenhuma sessão se perde? Não. Protege da limpeza da pasta gerida os ficheiros copiados com sucesso. Com execuções diárias bem-sucedidas, pode faltar até um dia de alterações recentes; falhas aumentam o intervalo, e uma cópia no mesmo disco pode perder-se com o original. ### Como verifico que o arquivo é utilizável? Confirme o sucesso das cópias agendadas, inspecione uma sessão recente e restaure periodicamente uma amostra para uma pasta temporária separada. Para proteger contra perda do dispositivo ou disco, teste também uma cópia guardada independentemente do original. ## Ailoot · A empresa e a sua carteira de projetos A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI. A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões. A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.