Claude Code 2.1.314 fecha um fail-open da política gerida e adiciona um interruptor que bloqueia escritas fora dos diretórios de trabalho

Atualize já se as suas barreiras de proteção do Claude Code vivem nas definições geridas. O Claude Code 2.1.314, datado de 30 de outubro de 2026 no changelog da Anthropic, corrige um caso em que uma sessão podia arrancar sem qualquer política. Fecha ainda três lacunas mais estreitas na sandbox, nos hooks e nas fontes de definições, e adiciona a primeira definição que faz as ferramentas de ficheiros do Claude recusar escritas fora dos diretórios de trabalho em todos os modos de permissão. A nossa classificação do Claude Code mantém-se condicional: é uma versão de reforço de rotina, e a resposta certa é atualizar, não repensar a ferramenta.

O que aconteceu

O fail-open da política gerida

O changelog, na íntegra: «Corrigido: forceRemoteSettingsRefresh definido apenas nas definições geridas remotas deixava de se aplicar depois de expirada a cópia armazenada, o que permitia que as sessões arrancassem sem política quando o servidor não estava acessível».

Na prática: uma organização que definia forceRemoteSettingsRefresh apenas nas suas definições geridas remotas esperava que o Claude Code se recusasse a correr sem gestão. Assim que a cópia em cache expirava, esse sinalizador deixava de se aplicar, por isso uma máquina que não conseguisse alcançar o servidor de definições iniciava uma sessão sem política. As máquinas que nunca perdiam contacto com o servidor não estavam expostas por esta via.

Mais três correções de permissões e sandbox

Todas na íntegra, da entrada 2.1.314:

• «Corrigido: as proteções da sandbox não se aplicavam a uma worktree acedida por claude -p --resume ou --continue»
• «Corrigido: um ficheiro de definições excluído com --setting-sources continuava a fornecer algumas definições, como regras do modo automático e consentimentos de permissão guardados»
• «Corrigido: os hooks que correspondem a Bash não corriam em comandos de shell iniciados pela ferramenta Monitor; esses hooks podem bloquear ou perguntar, mas não aprovar ou reescrever esses comandos»

Novos interruptores de reforço

• «Adicionado permissions.blockWritesOutsideWorkingDirectories: Write, Edit e NotebookEdit recusam caminhos fora dos diretórios de trabalho em todos os modos de permissão»
• «Alterado: as ferramentas de ficheiros do Claude passam a perguntar antes de editar a cópia local das definições geridas pelo servidor da sua organização, como já fazem para os seus ficheiros de definições»
• «Alterado: os pedidos sinalizados passam a tentar de novo noutro modelo, em vez de terminar numa recusa, quando ANTHROPIC_DEFAULT_OPUS_MODEL, availableModels ou deniedModels deixam apenas um modelo Opus mais antigo, ou nenhum»

A mesma entrada adiciona compactação por inatividade ao VS Code e ao separador Code do Claude Desktop: «uma conversa com mais de 200 mil tokens deixada inativa é resumida, e o resumo é usado na sua mensagem seguinte se a cache de prompts tiver expirado».

Porque importa

O fail-open é o título. O forceRemoteSettingsRefresh existe para que uma máquina gerida não corra sem política, e falhou exatamente no caso para que foi feito: cache expirada mais servidor inacessível. Quaisquer regras de negação, definições de sandbox ou restrições de modelo entregues através das definições geridas remotas estavam ausentes dessas sessões.

As outras três correções removem cada uma um contorno silencioso:

• Trabalhos headless retomados. Quem retomava trabalhos claude -p em worktrees em sandbox corria-os sem as proteções da sandbox.
• Ficheiros de definições excluídos. Um ficheiro excluído com --setting-sources podia mesmo assim levar regras do modo automático e consentimentos de permissão guardados para uma sessão.
• Comandos da ferramenta Monitor. Os comandos de shell iniciados pela ferramenta Monitor saltavam os hooks de Bash, por isso um hook de bloqueio não disparava sobre eles.

A nova definição permissions.blockWritesOutsideWorkingDirectories cobre apenas as ferramentas de ficheiros do Claude (Write, Edit e NotebookEdit). O changelog não diz que se aplique ao Bash, por isso um comando de shell ainda pode escrever noutros locais, a menos que a sandbox ou uma regra de negação o impeça.

O que muda para si

• Frotas geridas: atualize todas as máquinas para a 2.1.314, a começar pelas que dependem de forceRemoteSettingsRefresh para bloquear sessões sem política.
• Pipelines headless: se executa claude -p --resume ou --continue dentro de worktrees em sandbox, atualize antes da próxima execução.
• Execuções sem supervisão: considere definir permissions.blockWritesOutsideWorkingDirectories nas definições geridas ou do projeto, e combine-a com a sandbox ou com regras de negação de Bash, já que não cobre comandos de shell.
• Equipas que usam --setting-sources: depois de atualizar, verifique de novo que regras do modo automático e consentimentos de permissão guardados ainda se aplicam.

O que isto não lhe diz

O changelog não nomeia nenhuma CVE nem liga a nenhum aviso, por isso não há classificação oficial de gravidade. Não há entrada 2.1.313: o changelog passa da 2.1.312 (27 de outubro) diretamente para a 2.1.314, sem dar razão. Nós próprios não testámos a 2.1.314.