Controle de acesso à rede no Claude Code passa a valer por comando
Entenda como o controle de acesso à rede por comando do Claude Code reduz permissões persistentes em instalações de dependências executadas no sandbox.

Uma instalação de dependências não precisa mais ampliar o controle de acesso à rede durante todo o restante de uma tarefa do Claude Code. Em 14 de setembro de 2026, o Claude Code 2.1.271 passou a oferecer acesso à rede restrito ao comando no auto mode em sandbox. Assim, o host do registry liberado para a instalação volta a ser bloqueado quando esse comando termina.
O que mudou no controle de acesso à rede
O Claude Code tem duas camadas de segurança distintas nesse fluxo. A mudança só fica clara quando cada uma delas é analisada separadamente.
O auto mode decide se uma chamada de ferramenta pode ser executada. Um classificador independente avalia a ação em relação ao pedido feito. O guia anterior sobre o auto mode do Claude Code explica esse modelo geral de permissões.
O sandbox define o que um comando de shell em execução pode acessar. Ele limita gravações em arquivos e encaminha o tráfego de rede por um proxy que verifica o host de destino.
A versão 2.1.271 conecta essas camadas de forma mais estreita. Agora, uma chamada de Bash, PowerShell ou Monitor pode incluir uma lista allowed_domains no auto mode em sandbox. O Claude Code avalia o comando e os hosts necessários em conjunto. Esses hosts são liberados apenas para aquele comando, enquanto o sandbox recusa os demais. A nota de lançamento deixa esse escopo explícito.
Esse campo em snake case não é a mesma coisa que sandbox.network.allowedDomains no settings.json.
Antes dessa versão, aprovar um novo host no sandbox podia resultar em uma autorização mais ampla. Uma aprovação manual vale pelo restante da sessão atual, e uma aprovação salva pode persistir em sessões posteriores. O auto mode também pode armazenar em cache a decisão sobre um host e uma porta. O novo campo muda o alcance durante a execução mesmo quando o veredito do classificador é reutilizado: a liberação da rede pertence ao comando atual.
O efeito se limita à combinação citada no lançamento: auto mode, sandbox e Bash, PowerShell ou Monitor. Sessões manuais, comandos fora do sandbox, ferramentas internas de arquivos e tarefas que nunca acessam a rede não recebem esse limite.
O cálculo que importa é o escopo da permissão, não um plano mais barato
Nenhum preço de licença do Claude Code mudou. A Anthropic não anunciou tarifa, SKU ou resultado de desempenho específico para domínios limitados por comando.
A conta útil é o tamanho da autorização que precisa ser defendida:
standing grant = approved host × every later command that can reuse it
command-scoped grant = approved host × the reviewed command
Considere uma instalação de dependências que precisa acessar registry.npmjs.org. Antes, a escolha operacional costumava ser incômoda: interromper uma tarefa autônoma para decidir sobre a rede ou liberar o registry de antemão e aceitar que todo comando posterior no sandbox poderia acessá-lo. Agora, o auto mode pode aprovar o host junto com a própria instalação e fechá-lo antes que as etapas de build, teste, empacotamento e revisão continuem.
Isso altera duas linhas de custo, embora não mude a fatura da assinatura. As equipes de plataforma passam a ter menos exceções permanentes para definir e remover. Quem revisa a segurança pode avaliar o par comando-host, sem tratar o host como disponível durante todo o restante da tarefa.
Ainda existe custo computacional no fluxo de avaliação. Em contas Enterprise e de provedores com cobrança por uso citadas na documentação da Anthropic sobre modos de permissão, as verificações do classificador consomem tokens e acrescentam uma comunicação de ida e volta. O lançamento não fornece benchmark de tempo, e nenhum teste cronometrado foi feito para este artigo. Portanto, não há base para prometer uma economia de segundos.

