Claude Code: modo automático vira padrão em 14/08/2026

O que o modo automático altera em 14 de agosto de 2026

O modo automático do Claude Code executa chamadas de ferramentas sem parar para lhe pedir confirmação e envia cada ação primeiro para um modelo classificador separado para análise. A partir de 14 de agosto de 2026, será o modo com que as novas sessões começam nos planos Pro, Max e Team. Pode mudar de modo a qualquer momento, e uma predefinição que já tenha definido para si não é substituída.

A documentação descreve a alteração desta forma:

A partir de 14 de agosto de 2026, o modo automático passa a ser o modo de permissões predefinido para novas sessões nos planos Pro, Max e Team. Pode mudar de modo a qualquer momento. Uma predefinição definida por si mantém-se, a menos que aceite o pedido de mudança apresentado uma vez, e uma predefinição gerida pela sua organização não é alterada.

Duas cláusulas são mais importantes do que a data. Um defaultMode que definir no seu próprio ficheiro de definições mantém-se depois da alteração. Uma predefinição implementada pela sua organização através de definições geridas também se mantém. A publicação do anúncio acrescenta que o modo automático continua opcional nos planos Enterprise e nas contas que utilizam a API durante a primeira fase da implementação.

Se executar o Claude Code numa VPS (servidor privado virtual), vale a pena ler sobre a alteração antes de esta entrar em vigor. Um pedido de permissão é um ponto de controlo que requer uma pessoa diante do teclado. Num servidor remoto, muitas vezes não está presente, pelo que o modo com que uma sessão começa é o modo que se mantém durante horas.

Os modos de permissões do Claude Code, da maior supervisão à menor

Existem seis modos. O nome no início de cada linha é o valor que escreve nas definições ou passa a --permission-mode.

• default: o Claude pede confirmação antes de cada novo uso de ferramenta. As leituras dentro do seu diretório de trabalho continuam sem confirmação. A CLI (interface de linha de comandos) identifica este modo como Manual e aceita manual como alias a partir do Claude Code v2.1.200.
• plan: o Claude lê ficheiros e executa comandos para explorar o ambiente, mas não edita o seu código-fonte. As edições ficam bloqueadas até aprovar o plano.
• acceptEdits: as edições de ficheiros são executadas sem confirmação, juntamente com os comandos do sistema de ficheiros mkdir, touch, rm, rmdir, mv, cp e sed. Isto aplica-se apenas a caminhos dentro do seu diretório de trabalho ou do seu additionalDirectories. Qualquer outro comando da shell continua a pedir confirmação.
• auto: tudo é executado, com o classificador a verificar primeiro cada ação. As regras explícitas ask continuam a exigir confirmação.
• dontAsk: o Claude Code recusa automaticamente tudo o que exigiria a sua confirmação. Apenas as suas regras allow, os comandos Bash incorporados de apenas leitura e as chamadas aprovadas por um hook PreToolUse serão executados. A sessão nunca espera por entrada.
• bypassPermissions: as confirmações e as verificações de segurança são ignoradas, incluindo as escritas em caminhos protegidos como .git e .claude.

Prima Shift+Tab durante uma sessão para alternar entre default, acceptEdits e plan. A barra de estado mostra o modo selecionado, como ⏵⏵ auto mode on ou um ⏸ manual mode on cinzento. Por predefinição, os outros modos não fazem parte desse ciclo. auto é adicionado ao ciclo quando a sua conta cumpre os requisitos. bypassPermissions só é adicionado quando a sessão é iniciada com --permission-mode bypassPermissions ou --dangerously-skip-permissions. dontAsk nunca aparece nesse ciclo; defina-o com claude --permission-mode dontAsk.

O modo automático também requer um modelo recente, que é normalmente a razão pela qual não aparece. Em agosto de 2026, a documentação lista Claude Opus 4.6 ou posterior, Sonnet 4.6 ou posterior e Fable 5 na Anthropic API. Também indica que modelos mais antigos, como Sonnet 4.5, não são suportados em nenhum fornecedor. Se o Claude Code indicar que o modo automático não está disponível, um desses requisitos não foi cumprido. Não se trata de uma indisponibilidade temporária, por isso esperar não resolve o problema.

Dois controlos aplicam-se em todos os modos, incluindo bypassPermissions: regras deny e regras explícitas ask. São os controlos que continuam disponíveis, independentemente do modo com que a sessão é iniciada.

O que o classificador do modo automático bloqueia

