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

O que o modo automático altera em 14 August 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 revisão. A partir de 14 August 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 August 2026, o modo automático torna-se 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, exceto se aceitar o pedido de alteração apresentado uma única vez; uma predefinição gerida pela sua organização não é alterada.

Duas cláusulas são mais importantes do que a data. Um defaultMode definido no seu próprio ficheiro de definições mantém-se após a 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 ela entrar em vigor. Um pedido de permissão é um ponto de controlo que requer uma pessoa ao teclado. Num servidor remoto, normalmente não está presente. Por isso, o modo com que uma sessão começa é o modo que se mantém durante horas.

Os modos de permissão do Claude Code, do maior para o menor controlo

Existem seis modos. O nome no início de cada linha é o valor que escreve nas definições ou passa a --permission-mode. Os seis modos são aplicados pelo próprio Claude Code, e não pelo modelo, porque decidir o que uma chamada de ferramenta pode fazer é a função do harness que envolve o modelo.

• default: o Claude pergunta antes de cada novo uso de ferramenta. As leituras dentro do 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 sistema, mas não edita o 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 diretório de trabalho ou do seu additionalDirectories. Todos os outros comandos da shell continuam a pedir confirmação.
• auto: tudo é executado, depois de o classificador verificar cada ação. As regras explícitas ask continuam a exigir confirmação.
• dontAsk: o Claude Code rejeita automaticamente tudo o que exigiria uma confirmação. Apenas as regras allow, os comandos Bash incorporados e só de leitura e as chamadas aprovadas por um hook PreToolUse são executados. A sessão nunca aguarda 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 a cinzento. Por predefinição, os outros modos não fazem parte desse ciclo. auto é adicionado 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 o motivo pelo qual não aparece. Em agosto de 2026, a documentação indica 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. Estes são os controlos que permanecem ativos, 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 foi pedido. A documentação descreve a função numa frase:

Um modelo de classificação separado analisa as ações antes de serem executadas e bloqueia tudo o que ultrapassa o pedido, visa uma infraestrutura não reconhecida ou parece resultar de conteúdo malicioso lido pelo Claude.

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

• Transferência e execução de código, como curl | bash
• Deploys e migrações em produção
• Force push
• Modificação de infraestrutura partilhada
• Abertura de um túnel ou reverse shell que torna um serviço local acessível a partir da Internet pública
• Impressão de uma credencial ou token ativo no transcript ou num ficheiro

Permitido por predefinição:

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

Não trabalhe com base num resumo como o anterior. Execute claude auto-mode defaults para imprimir as listas completas de regras em JSON e leia o conjunto incluído na versão instalada.

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. Por isso, o texto dentro de um ficheiro ou de uma página Web lida pelo Claude não consegue comunicar 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 é suspenso e o Claude Code volta a pedir-lhe 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. Nesse caso, bloqueios repetidos abortam a sessão.

Esse segundo comportamento é o que causa problemas num servidor remoto. Uma execução não supervisionada que atinge o limite para e fica à espera de uma pessoa que não está a olhar para o terminal. Uma segunda sessão do Claude Code no mesmo servidor não substitui essa pessoa, porque o texto enviado de uma sessão para outra fica retido até a sessão recetora o recolher, e uma sessão parada num pedido de permissão continua a precisar de uma resposta humana. Restringir o que o agente se propõe fazer é a outra parte da solução, e uma skill que orienta o agente para a alteração mínima que funciona impede que uma sessão avance para as ações abrangentes que o classificador interrompe. Enquanto uma skill orienta uma tarefa, um estilo de saída edita o próprio system prompt, pelo que um estilo que pede alterações pequenas e cirúrgicas se aplica a todas as interações da sessão, e não apenas à tarefa para a qual o invocou.

Onde os modos ficam em settings.json

Tudo o que foi descrito acima corresponde a um objeto no 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 prevalece sobre uma regra mais abrangente que apareça antes dela. 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 torna o modo automático útil. O modo automático elimina a confirmação de rotina, e uma regra ask volta a exigir confirmação para o comando específico que quer submeter à aprovação de uma pessoa. O comando de deployment deve ficar aí. O mesmo se aplica a Bash(git push *), se quiser um ponto de controlo 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 desde o início.

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

