Usuários do Claude Code relatam sumiço de conversas antigas e questionam política de retenção
Usuários do Claude Code, ambiente de programação assistida da Anthropic, têm observado o desaparecimento inesperado de históricos de chat dentro do aplicativo. De acordo com relatos registrados no repositório oficial do projeto, transcrições de conversas deixam de existir sem qualquer alerta visível, sobretudo quando passam de 30 dias de idade.
A origem do problema parece estar ligada à configuração `cleanupPeriodDays`, definida por padrão para 30 dias. Sempre que o Claude Code é iniciado, um processo interno de limpeza verifica os arquivos de transcrição salvos em formato `.jsonl` e remove aqueles que considera antigos. Na prática, isso significa que sessões inteiras de trabalho – muitas vezes usadas como diário técnico – podem ser apagadas automaticamente após esse período.
Para quem utiliza o Claude Code não apenas como assistente de geração de código, mas como registro de raciocínio técnico, essa limpeza automática tem impacto direto. Nessas transcrições, costumam ficar documentadas decisões de arquitetura, etapas de depuração, hipóteses testadas, justificativas de implementação, comparações de soluções e contexto geral de projeto. A perda desse material pode complicar auditorias técnicas, revisões posteriores, handover entre equipes e o simples ato de retomar um trabalho interrompido há algumas semanas.
A Anthropic afirma que a política de exclusão em 30 dias existe desde o lançamento do Claude Code e que ela foi concebida como uma camada adicional de segurança. Segundo a empresa, manter indefinidamente no disco local arquivos de texto contendo sessões de programação abre uma superfície de risco considerável: esses registros podem embutir trechos de código sensível, credenciais temporárias que não foram rotacionadas, chaves de API, endpoints internos, caminhos de infraestrutura, logs de erro com dados privados e detalhes de configuração que não deveriam ficar acessíveis por tempo indeterminado.
Na visão da companhia, definir 30 dias como padrão é uma tentativa de equilibrar conveniência e segurança: seria tempo suficiente para retomar trabalhos recentes, sem transformar o diretório de transcrições em um repositório permanente de informações sensíveis. Sob essa ótica, a decisão faz sentido no contexto de segurança defensiva, já que muitos desenvolvedores negligenciam criptografia de disco, controle de acesso ao equipamento ou boas práticas de descarte seguro de dados.
O atrito com a base de usuários, porém, não está exatamente na existência de um limite de retenção, mas na forma como ele é comunicado e implementado. Relatos indicam que, durante a instalação, na primeira execução do aplicativo e mesmo no uso cotidiano, não há um aviso claro informando que conversas com mais de 30 dias serão removidas automaticamente. Nem todos percebem que há uma opção configurável relacionada a esse comportamento, ou entendem desde o início que o histórico não é persistente por padrão.
Um dos usuários relata que a limpeza começa a atuar “do jeito que vem de fábrica”, sem qualquer destaque na interface ou passo de onboarding apontando para o mecanismo de expiração. Isso leva parte das pessoas a crer que o histórico é duradouro, comparável a um repositório de anotações ou a um log permanente de desenvolvimento. Quando a realidade se impõe – com o sumiço de sessões antigas – o choque entre expectativa e comportamento real se traduz em frustração e, em alguns casos, perda efetiva de produtividade.
Outro relato descreve uma situação em que o código do projeto e o histórico do Git permaneceram intactos, mas todo o “fio condutor” do raciocínio desapareceu com a limpeza. Ficaram de fora discussões de design de software, justificativas de decisões, trilhas de debugging e análises comparativas que haviam sido feitas ao longo de dias ou semanas. Em atividades exploratórias, pesquisa aplicada, provas de conceito ou investigação de bugs complexos, esse contexto conversacional é tão valioso quanto o repositório em si, pois revela o porquê das escolhas, não apenas o resultado final.
A insatisfação aumenta diante da ausência de mecanismos de reversão. De acordo com as queixas, o recurso de limpeza não oferece lixeira, período de carência, confirmação antes de aplicar a exclusão, opção nativa de restauração ou um log detalhado apontando exatamente o que foi apagado. Depois do processo de limpeza, o usuário pode nem sequer saber quais conversas desapareceram, o que dificulta tanto a recuperação por meios alternativos quanto a simples auditoria do que foi perdido.
Há ainda um componente técnico adicional complicando o cenário: nem sempre aumentar o valor de retenção resolve. Alguns usuários apontam que, mesmo ajustando o `cleanupPeriodDays` para períodos mais longos, o resultado não é o esperado. Uma análise de causa raiz sugerida por um participante indica que o mecanismo de exclusão se baseia no `mtime` (tempo de modificação do arquivo), em vez da data real da última interação no chat.
Esse detalhe é relevante porque o `mtime` é facilmente alterado por vários fatores externos. Ferramentas de sincronização em nuvem, scripts de backup, restaurações de sistema ou até movimentações de arquivos entre diretórios podem modificar o horário de modificação sem que a conversa em si seja antiga. Dessa forma, uma sessão ainda relevante pode parecer “velha” para o mecanismo de limpeza. Na próxima execução do Claude Code, aquele transcript é tratado como expirado e apagado silenciosamente, sem que o usuário associe o evento a uma ação recente de manutenção ou migração de arquivos.
Até o momento, a principal estratégia apontada para mitigar o problema é manter cópias de segurança das transcrições. Várias abordagens foram sugeridas: desde backups manuais periódicos do diretório de conversas até scripts automatizados que copiam os arquivos antes da inicialização da ferramenta. Alguns optam por mover regularmente as transcrições para outro local fora do alcance do mecanismo de limpeza, criando um arquivo paralelo de sessões consideradas importantes.
Ainda assim, muitos consideram essa solução apenas um paliativo. Fazer backup é, de fato, uma boa prática básica em qualquer fluxo de trabalho que envolva dados valiosos, mas não deveria ser a única camada de proteção contra uma operação intrinsecamente destrutiva, sobretudo quando essa operação é disparada de forma automática e silenciosa. A demanda recorrente é por uma política de produto mais transparente e configurável em torno da retenção de conversas.
Entre as sugestões frequentemente associadas ao caso estão: destacar de forma clara, já na instalação e no primeiro uso, que há uma política de expiração de 30 dias; permitir que o usuário escolha o período logo no onboarding; registrar, em um log local, quais arquivos foram excluídos, com data e motivo; incluir uma confirmação quando a limpeza for disparada manualmente; e oferecer modos alternativos de funcionamento, como retenção ilimitada com aviso de risco de segurança ou exclusão apenas sob demanda.
O episódio ilustra uma tensão recorrente em ferramentas locais de IA voltadas a desenvolvimento de software. De um lado, há a necessidade de minimizar o tempo de vida de dados sensíveis em dispositivos que podem ser comprometidos por malware, acessos não autorizados, perda física ou roubo. De outro, há o valor crescente das conversas como parte integrante do processo de engenharia – um tipo de documentação viva que, na prática, complementa ou até substitui comentários no código, wikis internos e documentos formais de arquitetura.
Para equipes que trabalham em setores regulados ou lidam com propriedade intelectual altamente sensível, a postura da Anthropic encontra eco: reduzir superfície de dados é um princípio de segurança consolidado. Manter meses ou anos de conversas em texto claro em um notebook sem criptografia, por exemplo, é um risco considerável. Nesses contextos, políticas de expiração automática, aliadas a boas práticas como criptografia de disco, segmentação de ambientes e rotação de credenciais, fazem parte de uma estratégia mais ampla de proteção.
Por outro lado, ambientes de pesquisa, times pequenos ou desenvolvedores independentes tendem a aproveitar historicamente essas conversas como memória de longo prazo do projeto. Em ciclos longos de desenvolvimento, é comum revisitar discussões antigas para entender por que determinada abordagem foi descartada, quais limitações técnicas existiam em uma fase anterior ou quais experimentos já foram realizados e com quais resultados. O desaparecimento silencioso desse registro força um recomeço de linha de raciocínio e pode levar à repetição de tentativas já avaliadas no passado.
Diante desse cenário, algumas boas práticas podem ajudar quem depende do Claude Code ou de ferramentas semelhantes como suporte contínuo ao trabalho:
– Tratar conversas importantes como documentação: copiar respostas críticas, decisões e raciocínios para arquivos de documentação do projeto, em vez de confiar apenas no histórico do assistente.
– Adotar rotinas de backup estruturadas: integrar o diretório de transcrições a uma política de backup já existente, com verificações periódicas de restauração.
– Revisar configurações assim que instalar: localizar e ajustar parâmetros como `cleanupPeriodDays` de acordo com a política de dados da equipe ou da organização.
– Separar ambientes sensíveis: em projetos que envolvem dados altamente críticos, considerar o uso de máquinas dedicadas, armazenamento criptografado e períodos de retenção mais curtos, mesmo que isso exija maior disciplina na documentação manual.
O debate também toca em um ponto de experiência de usuário: operações destrutivas, mesmo quando justificadas por segurança, tendem a ser melhor aceitas quando são claramente explicadas, permitem personalização e oferecem algum tipo de trilha de auditoria. Em ferramentas de desenvolvimento assistido por IA, onde a linha entre “código” e “conversa” fica cada vez mais difusa, projetar políticas de retenção passa a ser tão importante quanto projetar a própria interface de chat.
No fim, o caso do Claude Code funciona como um alerta para todo o ecossistema de ferramentas de IA locais: conformidade com boas práticas de segurança não elimina a necessidade de comunicação transparente. Usuários que adotam esses sistemas como parte central do seu fluxo de trabalho esperam previsibilidade e controle sobre o destino das informações que produzem. Ajustar o equilíbrio entre proteção de dados e preservação de conhecimento técnico será um dos desafios centrais na evolução desses produtos.