O classificador é um segundo modelo que lê a ação pendente e decide se ela corresponde ao que pediu. A documentação descreve a função numa frase:

Um modelo classificador separado analisa as ações antes da execução e bloqueia tudo o que ultrapasse o seu pedido, tenha como alvo uma infraestrutura não reconhecida ou pareça ser impulsionado por conteúdo hostil que o Claude leu.

Bloqueado por predefinição, nas categorias que um operador de servidores encontra com mais frequência:

• Transferir e executar código, como curl | bash
• Deploys e migrações em produção
• Force push
• Modificar infraestrutura partilhada
• Abrir um túnel ou reverse shell que torne um serviço local acessível a partir da Internet pública
• Imprimir uma credencial ou um token ativo na transcrição ou num ficheiro

Permitido por predefinição:

• Operações em ficheiros locais no diretório de trabalho
• Instalar dependências declaradas nos seus lock files ou manifests
• Pedidos HTTP apenas de leitura
• Fazer push para qualquer branch do repositório em que está a trabalhar

Não trabalhe a partir de um resumo como o anterior. Execute claude auto-mode defaults para imprimir as listas completas de regras em JSON e leia o conjunto fornecido com a versão que instalou.

Antes de depender deste mecanismo, tenha em conta dois limites documentados. Primeiro, o classificador vê as suas mensagens, as chamadas de ferramentas e o conteúdo CLAUDE.md, mas os resultados das ferramentas são removidos. Assim, o texto dentro de um ficheiro ou de uma página Web que o Claude leu não consegue interagir diretamente com o classificador. Segundo, quando o classificador bloqueia uma ação 3 vezes seguidas ou 20 vezes numa sessão, o modo automático é pausado e o Claude Code volta a pedir confirmação. Esses limites não são configuráveis. No modo não interativo, com a flag -p, não há ninguém a quem pedir confirmação. Por isso, bloqueios repetidos abortam a sessão.

Este segundo comportamento é o que causa problemas num servidor remoto. Uma execução não assistida que atinja o limite para e fica à espera de uma pessoa que não está a acompanhar o terminal. Restringir o objetivo do agente é a outra parte da solução. Uma skill que orienta o agente para a alteração mínima que resolve o problema evita que a sessão avance para ações extensas que o classificador bloqueia.

Onde os modos ficam em settings.json

Tudo o que foi apresentado acima é um objeto num ficheiro de definições.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

As regras são avaliadas por ordem: negar, depois perguntar e, por fim, permitir. A primeira correspondência nessa ordem determina o resultado. Uma regra mais específica não se sobrepõe a uma regra mais abrangente que apareça antes. Uma regra de negação para Bash(aws *) bloqueia aws s3 ls, mesmo que também tenha permitido esse comando exato. Por isso, uma regra de negação não pode ter exceções.

ask é o tipo de regra que justifica a sua utilização no modo automático. O modo automático elimina o pedido de confirmação habitual. Uma regra ask adiciona novamente esse pedido para o comando específico que pretende que uma pessoa autorize. O seu comando de deploy deve ficar aí. O mesmo se aplica a Bash(git push *) se quiser um ponto de verificação antes de o código sair do servidor. Manter os ficheiros de credenciais em deny é a outra parte dessa configuração. Isto combina com manter as credenciais fora do alcance de um agente.

Os próprios ficheiros de definições, por ordem crescente de precedência:

• ~/.claude/settings.json: as suas definições de utilizador, aplicadas em todos os projetos.
• .claude/settings.json: as definições do projeto, submetidas ao repositório.
• .claude/settings.local.json: as suas próprias definições para um repositório, ignoradas pelo git.
• Definições geridas, implementadas por um administrador. No Linux, esse ficheiro é /etc/claude-code/managed-settings.json. Nada substitui uma regra de permissões gerida, incluindo um sinalizador da linha de comandos.

Existe aqui uma armadilha com uma causa documentada. defaultMode: "auto" é ignorado quando vem de .claude/settings.json ou .claude/settings.local.json, a partir de Claude Code v2.1.142, para impedir que um repositório ative o modo automático através de um ficheiro de definições. Se o definir aí, a sessão inicia no modo default sem apresentar qualquer erro. Mova a linha para ~/.claude/settings.json. Execute /permissions para listar todas as regras ativas juntamente com o ficheiro de onde vieram.

Os dois switches que desativam um modo

Os administradores têm dois switches de desativação, e ambos aceitam a string "disable" em vez de um valor booleano.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

