Claude Code 2.1.268: O que foi corrigido nas regras deny e no MCP

A versão 2.1.268 do Claude Code foi lançada a 10 de setembro de 2026, seguida no dia seguinte pela versão 2.1.269. Deve atualizar imediatamente: em dois casos, as regras deny que utiliza para impedir o agente de aceder a .env e a pastas de serviços eram silenciosamente ineficazes. Além disso, o comando /mcp podia imprimir segredos das suas configurações no terminal.

Tudo o que se segue baseia-se no changelog e na documentação oficiais da Anthropic, tal como estavam a 17 de setembro de 2026, a data do material de origem. Nesse dia, a versão mais recente era a 2.1.274. Descrevemos o funcionamento dos erros com base nessas entradas; os contornos das proteções não foram reproduzidos na versão vulnerável.

Para obter instruções adicionais sobre como trabalhar com Ailoot, consulte a documentação.

O que foi corrigido no Claude Code 2.1.268 e 2.1.269?#

Quatro correções são relevantes para as regras de permissões:

1. As proibições em ligações simbólicas não funcionavam. As regras deny e ask escritas para diretórios que são ligações simbólicas (/etc, /tmp, /var no macOS, /bin no Linux) não eram acionadas quando o caminho era especificado pela sua localização real. Os comandos Bash também ignoravam as regras deny escritas para um caminho através de uma ligação simbólica.
2. A proibição de leitura e edição falhava com env -C ou eval. Se a mesma linha de comando contivesse uma construção que a verificação de permissões não conseguisse analisar, a regra deny para Read ou Edit podia não ser acionada.
3. Uma regra com “!” aplicava-se de forma mais abrangente do que o pretendido. Uma regra deny ou ask iniciada por ! aplicava-se para além do ficheiro de definições onde estava escrita. Agora, aplica-se apenas no âmbito da sua própria origem, e uma negação isolada ! é ignorada.
4. tee contornava as proibições ao escrever. As regras deny para Edit() e a verificação do caminho de escrita não se aplicavam a um ficheiro criado pelo comando Bash tee. A permissão Bash(tee:*) já não abrange escritas fora dos diretórios de trabalho.

Estas versões também corrigiram dois problemas relacionados com a exposição de segredos. O WebFetch já não espera indefinidamente por uma resposta de um servidor que mantém a ligação aberta: o pedido falha agora ao fim de 300 segundos, e o tempo limite pode ser configurado com a variável CLAUDE_CODE_WEBFETCH_DEADLINE_MS. Também foi eliminado o uso persistentemente elevado de CPU em sessões longas em inatividade.

Como funcionam as proibições no Claude Code?#

O Claude Code tem três listas de regras: deny (sempre proibido), ask (perguntar antes de executar a ação) e allow (permitido sem confirmação). Quando o agente está prestes a fazer algo, as regras são verificadas rigorosamente por essa ordem. Uma regra deny correspondente anula qualquer regra allow para a mesma ação: uma regra allow não pode abrir uma exceção a uma proibição.

As regras são guardadas em três locais: regras do utilizador em ~/.claude/settings.json, regras do projeto em .claude/settings.json dentro do repositório e regras locais em .claude/settings.local.json. Segue-se um exemplo de definições que proíbem a leitura de um ficheiro com chaves:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Pode ver todas as regras ativas e o ficheiro de origem de cada uma executando /permissions numa sessão. Se uma regra bloquear a leitura, a mensagem de proibição identifica essa regra, o que será útil para a verificação abaixo.

Que erros afetaram as proibições e o âmbito das regras?#

Os erros afetaram as verificações de caminhos e comandos, bem como o âmbito das regras provenientes de diferentes ficheiros de definições.

Primeiro caso: ligações simbólicas. No macOS, /etc, /tmp e /var são ligações simbólicas para pastas reais em /private; no Linux, /bin é frequentemente uma ligação semelhante. Se escreveu uma regra deny para uma forma do caminho, mas o agente acedeu ao mesmo caminho usando outra (por exemplo, a localização real em vez da ligação simbólica), a regra não era acionada. Os comandos Bash também ignoravam uma proibição escrita para um caminho através de uma ligação simbólica. Na versão 2.1.268, ambos os casos foram corrigidos: a regra aplica-se agora independentemente da forma do caminho utilizada.

