Se você usa Claude Code em ambiente de produção — seja para revisar código, automatizar fluxos de desenvolvimento ou dar ao modelo acesso a arquivos do seu repositório — a versão v2.1.214 não é uma atualização opcional. É uma correção de segurança que fecha falhas reais no sistema de permissões, falhas que poderiam permitir que o modelo escrevesse, executasse ou redirecionasse operações em lugares que você explicitamente não autorizou.
A Anthropic publicou o changelog dessa versão diretamente no repositório oficial do Claude Code no GitHub, e o conjunto de correções é suficientemente sério para merecer análise linha a linha. Vamos fazer isso.
Falha 1: regras dir/** aprovando escrita em diretórios errados
A primeira correção resolve um comportamento incorreto nas allow rules que usam o padrão dir/** com um único segmento de caminho — por exemplo, Edit(src/**).
O que deveria acontecer
Quando você escreve uma regra como Edit(src/**), a intenção é clara: autorizar edições dentro do diretório src/ a partir do diretório de trabalho atual (cwd). Ou seja, apenas <cwd>/src/ e seus subdiretórios.
O que estava acontecendo na prática
O parser de permissões interpretava a regra de forma mais permissiva do que o pretendido. O padrão src/** estava sendo resolvido como “qualquer diretório chamado src em qualquer ponto da árvore de arquivos”, não apenas o src imediatamente abaixo do cwd.
Na prática, isso significava que uma regra como Edit(src/**) poderia aprovar automaticamente escritas em caminhos como:
/home/user/projeto/outras-pastas/src/arquivo-critico.ts
/home/user/projeto/node_modules/algum-pacote/src/index.jsPara times que trabalham com monorepos ou estruturas com múltiplas pastas src/ aninhadas, o risco é direto: o modelo poderia modificar arquivos fora do escopo pretendido sem disparar nenhum alerta de permissão. A correção na v2.1.214 restringe a resolução do padrão ao caminho exato relativo ao cwd, que é o comportamento esperado e documentado.
Falha 2: bypass de verificação de permissão no Windows PowerShell 5.1
A segunda correção é geograficamente específica, mas com impacto real para qualquer time que desenvolve em Windows.
O contexto do problema
O Claude Code verifica permissões antes de executar comandos no shell. Essa verificação é a camada que impede que o modelo execute comandos não autorizados — ela analisa o comando antes de passá-lo ao interpretador.
O problema: essa análise falhava silenciosamente em sessões rodando no Windows PowerShell 5.1. A versão 5.1 do PowerShell tem particularidades de parsing e codificação de strings que diferem tanto do PowerShell Core (7.x) quanto do CMD tradicional. O analisador de permissões do Claude Code não tratava essas particularidades, o que abria a possibilidade de que comandos fossem executados sem passar pela verificação correta.
Por que isso é grave
Um bypass de verificação de permissão não é uma falha de UX — é uma falha de modelo de segurança. Se o sistema promete que “apenas comandos autorizados serão executados”, e essa promessa não vale para uma versão específica de shell amplamente usada em ambientes corporativos Windows, você não tem como confiar nas suas políticas de permissão.
Times que usam Claude Code em pipelines de CI/CD no Windows, ou em máquinas de desenvolvedores com PowerShell 5.1 (que ainda é o padrão em muitas instalações do Windows 10 e Windows Server), estavam operando com uma falsa sensação de controle.
Falha 3: redirecionamento de file-descriptor no Bash passando pela análise
A terceira correção talvez seja a mais técnica, mas também a mais insidiosa para quem não conhece as particularidades do Bash.
O problema com redirecionamentos de file-descriptor
O Bash suporta formas avançadas de redirecionamento de entrada e saída usando file descriptors explícitos, como:
# Redirecionar stderr para um arquivo
comando 2>/tmp/erro.log
# Redirecionar stdout para um file descriptor aberto
exec 3>/caminho/para/arquivo
echo "dados" >&3Essas formas de redirecionamento são sintaticamente diferentes dos redirecionamentos simples (>, >>, <) e o analisador de permissões do Claude Code não as reconhecia corretamente. O resultado: comandos que usavam redirecionamentos via file descriptor eram classificados de forma errada pela análise, potencialmente sendo aprovados quando não deveriam — ou rejeitados sem motivo claro.
A correção implementa o comportamento fail-closed: quando o analisador encontra uma forma de redirecionamento que não consegue avaliar com certeza, ele nega a execução. É a abordagem conservadora correta para um sistema de segurança.
O problema com comandos muito longos
O changelog da v2.1.214 também menciona uma quarta correção relacionada: comandos com mais de 10.000 caracteres eram mal avaliados pelo verificador de permissões do Bash. Comandos longos aparecem com frequência em pipelines automatizados — pense em scripts gerados dinamicamente, listas de argumentos extensas ou comandos construídos via interpolação. A falha de análise nesses casos era outro vetor de comportamento inesperado.
O que muda na v2.1.215: /verify e /code-review agora são manuais
Junto com as correções de segurança, vale registrar uma mudança de comportamento que chega na versão imediatamente seguinte, a v2.1.215: os comandos /verify e /code-review passam a ser invocados manualmente, em vez de serem acionados automaticamente pelo fluxo de trabalho do Claude Code.
Essa mudança tem implicações práticas para times que dependem dessas verificações como parte do seu processo. Se você tinha /code-review sendo executado automaticamente ao fim de uma sessão de edição, precisará ajustar seus fluxos para invocá-lo explicitamente. A mudança devolve controle ao desenvolvedor, mas exige atenção para que revisões não sejam simplesmente esquecidas no dia a dia.
Por que atualizar agora, não depois
Existe uma tendência natural de adiar atualizações em ambientes de produção — “se está funcionando, não mexa”. Essa lógica não se aplica aqui, por uma razão simples: as três falhas corrigidas afetam diretamente o modelo de permissões, que é a única barreira entre o Claude Code e operações não autorizadas no seu sistema de arquivos e shell.
Você pode estar operando hoje com regras de permissão que acredita serem restritivas, mas que na prática são mais amplas do que configurou. Ou com um pipeline no Windows onde os comandos executados não estão sendo verificados corretamente. Ou com scripts Bash que usam redirecionamentos avançados sendo avaliados de forma incorreta.
Nenhum desses cenários é hipotético — são consequências diretas das falhas documentadas pela Anthropic.
Para atualizar o Claude Code, execute:
npm update -g @anthropic-ai/claude-codeOu, se estiver usando via npx:
npx @anthropic-ai/claude-code@latestVerifique a versão instalada com:
claude --versionApós atualizar para a v2.1.214 ou superior, revise suas allow rules existentes — especialmente aquelas com padrões dir/** — para confirmar que o escopo está de acordo com o que você pretendia configurar. Com a correção em vigor, regras que antes eram interpretadas de forma mais ampla passam a ser mais restritivas, o que é o comportamento correto, mas pode exigir ajustes se você dependia (mesmo que sem saber) do comportamento anterior.
Conclusão
A v2.1.214 do Claude Code é um exemplo do tipo de release que não gera manchete, mas que importa de verdade. Não há novas funcionalidades chamativas, não há melhoria de performance visível. Há três correções cirúrgicas em pontos onde o sistema de segurança estava falhando de formas específicas e detectáveis.
A Anthropic documentou essas correções de forma transparente no changelog público — o que é a postura correta. Cabe a você e ao seu time agir com a mesma seriedade e garantir que a versão em produção reflita essas correções.
Atualize agora. Revise suas regras de permissão. E fique de olho no que muda com a v2.1.215 em relação ao /verify e /code-review.
Fontes
- Anthropic / GitHub — Release notes oficiais do Claude Code v2.1.214: https://github.com/anthropics/claude-code/releases/tag/v2.1.214
- Anthropic — Repositório oficial do Claude Code no GitHub: https://github.com/anthropics/claude-code