A documentação especifica exatamente onde os deve colocar:

Para impedir a utilização do modo bypassPermissions ou auto, defina permissions.disableBypassPermissionsMode ou permissions.disableAutoMode como "disable" em qualquer ficheiro de definições. Estas opções são mais úteis em definições geridas, onde não podem ser substituídas.

disableAutoMode remove auto do ciclo Shift+Tab e rejeita --permission-mode auto no arranque. disableBypassPermissionsMode faz o mesmo para o modo de bypass e funciona a partir de qualquer âmbito. Assim, pode defini-lo no seu próprio ~/.claude/settings.json para impedir o acesso a um modo que prefere não ativar às 2am num servidor em produção. Num sistema utilizado por outras pessoas, coloque ambos em /etc/claude-code/managed-settings.json, porque um ficheiro de definições do utilizador pertence ao utilizador, enquanto um ficheiro gerido não pertence.

Por que o modo automático numa VPS precisa de um limite de isolamento

O classificador analisa uma ação de cada vez. Não controla o que uma ação aprovada faz depois. A documentação estabelece claramente o limite:

O classificador é um controlo por ação, não um limite de isolamento. Por isso, um limite de isolamento continua a fornecer defesa em profundidade para execuções não assistidas e não é necessário da mesma forma que para --dangerously-skip-permissions.

Por isso, a combinação adequada para um servidor remoto é o modo automático com um ambiente que esteja disposto a perder, não bypassPermissions com esperança. O modo de bypass está documentado apenas para ambientes isolados: contentores, máquinas virtuais ou dev containers sem acesso à Internet, onde o Claude Code não pode danificar o sistema anfitrião. Uma VPS que executa a sua base de dados e o seu reverse proxy não se enquadra em nenhum desses casos.

Num servidor, três medidas são especialmente importantes. Execute o Claude Code como um utilizador normal, nunca como root. Dê a esse utilizador um diretório de trabalho e nada mais que valha a pena ler. Recrie o servidor em vez de o reparar. É esse o motivo para usar uma VM descartável que elimina depois de cada tarefa. Os detalhes de hardening associados a estas medidas, desde a criação do utilizador até às regras da firewall, estão descritos em o procedimento completo de segurança para executar o Claude Code numa VPS, por isso não são repetidos aqui.

O Claude Code aplica a regra relativa a root. No Linux e no macOS, recusa iniciar em modo de bypass com sudo ou como root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Essa verificação é ignorada dentro de um sandbox reconhecido. Por isso, a resposta documentada para executar o agente autonomamente num contentor é usar um dev container que execute o Claude Code como um utilizador que não seja root. Se controlar o agente a partir de um telemóvel ou de um portátil através de SSH, o mesmo princípio aplica-se a uma sessão prolongada do Claude Code mantida aberta no tmux: ninguém acompanha o prompt enquanto a sessão está em execução.

Configurar o sandbox do Bash numa VPS Ubuntu

O sandbox integrado restringe o acesso ao sistema de ficheiros e à rede de todos os comandos Bash executados pelo Claude, e o sistema operativo aplica essas restrições também aos processos filhos. No Linux, são necessários dois pacotes.

sudo apt-get install bubblewrap socat

Inicie o Claude Code e execute /sandbox. O painel abre com um separador Mode e um separador Overrides, além de um separador Dependencies que lista tudo o que está em falta. A verificação de dependências é executada no arranque. Por isso, reinicie o Claude Code depois de instalar os pacotes. Caso contrário, o painel continuará a indicá-los como ausentes.

No Ubuntu 24.04 e posteriores, a política AppArmor predefinida impede que o bubblewrap crie os namespaces de utilizador de que necessita. Por isso, o sandbox não inicia. Verifique se isso se aplica ao seu servidor:

sysctl kernel.apparmor_restrict_unprivileged_userns

Um 0, ou um erro a indicar que a chave não existe, significa que não é necessária nenhuma ação. Um 1 significa que bwrap precisa do seu próprio perfil:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

O perfil aplica-se ao próprio bwrap, não aos comandos que este executa dentro do sandbox. Depois, reduza o limite nas definições:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Esse bloco deve ficar no .claude/settings.json do projeto, porque . só resolve para a raiz do projeto nas definições do projeto. Coloque as mesmas linhas em ~/.claude/settings.json e . resolverá para ~/.claude. Assim, a regra denyRead mantém os ficheiros do projeto bloqueados e todos os comandos falham ao tentar ler o código que deveriam editar.