Quem já pode aproveitar essa mudança
Fundador solo que executa uma tarefa longa de build
Quem toca uma empresa sozinho pode deixar o Claude Code restaurar os pacotes travados de um repositório SaaS e, em seguida, prosseguir com testes e revisão de código sem manter o registry público aberto para essas etapas. A vantagem é deixar a tarefa avançar sem transformar um download necessário em saída de rede permanente durante toda a sessão.
Líder técnico de agência que alterna entre repositórios de clientes
Uma agência pode vincular o host de pacotes do cliente à instalação que realmente precisa dele, em vez de salvar mais uma exceção no nível do projeto. Isso reduz a limpeza de permissões e dificulta que um comando da fase seguinte envie código do cliente a um host aberto apenas para trabalhar com dependências.
Responsável por plataforma ou segurança que administra agentes autônomos
Uma equipe de plataforma pode manter regras de bloqueio para toda a organização e restrições gerenciadas de domínio, enquanto comandos rotineiros solicitam um acesso mais estreito dentro dessa política. O registro da avaliação fica mais fácil de explicar: este comando precisou deste host para esta ação. Isso não prova que o host era seguro para tudo o que o agente fez depois.
Engenheiro de build que separa instalação e teste
Um engenheiro de build pode transformar a restauração de pacotes em uma fase com rede e a suíte de testes em uma fase offline. Se um teste comprometido ou um script inesperado tentar acessar o registry após o fim da instalação, ele não herdará a liberação do comando anterior — a menos que outra regra permanente já autorize esse host.
Como limitar uma instalação de dependências npm
A maneira mais clara de entender a mudança é usar um repositório com package-lock.json versionado e dependências resolvidas por um único registry conhecido. A documentação do npm recomenda npm ci para instalações automatizadas e limpas: o comando exige um lockfile, falha quando há divergência entre o lockfile e o manifesto, remove um node_modules existente e não altera o manifesto nem o lockfile. A opção --ignore-scripts impede a execução de scripts de ciclo de vida dos pacotes durante a instalação. Esses comportamentos estão documentados pelo npm.
Confirme a versão do Claude Code
Execute a verificação de versão indicada no changelog:
Bashclaude --versionUse a versão 2.1.271 ou uma compilação posterior que já inclua o recurso.
Inicie o auto mode em um sandbox que bloqueia em caso de falha
Em uma única sessão, combine o auto mode com um sandbox que precisa iniciar corretamente e impede que um comando bloqueado seja repetido fora desse limite:
Bashclaude --permission-mode auto --settings '{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}'O comando usa os controles documentados
--permission-mode,--settings,failIfUnavailableeallowUnsandboxedCommands. No macOS, o sandbox já vem integrado. Linux e WSL2 precisam debubblewrapesocat; o sandbox integrado não oferece suporte ao Windows nativo. A configuração e as limitações de plataforma estão no guia do sandbox.Descreva a instalação com um escopo restrito
Envie a tarefa abaixo, trocando o host do registry caso o lockfile use um registry privado:
Instale exatamente as dependências de
package-lock.jsoncomnpm ci --ignore-scripts. Este comando pode acessar somenteregistry.npmjs.org. Não salve esse host nas configurações do projeto nem do usuário. Quando a instalação terminar, execute a suíte de testes em um comando separado e sem acesso à rede. Pare se a instalação exigir qualquer outro host.O campo
allowed_domainsnão é digitado manualmente. O Claude Code monta a chamada da ferramenta de shell, e o auto mode avalia o host solicitado junto com essa chamada.Verifique se a próxima etapa começa bloqueada
Abra
/sandbox, consulte a aba Config já resolvida e confirme queregistry.npmjs.orgnão consta em umallowedDomainspermanente nem em uma regraWebFetchsalva. Depois, execute o comando de teste separadamente. Qualquer tentativa de rede desse comando posterior precisará do seu próprio conjunto de domínios avaliados ou será recusada pela política existente.
O ponto que costuma causar confusão é o lockfile. Um lockfile pode apontar para um registry privado, um host Git ou uma URL direta de tarball. Citar apenas registry.npmjs.org não transfere essas dependências para lá. Confira os hosts realmente resolvidos, mantenha a lista exata e deixe o comando parar se o lock solicitar um destino inesperado.
O que o controle de acesso à rede por comando não resolve
O acesso à rede limitado por comando restringe quando um host fica acessível. Ele não prova que o host é confiável, não inspeciona todas as solicitações criptografadas nem torna seguro o código baixado.
O proxy integrado da Anthropic filtra por hostname e, por padrão, não inspeciona o conteúdo TLS. Durante o comando aprovado, um processo consegue acessar qualquer caminho permitido naquele host. Processos-filhos criados pelo comando compartilham o limite do sandbox. Por isso, npm ci --ignore-scripts funciona bem como exemplo didático: a opção retira os scripts de ciclo de vida dos pacotes da etapa de instalação, mas não audita os pacotes baixados.
A política gerenciada continua acima desse recurso. strictAllowlist pode bloquear tudo o que estiver fora da lista configurada, e allowManagedDomainsOnly pode restringir os hosts autorizados às configurações gerenciadas. Regras explícitas de bloqueio continuam prevalecendo. Os domínios por comando não atravessam esses controles.
Uma nova tentativa fora do sandbox é outro caso importante. Por padrão, o Claude Code tem uma rota de escape para comandos que o sandbox não consegue executar. Definir allowUnsandboxedCommands como false é importante porque impede que uma instalação malsucedida troque silenciosamente a pergunta “qual host este comando pode acessar?” por “este comando pode ser executado fora do sandbox?”.
O que fazer na próxima segunda-feira
Vale agir nesta semana se o Claude Code roda em auto mode para atualizações de dependências, manutenção durante a madrugada ou tarefas autônomas de build e os registries de pacotes ainda ficam em uma allowlist ampla do sandbox. O recurso cria uma boa oportunidade para testar se essas entradas permanentes podem ser removidas.
É melhor esperar se a organização adota uma política de rede gerenciada que libera o registry de propósito para todos os comandos, ou se um contêiner externo ou executor de CI já impõe uma regra de saída mais restrita por processo. O novo campo ainda pode acrescentar defesa em profundidade, mas não substitui o limite que já está em operação.
Nada muda para quem não usa auto mode com sandbox ou para tarefas que nunca chamam Bash, PowerShell ou Monitor pela rede.
A ação para segunda-feira é pequena: confirme o Claude Code 2.1.271 ou mais recente, escolha uma instalação baseada em lockfile, inicie-a em auto mode com um sandbox que bloqueia em caso de falha, informe apenas o host esperado do registry e então prove que o comando de teste seguinte não consegue reutilizar esse caminho de rede. Só remova uma exceção permanente do registry depois que essa verificação passar no seu próprio ambiente.
Se você quer acompanhar a próxima mudança de plataforma já traduzida para o fluxo de trabalho que ela afeta, assine a newsletter.
- Última atualização
- 15 de set. de 2026
- Categoria
- Explained