Segundo caso: env -C e eval na mesma linha. A verificação de permissões analisa um comando para determinar a que ficheiros este irá aceder. Não consegue analisar construções como env -C ou eval. O erro consistia em que, quando uma dessas construções aparecia na linha, a regra deny para Read ou Edit podia não ser aplicada. Como resultado, o comando podia contornar a proibição de leitura ou edição de um ficheiro protegido.

Terceiro caso: uma regra com “!” aplicava-se para além dos seus limites. Uma regra iniciada por ! deve aplicar-se apenas ao ficheiro de definições onde está escrita. Antes da versão 2.1.269, também se aplicava a outras origens de definições. Agora, o seu âmbito limita-se ao próprio ficheiro, e uma regra composta apenas por ! é ignorada.

Quarto caso: escrita através de tee. O comando Bash tee pode escrever num ficheiro. A verificação do caminho de escrita e as regras deny para Edit() não se aplicavam a esse ficheiro. Ao mesmo tempo, a permissão Bash(tee:*) abrangia escritas fora dos diretórios de trabalho. Na versão 2.1.269, estas verificações passaram a aplicar-se às escritas através de tee: a proibição para o ficheiro produz efeito, e Bash(tee:*) abrange apenas os diretórios de trabalho.

Se utiliza proibições específicas — para bloquear .env, algumas pastas de serviços ou comandos perigosos — também as deve verificar. Os passos estão abaixo.

Porque podia /mcp apresentar as suas chaves?#

As configurações dos servidores MCP guardam frequentemente as chaves em variáveis de ambiente e referenciam-nas através de ${VAR}, para que o ficheiro possa ser guardado num repositório sem incluir os próprios segredos. O problema era que os comandos de visualização (/mcp, /plugin, claude mcp list, claude mcp get) e as mensagens de erro de início de sessão MCP apresentavam a configuração com os valores já substituídos. A própria chave aparecia no ecrã.

Outra correção diz respeito aos erros de plugins e marketplaces: podiam apresentar um token ou uma palavra-passe do URL Git de origem.

Se o resultado de /mcp ou claude mcp list numa versão anterior apareceu numa transmissão em direto, numa captura de ecrã, numa mensagem enviada a um colega ou num registo que saiu do seu computador, incluindo automaticamente, parta do princípio de que as chaves das suas configurações MCP foram expostas e altere-as. Se o resultado nunca saiu do seu computador, basta atualizar. Temos um guia separado sobre servidores MCP e configurações prontas a utilizar: Servidores MCP do Claude Code.

Outras alterações nestas versões#

WebFetch e artefactos. Anteriormente, uma regra WebFetch sem detalhes nas listas deny ou ask também se aplicava à leitura e modificação de artefactos publicados. A partir da versão 2.1.268, deixou de se aplicar a esses artefactos. Para os bloquear, precisa de uma regra Artifact separada ou de uma regra para o domínio, como WebFetch(domain:claude.ai). Se dependia de uma proibição geral de WebFetch para impedir a leitura de artefactos, volte a verificar as definições: a regra anterior já não bloqueia essas ações.

O WebFetch tem agora um tempo limite. Um pedido a um servidor que mantém a ligação aberta e não conclui a resposta falha agora ao fim de 300 segundos. Anteriormente, um pedido desse tipo podia ficar bloqueado indefinidamente. O comportamento pode ser configurado com a variável CLAUDE_CODE_WEBFETCH_DEADLINE_MS; defini-la como 0 desativa o tempo limite.

Foi eliminado o uso persistentemente elevado de CPU em sessões inativas. Em sessões longas em inatividade, um ciclo de inatividade no Claude Code podia causar um uso persistentemente elevado de CPU. Este erro foi corrigido na versão 2.1.268. Também podia afetar quem mantém sessões abertas durante todo o dia.