• ~/.claude/settings.json: as definições do seu 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 uma opção da linha de comandos.

Existe aqui uma armadilha com uma causa documentada. defaultMode: "auto" é ignorado quando provém de .claude/settings.json ou .claude/settings.local.json, a partir do Claude Code v2.1.142, para impedir que um repositório ative o modo automático ao incluir um ficheiro de definições. Se o definir nesse local, 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 origem.

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 booleano.

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

A documentação especifica exatamente onde os definir:

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

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 bloquear o acesso a um modo que prefere não utilizar às 2am num servidor em produção. Num servidor utilizado por outras pessoas, coloque ambos em /etc/claude-code/managed-settings.json. 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 acrescentar defesa em profundidade às execuções não supervisionadas e não é necessário da mesma forma que para --dangerously-skip-permissions.

Assim, a combinação adequada para um sistema remoto é o modo automático com um ambiente que esteja disposto a perder, e 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, nos quais o Claude Code não pode danificar o sistema anfitrião. Uma VPS que executa a sua base de dados e o reverse proxy não corresponde a nenhum desses casos.

Três medidas são as mais importantes num servidor. 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 sistema em vez de o reparar. Esse é o motivo para usar uma VM descartável que elimina depois de cada tarefa. Os detalhes de hardening dessas medidas, desde a criação do utilizador até às regras da firewall, estão descritos em o guia completo de segurança para executar o Claude Code numa VPS, por isso não são repetidos aqui.

O Claude Code impõe a regra relativa a root. No Linux e no macOS, recusa iniciar no 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 uma sandbox reconhecida. Por isso, a resposta documentada para executar trabalho autónomo em contentores é um dev container que execute o Claude Code como um utilizador não root. Se controlar o agente a partir de um telemóvel ou portátil através de SSH, o mesmo raciocínio aplica-se a uma sessão prolongada do Claude Code mantida aberta no tmux: ninguém está a observar o prompt enquanto a sessão decorre. Nada começa enquanto o próprio login não funcionar. Por isso, se o sistema rejeitar a ligação com Permission denied (publickey), a saída detalhada do SSH indicará qual dos cinco problemas está realmente a ocorrer.

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 os separadores Mode e Overrides, além de um separador Dependencies que lista tudo o que estiver em falta. A verificação das dependências é feita no arranque. Por isso, reinicie o Claude Code depois de instalar os pacotes, caso contrário o painel continuará a indicar que estão ausentes.

No Ubuntu 24.04 e posteriores, a política AppArmor predefinida impede o bubblewrap de criar os user namespaces necessários. Por isso, o sandbox não consegue arrancar. 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ário fazer nada. 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 ele executa dentro do sandbox. Em seguida, reduza o limite nas definições:

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

Esse bloco pertence ao .claude/settings.json do projeto, porque . só é resolvido para a raiz do projeto nas definições do projeto. Se colocar as mesmas linhas em ~/.claude/settings.json, . será resolvido para ~/.claude. Nesse caso, 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 conta 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 estes componentes dentro 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 beta de investigação.

Que modo deve usar cada configuração?

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

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

Um VPS partilhado

Use auto por utilizador, configurado no próprio ~/.claude/settings.json de cada utilizador, num sistema onde a conta que executa o Claude Code não é root e não consegue ler o trabalho dos outros utilizadores. Disponibilize 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 pedido de confirmação. O modo automático também é executado de forma não interativa, mas os bloqueios repetidos do classificador interrompem uma sessão -p. Por isso, um job que os encontre falha a meio, com o trabalho incompleto. Reserve bypassPermissions para um contentor ou uma máquina virtual que reconstrói a partir de uma imagem, e não o use em nenhum host que também execute algo importante.

FAQ

Quando é que 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 fase da disponibilização. Para confirmar o modo efetivo de uma sessão, consulte a barra de estado, que mostra ⏵⏵ 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 e 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 todas 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 opção 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. Isto impede que um repositório ative o modo automático para si próprio ao distribuir 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 provider.