Atualizar uma ferramenta de linha de comando pode parecer rotina — mas algumas versões carregam mudanças que afetam diretamente a confiabilidade de pipelines inteiros. A v2.1.205 do Claude Code, lançada pela Anthropic, é exatamente esse tipo de release: quatro correções e adições cirúrgicas que resolvem problemas com impacto real em segurança, integridade de dados e comportamento em ambientes Windows. Se a sua equipe usa Claude Code em automações, CI/CD ou ambientes heterogêneos, esta leitura é obrigatória.
1. Nova regra de segurança no auto mode: sem adulteração de transcrições
A mudança mais estratégica desta versão é a adição de uma regra explícita no modo automático que bloqueia qualquer tentativa de adulteração dos arquivos de transcrição de sessão.
Por que isso importa? Em fluxos automatizados — onde o Claude Code opera sem supervisão humana direta —, os arquivos de transcrição são o registro auditável de tudo o que aconteceu: quais ferramentas foram chamadas, quais arquivos foram modificados, quais decisões foram tomadas. Em contextos sensíveis (compliance, auditoria de código, rastreabilidade de deploys), a integridade dessas transcrições não é opcional; é o que separa um sistema confiável de um sistema que “parece” confiável.
A preocupação que essa regra endereça é sofisticada: em cenários de prompt injection ou em situações onde o modelo recebe instruções maliciosas embutidas em contexto externo (um arquivo de código com instruções escondidas em comentários, por exemplo), um agente sem restrições poderia ser induzido a modificar ou apagar seu próprio log de atividades. Isso tornaria a auditoria pós-fato impossível.
Com a nova regra, o auto mode passa a tratar os arquivos de transcrição como zona protegida, bloqueando ações que tentem sobrescrevê-los, truncá-los ou deletá-los durante a sessão. A Anthropic está, na prática, construindo um perímetro de segurança em torno da memória operacional do agente.
Impacto prático: equipes que rodam Claude Code em pipelines de CI/CD ou em automações noturnas ganham uma camada adicional de proteção contra manipulação de registros — seja por erro, seja por entrada maliciosa no contexto.
2. --json-schema finalmente se comporta como você espera
Esta correção resolve dois bugs relacionados ao flag --json-schema que, juntos, tornavam o recurso de saída estruturada bastante imprevisível:
Bug 1 — Saída silenciosamente não estruturada: quando um schema inválido era passado via --json-schema, o Claude Code simplesmente ignorava o schema e produzia saída em texto livre — sem nenhum aviso, sem nenhum erro. Para pipelines que dependem de JSON estruturado para alimentar etapas seguintes (parsers, bancos de dados, APIs), isso significava falhas silenciosas que apareciam muito depois, no lugar errado, difíceis de rastrear.
Bug 2 — Rejeição indevida de schemas com format: schemas que usavam a palavra-chave format (comum em JSON Schema para validar formatos como date-time, email, uri) eram rejeitados pelo Claude Code, mesmo sendo schemas perfeitamente válidos. Isso forçava equipes a remover propriedades legítimas dos seus schemas ou a manter versões “mutiladas” apenas para compatibilidade com a ferramenta.
Com a v2.1.205, os dois comportamentos foram corrigidos:
- Schemas inválidos agora geram erro explícito, interrompendo a execução antes de produzir saída incorreta.
- Schemas com a keyword
formatsão aceitos e processados normalmente.
Exemplo de uso agora funcional:
claude --json-schema '{
"type": "object",
"properties": {
"created_at": {
"type": "string",
"format": "date-time"
},
"email": {
"type": "string",
"format": "email"
}
}
}' "Extraia os dados de contato deste documento"Antes desta versão, o schema acima seria rejeitado por causa do format. Agora, funciona como esperado. Para equipes que constroem pipelines de extração de dados estruturados com Claude Code, esta correção desbloqueia casos de uso que estavam bloqueados ou exigiam gambiarras.
3. Mensagens perdidas no limite de --max-turns: recuperação garantida
O terceiro fix endereça um problema de perda silenciosa de dados que ocorria em um cenário específico, mas muito comum em automações: o usuário (ou o sistema automatizado) enviava uma mensagem enquanto o Claude estava processando sua resposta, e essa sessão atingia exatamente o limite de --max-turns no momento em que o turno atual terminava.
O resultado? A mensagem enviada durante o processamento era descartada silenciosamente, sem aviso. Em pipelines onde cada mensagem carrega uma instrução ou dado importante, perder uma mensagem sem saber é potencialmente catastrófico — você assume que a instrução foi recebida e processada, mas ela simplesmente desapareceu.
A correção garante que mensagens enviadas durante o processamento de um turno, mesmo quando o limite de --max-turns é atingido, não sejam perdidas. O comportamento exato de como elas são tratadas (enfileiradas, reportadas como não processadas) depende do contexto de uso, mas o ponto central é: a perda silenciosa foi eliminada.
Por que isso é crítico em automações? Em pipelines onde Claude Code opera com --max-turns definido para controlar custo ou tempo de execução, a interação entre o limite de turnos e mensagens concorrentes criava uma janela de falha invisível. Times de engenharia podiam passar horas depurando comportamentos inesperados sem encontrar a causa — porque não havia nenhum log de erro, nenhum sinal de que algo tinha sido perdido.
4. Worktrees no Windows: o bug que destruía arquivos fora do seu escopo
Este é, sem dúvida, o bug com maior potencial de dano desta lista — e provavelmente o mais obscuro.
O cenário: você está usando Claude Code com Git worktrees em um ambiente Windows com sistema de arquivos NTFS. Dentro do worktree, existe um junction NTFS (equivalente Windows a um symlink de diretório) ou um symlink de diretório apontando para algum lugar fora do worktree. Quando o Claude Code executava a remoção do worktree, ele seguia esse junction/symlink e deletava arquivos no destino — arquivos que estavam completamente fora do escopo do worktree sendo removido.
Em português simples: ao remover um worktree, o Claude Code podia apagar arquivos de outras partes do seu sistema.
Junctions NTFS são comuns em ambientes Windows corporativos para mapear estruturas de diretórios, criar compatibilidade entre ferramentas que esperam caminhos específicos, ou gerenciar dependências. Times que trabalham com múltiplos worktrees em projetos complexos e usam junctions para organizar o ambiente estavam expostos a este bug.
A v2.1.205 corrige o comportamento de remoção de worktrees para que ele respeite os limites do worktree, sem seguir junctions ou symlinks de diretório para fora do seu escopo.
Recomendação imediata: se sua equipe usa Claude Code em Windows com Git worktrees e há qualquer junction NTFS ou symlink de diretório no ambiente, atualize para v2.1.205 antes do próximo ciclo de trabalho. O risco de perda de dados com versões anteriores é real.
Como atualizar
A atualização é direta via npm:
npm update -g @anthropic-ai/claude-codePara verificar a versão instalada após a atualização:
claude --versionConfirme que a saída exibe 2.1.205 ou superior antes de retomar pipelines automatizados.
O padrão que esta release revela
Olhando as quatro mudanças em conjunto, é possível identificar um padrão claro nas prioridades da Anthropic para o Claude Code: confiabilidade em ambientes não supervisionados.
Cada fix desta versão ataca uma variante do mesmo problema — o que acontece quando o Claude Code opera sozinho, sem um humano assistindo a cada passo? A nova regra de transcrição protege a auditabilidade. A correção do --json-schema elimina falhas silenciosas na saída. A recuperação de mensagens perdidas elimina perda silenciosa de entrada. E a correção dos worktrees elimina destruição silenciosa de dados.
Para equipes que estão migrando de uso interativo para uso agêntico do Claude Code — onde o modelo toma decisões encadeadas sem intervenção humana —, essa evolução é exatamente o que precisam ver acontecer. Ferramentas agênticas precisam falhar barulhentamente e proteger silenciosamente; não o contrário.
Se você ainda não integrou Claude Code nos seus pipelines de desenvolvimento, este é um bom momento para revisar o repositório oficial e avaliar os casos de uso. A trajetória de maturidade da ferramenta está clara.