Instale a versão mais recente. Surgiu um novo erro na versão 2.1.269: após uma sessão estar em execução durante muito tempo, os comandos Bash do Git que apenas liam dados começaram a pedir permissão. O erro foi corrigido na versão 2.1.270. Por isso, atualize para a versão mais recente (a 17 de setembro de 2026, era a 2.1.274); não fique pela 2.1.268 ou 2.1.269.

Como atualizar e verificar se as proibições funcionam?#

1. Veja qual é a versão atual. Execute claude --version no terminal. As correções dos problemas descritos acima foram lançadas nas versões 2.1.268 e 2.1.269. Se o número da versão for inferior a 2.1.268, ainda não inclui estas correções, embora a aplicabilidade de cada problema dependa dos caminhos, comandos e regras que utiliza.
2. Atualize. O guia como atualizar o Claude Code para a versão mais recente contém instruções passo a passo e resolução de problemas. Escolha a versão mais recente; não fique pela 2.1.268.
3. Teste a proibição. Não teste uma regra num ficheiro .env real: se a proibição falhar, o agente verá chaves reais. Crie um ficheiro de teste, por exemplo secret-test.txt, com qualquer texto, como “isto é um teste”; adicione a regra "Read(./secret-test.txt)" à lista deny no ficheiro .claude/settings.json do projeto; reinicie a sessão; e peça: “lê o ficheiro secret-test.txt e diz-me o que contém.” O comportamento esperado é uma mensagem de proibição que identifique a sua regra. Se o agente ler o ficheiro, a proibição não funcionou neste teste. Comece por verificar a sintaxe na secção acima e abra /permissions para ver as regras ativas e os ficheiros de onde foram carregadas. O resultado do teste, por si só, não identifica a causa. Uma proibição demonstra que a regra para este ficheiro funciona; não permite concluir nada sobre as outras regras, por isso verifique-as uma a uma da mesma forma.
4. Se utilizar caminhos como estes, verifique o caso das ligações simbólicas. Se tiver proibições para /tmp, /etc ou /var no macOS, ou para /bin no Linux, repita o teste para esses caminhos depois de atualizar.
5. Reveja as regras com “!”. Se tiver utilizado alguma, confirme que cada uma está escrita no ficheiro onde se pretende que se aplique.

Se a proibição funcionar, mas o Claude Code continuar sem conseguir ver os ficheiros de que precisa, consulte a explicação separada: porque é que o Claude Code não consegue ver os ficheiros do projeto.

Se não puder atualizar neste momento#

Por vezes, tem de adiar uma atualização: não pode alterar o ambiente, o computador pertence à empresa ou precisa de concluir a tarefa atual. Até atualizar, pode reduzir o risco da seguinte forma:

• escreva regras deny para ambas as formas do caminho — a ligação simbólica e a localização real (no macOS, os caminhos reais estão sob /private);
• não combine vários comandos numa só linha e evite env -C e eval nos comandos que pedir ao agente para executar;
• não mostre a ninguém o resultado de /mcp, /plugin, claude mcp list ou claude mcp get, e altere as chaves das configurações MCP que possam ter ido parar às mãos de terceiros;
• lembre-se de que tee escreve apesar da regra deny para Edit — não considere os ficheiros protegidos se Bash estiver autorizado.

Estas medidas reduzem a probabilidade de contornos específicos, mas não substituem a correção. Atualize e execute o teste da secção anterior assim que puder.

Resumo breve#

As versões 2.1.268 e 2.1.269 corrigiram quatro problemas de permissões no Claude Code: ligações simbólicas, linhas com env -C e eval, regras com “!” que se aplicavam para além do respetivo ficheiro e escritas através de tee. Separadamente, corrigiram a exposição de segredos no resultado de /mcp e de tokens nos erros dos plugins. Verifique o número da versão, atualize para a versão mais recente e execute o teste com um ficheiro de teste da secção anterior. Uma mensagem de proibição que identifique a sua regra demonstra que a proibição funcionou neste teste. A mera presença da regra nas definições não é suficiente para a verificar.

Para continuar a trabalhar com modelos, pode aceder à Ailoot.