Usuários do Claude Code, ambiente de programação assistida por IA da Anthropic, vêm relatando o desaparecimento repentino de conversas antigas armazenadas no aplicativo. Relatos em canais de desenvolvimento apontam que transcrições de chats estão sendo removidas automaticamente, em especial quando ultrapassam cerca de 30 dias, sem um aviso claro de que isso aconteceria.
No centro do problema está a configuração `cleanupPeriodDays`, parâmetro interno do Claude Code que define por quantos dias as conversas são mantidas no disco. O valor padrão desse campo é 30. Sempre que a ferramenta é inicializada, entra em ação um processo automático de limpeza que examina os arquivos de transcrição no formato `.jsonl` e apaga aqueles considerados “velhos demais” de acordo com essa regra.
Para boa parte dos profissionais que utilizam o Claude Code como apoio cotidiano em projetos, essa rotina de exclusão não é apenas um detalhe técnico. Muitas dessas conversas funcionam como um diário de trabalho: registram decisões de arquitetura, raciocínios de debugging, discussões sobre trade-offs, hipóteses rejeitadas e todo o contexto que levou ao código final. Quando esses registros somem, a perda não se limita a “perder o chat”, mas sim a apagar um pedaço relevante da memória técnica do projeto.
A Anthropic afirma que essa política de retenção limitada não é nova nem oculta. De acordo com a empresa, o prazo de 30 dias está presente desde o lançamento do Claude Code e faz parte de uma estratégia de segurança: manter por tempo indefinido no computador local transcrições em texto puro de sessões de programação significaria acumular dados altamente sensíveis, como código-fonte interno, credenciais acidentalmente coladas no chat, chaves de API, detalhes de infraestrutura e potenciais vulnerabilidades.
Sob a ótica da segurança, o argumento faz sentido. Históricos de interação com ferramentas de código assistido podem conter trechos de sistemas críticos, caminhos de servidores, parâmetros de configuração, logs de erro com informações internas e até tokens que, se caírem em mãos erradas, podem facilitar ataques. Reduzir o tempo de retenção local é uma forma de diminuir a superfície de exposição: se o dispositivo for comprometido, há menos dados antigos disponíveis para exploração.
A empresa explica que o período padrão de 30 dias foi pensado como um meio-termo: longo o suficiente para permitir que o usuário retome rapidamente trabalhos em andamento, mas curto o bastante para não transformar o disco rígido em um repositório permanente de dados confidenciais. Na teoria, esse equilíbrio oferece continuidade de contexto para o desenvolvedor sem abrir mão de princípios mínimos de segurança da informação.
As críticas de quem utiliza o Claude Code, porém, não se concentram na existência de um limite de retenção, e sim na transparência e na experiência de uso associadas a essa política. Relatos apontam que, durante a instalação, na primeira execução ou antes de o mecanismo de limpeza entrar em ação, não há um alerta claro e explícito informando que qualquer conversa com mais de 30 dias será removida de forma automática. Também não seria evidente, para usuários comuns, onde encontrar a configuração responsável por esse comportamento.
Um desenvolvedor relatou que a limpeza acontece literalmente “fora da caixa”, assim que o software está em uso, sem qualquer destaque na interface inicial ou diálogo chamando atenção para o fato. Nesse cenário, muitos acabam presumindo que o histórico será mantido indefinidamente, da mesma forma que ocorre em outras ferramentas de chat ou IDEs com histórico persistente. Quando a rotina de exclusão roda, a diferença entre expectativa e realidade se traduz diretamente em frustração e perda de produtividade.
Outro depoimento destacou que, após a rotina de limpeza, o código-fonte do projeto e o histórico do repositório de versão permaneceram intactos. O que sumiu foi justamente o “fio do raciocínio” percorrido até o resultado final: mensagens que registravam debates de design, explicações passo a passo de correções, comparações entre abordagens alternativas e análises feitas ao longo de várias sessões. Em projetos de pesquisa, desenvolvimento exploratório ou investigações de bugs complexos, esse rastro de pensamento pode ter valor tão grande quanto o código que acabou sendo incorporado ao repositório.
Além disso, o mecanismo de limpeza atual não parece oferecer uma rede de segurança. Não há uma espécie de “lixeira” interna para conversas, nem um período de quarentena que permita desfazer a exclusão. Usuários apontam a ausência de qualquer opção nativa de restauração, de um log detalhando quais arquivos foram removidos ou de um fluxo de confirmação antes de apagar grandes quantidades de histórico. Uma vez concluída a limpeza, em muitos casos não há sequer uma forma simples de saber exatamente o que foi apagado.
Outro aspecto técnico que levantou preocupações é que simplesmente ampliar o período de retenção não garante o resultado esperado. Alguns usuários afirmam que, mesmo ajustando o valor de `cleanupPeriodDays` para prazos mais longos, as conversas continuaram sendo removidas em momentos inesperados. Uma análise de causa raiz feita por um dos participantes chama atenção para o critério usado na exclusão: em vez de olhar para a data da última atividade real na conversa, o sistema se basearia no `mtime` – o horário de modificação do arquivo no sistema de arquivos.
Esse detalhe pode gerar efeitos colaterais difíceis de prever. O `mtime` é facilmente alterado por outros processos: ferramentas de sincronização, rotinas de backup, scripts de organização de arquivos ou até restaurações manuais podem modificar a data de modificação de uma transcrição. Com isso, conversas ainda ativas ou relevantes podem passar a ser vistas pelo mecanismo de limpeza como “antigas demais” e acabar apagadas na próxima inicialização do Claude Code, sem qualquer notificação específica de que aquele histórico estava prestes a desaparecer.
Diante desse cenário, a principal orientação que vem sendo citada por usuários é a adoção de rotinas próprias de backup das transcrições geradas pelo Claude Code. Entre as sugestões, aparecem cópias periódicas da pasta onde os arquivos `.jsonl` são salvos, automações que fazem exportações diárias antes de abrir a ferramenta ou scripts que versionam os históricos em sistemas de controle de versão. Apesar de úteis, essas soluções são vistas mais como um paliativo do que como uma resposta definitiva ao problema.
Para muitos profissionais, backup é um procedimento essencial em qualquer fluxo de trabalho sério, mas não substitui uma política de produto robusta para operações destrutivas. A expectativa é que o próprio Claude Code ofereça mecanismos claros para lidar com a retenção automática: avisos destacados na interface, possibilidade de configurar o comportamento desde o primeiro uso, relatórios indicando o que está sendo removido e opções de reversão ou exportação antes da exclusão definitiva.
O caso evidencia uma tensão que tem se repetido em ferramentas locais de IA voltadas a desenvolvimento de software. De um lado, há a necessidade de preservar o contexto das interações, já que é esse histórico que torna o assistente mais útil ao longo do tempo, permitindo acompanhar a evolução de um projeto, relembrar decisões passadas e continuar discussões interrompidas. De outro, há uma preocupação crescente com a redução de riscos, especialmente em ambientes corporativos que lidam com dados sensíveis e exigências regulatórias rígidas.
Para times de segurança e conformidade, políticas agressivas de limpeza automática fazem sentido: quanto menos dados persistidos no disco, menor a quantidade de informação que pode ser exposta em caso de comprometimento da máquina ou de acesso indevido. Em setores regulados, como financeiro, saúde ou governo, a simples existência de longos históricos de conversas contendo detalhes técnicos internos já é vista como um risco a ser gerenciado.
Já para equipes de desenvolvimento, arquitetos de software e engenheiros de dados, o quadro é mais nuançado. Muitas vezes, a conversa com o assistente de código se torna uma forma de documentação viva, capturando não só o que foi feito, mas por que determinadas escolhas foram tomadas, quais caminhos foram testados e abandonados e quais restrições influenciaram o design de uma solução. Apagar tudo isso após 30 dias significa depender exclusivamente de documentação manual, que frequentemente não acompanha o ritmo real dos projetos.
Uma solução intermediária que vem sendo sugerida por especialistas em governança de dados é a adoção de camadas configuráveis de retenção. Em vez de um único prazo fixo aplicado indistintamente, o usuário poderia escolher perfis de uso: por exemplo, retenção curta com limpeza automática para ambientes com alta sensibilidade, retenção estendida com alertas periódicos para projetos pessoais ou pesquisa, e até perfis customizados para equipes específicas, com políticas de arquivamento bem definidas.
Outra possibilidade é separar, dentro da própria ferramenta, o que é considerado “histórico crítico” do que é “contexto temporário”. Conversas marcadas explicitamente pelo usuário como importantes – como discussões de design, decisões arquiteturais ou análises extensas – poderiam ser armazenadas em uma área diferente, sujeita a regras mais brandas de limpeza ou a fluxos de revisão antes da exclusão. Já interações rotineiras, experimentais ou triviais continuariam seguindo o prazo padrão.
Também entra em jogo a transparência visual. Alertas proeminentes na interface, indicadores de tempo restante antes da exclusão de cada conversa, mensagens de confirmação quando uma limpeza em massa estiver prestes a ocorrer e um painel com histórico das ações de limpeza ajudariam a alinhar a expectativa dos usuários ao comportamento real da ferramenta. Em vez de descobrir que tudo sumiu depois do fato, o desenvolvedor teria tempo para agir – exportando, marcando ou revisando conteúdos importantes.
Do ponto de vista de experiência do usuário, outra melhoria possível seria a oferta de um fluxo simplificado de exportação e arquivamento. Bastaria, por exemplo, um botão para salvar determinadas conversas em um formato padronizado, idealmente estruturado o suficiente para permitir buscas futuras, indexação por ferramentas de documentação e integração com sistemas já usados por equipes de engenharia.
A discussão em torno do Claude Code acaba funcionando como um estudo de caso sobre como decisões de segurança, quando implementadas sem comunicação clara e sem opções de controle, podem impactar diretamente o dia a dia de trabalho de desenvolvedores. O desafio não está apenas em escolher um número – 30 dias, 60 dias ou 1 ano -, mas em desenhar mecanismos que tornem esse tipo de política visível, compreensível e ajustável.
Enquanto a Anthropic mantém a posição de que a retenção limitada é um pilar de segurança do produto, cresce a demanda para que a ferramenta evolua na forma como lida com o histórico de conversas: oferecendo mais transparência, granularidade de configuração, meios de recuperação e, principalmente, respeito à expectativa de que o raciocínio por trás do código não deve desaparecer sem aviso. O equilíbrio entre proteção de dados e preservação de conhecimento técnico continua sendo um dos principais pontos de fricção na adoção de assistentes de IA em fluxos de desenvolvimento reais.