Tenha em atenção o que isto não abrange. O sandbox restringe o Bash e os respetivos processos filhos. As ferramentas de ficheiros integradas são executadas dentro do processo do Claude Code, enquanto os servidores MCP (model context protocol) e os hooks são processos separados que são executados sem restrições no host. Para colocar todos atrás do mesmo limite, execute todo o processo do Claude Code dentro de um contentor, de uma máquina virtual ou do pacote @anthropic-ai/sandbox-runtime, que, no momento da redação, é uma versão de pré-visualização beta para investigação.

Que modo é adequado para cada configuração?

Um repositório isolado no seu próprio portátil

Use auto, com regras ask para as ações que pretende permitir. Está ao teclado, o fallback do classificador consegue efetivamente chegar até si e os danos ficam limitados a uma máquina que controla. Foi para este caso que o predefinido de 14 August foi definido.

Um VPS partilhado

Use auto por utilizador, definido no próprio ~/.claude/settings.json de cada utilizador, num sistema em que a conta que executa o Claude Code não é root e não consegue ler o trabalho dos outros utilizadores. Configure disableBypassPermissionsMode como "disable" em /etc/claude-code/managed-settings.json, juntamente com as regras de negação que protegem os caminhos partilhados. Um sistema partilhado é o caso mais claro em que bypassPermissions está errado, porque o limite de isolamento assumido por esse modo não existe: os outros utilizadores estão dentro dele.

CI e sessões não interativas

Use dontAsk com uma lista allow explícita dos comandos de que o job precisa. A negação automática é o comportamento correto quando nenhuma pessoa verá um prompt. O modo automático também é executado de forma não interativa, mas bloqueios repetidos do classificador interrompem uma sessão -p, pelo que um job que os atinja falha a meio, com o trabalho parcialmente concluído. Mantenha bypassPermissions num contentor ou numa máquina virtual que reconstrói a partir de uma imagem e não o utilize em nenhum host que também execute algo importante para si.

FAQ

Quando o modo automático passa a ser o modo predefinido no Claude Code?

A partir de 14 August 2026, para novas sessões nos planos Pro, Max e Team. A documentação acrescenta que pode mudar de modo a qualquer momento, que uma predefinição definida por si permanece ativa, exceto se aceitar o aviso de mudança única, e que uma predefinição gerida pela sua organização não é alterada. O anúncio indica que o modo automático continua opcional nos planos Enterprise e nas contas que usam a API durante a primeira parte da implementação. Verifique o modo efetivo da sessão na barra de estado, que apresenta ⏵⏵ auto mode on no modo automático.

Devo usar o modo automático ou bypassPermissions num VPS?

Use o modo automático com um limite de isolamento. O classificador analisa cada ação antes da execução, mas a documentação deixa claro que este é um controlo por ação, não um limite de isolamento. Por isso, uma execução sem supervisão continua a exigir um container, uma máquina virtual ou um sistema que esteja preparado para reconstruir. bypassPermissions ignora completamente as verificações e está documentado apenas para ambientes isolados. O Claude Code recusa iniciar nesse modo como root no Linux e apresenta --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

Como impeço qualquer pessoa no meu servidor de usar o modo automático ou o modo bypass?

Defina permissions.disableAutoMode e permissions.disableBypassPermissionsMode com a string "disable" em /etc/claude-code/managed-settings.json. As definições geridas têm precedência sobre todos os outros âmbitos. Por isso, nenhum ficheiro de definições do utilizador nem nenhuma flag da linha de comandos as pode substituir. disableAutoMode remove auto do ciclo Shift+Tab e rejeita --permission-mode auto no arranque. disableBypassPermissionsMode também funciona a partir de qualquer âmbito, pelo que um único utilizador pode defini-lo no seu próprio ~/.claude/settings.json.

Por que motivo a minha definição defaultMode: "auto" é ignorada?

Porque está no ficheiro errado. A partir do Claude Code v2.1.142, defaultMode: "auto" é ignorado quando vem de .claude/settings.json ou .claude/settings.local.json, para impedir que um repositório ative o modo automático por incluir um ficheiro de definições. A sessão inicia no modo default e não apresenta nenhum erro. Mova a definição para ~/.claude/settings.json e execute /permissions para confirmar de que ficheiro veio cada regra ativa. Se o modo automático continuar indisponível, verifique o requisito do modelo: modelos mais antigos, como Sonnet 4.5, não são suportados em nenhum fornecedor.