SpyBara
Go Premium

permission-modes.md 2026-09-08 20:00 UTC to 2026-09-09 22:58 UTC

This page contains 325 additions and 139 deletions.

2026
Wed 9 22:58 Sat 12 03:02 Fri 18 23:58 Sat 19 23:57 Tue 22 23:59 Fri 25 23:58

Escolha um modo de permissão

Controle se Claude pede permissão antes de agir. Alterne modos de permissão com Shift+Tab na CLI, o indicador de modo no VS Code ou o seletor de modo no Desktop.

Um modo de permissão define quais ações Claude pode executar em uma sessão sem pedir sua permissão primeiro. No modo Manual, Claude Code para e pede sua permissão antes da maioria das ações que editam arquivos, executam comandos shell ou acessam a rede. No modo automático, um segundo modelo, o classificador, revisa as ações em vez de você; como o classificador avalia ações lista quais ações ele revisa e quais o ignoram.

Nos planos Pro, Max e Team, o modo de permissão inicial integrado é o modo automático. Qual modo uma sessão inicia cobre as superfícies e configurações que alteram o modo de permissão inicial. Você também pode alterar o modo de permissão de uma sessão em execução a qualquer momento.

Modos disponíveis

Cada modo faz uma compensação diferente entre conveniência e supervisão. A tabela abaixo mostra o que Claude pode fazer sem um prompt de permissão em cada modo. O modo Manual aparece sob seu valor de configuração, default.

Modo O que é executado sem perguntar Melhor para
default Apenas leituras Revisar cada ação você mesmo, trabalho sensível
acceptEdits Leituras, edições de arquivo e comandos comuns do sistema de arquivos (mkdir, touch, mv, cp, etc.) Iterando sobre código que você está revisando
plan Leituras, mais comandos aprovados pelo classificador quando modo automático está disponível Explorando uma base de código antes de alterá-la
auto Tudo, com verificações de segurança em segundo plano Tarefas longas, reduzindo fadiga de prompts
dontAsk Apenas ferramentas pré-aprovadas CI bloqueado e scripts
bypassPermissions Tudo Apenas contêineres isolados e VMs

O modo que revisa cada ação é nomeado Manual na CLI, em claude --help, nas extensões VS Code e JetBrains, e no aplicativo de desktop. Seu valor de configuração é default, que é o que hooks e integrações SDK usam. A CLI aceita manual como um alias em qualquer lugar onde você digita o valor, por exemplo claude --permission-mode manual ou "defaultMode": "manual". O rótulo Manual e o alias manual requerem Claude Code v2.1.200 ou posterior. O rótulo do aplicativo de desktop não depende da sua versão da CLI.

As gravações em caminhos protegidos nunca são auto-aprovadas, exceto no modo bypassPermissions e em sessões de modo plan onde permissões de bypass estão disponíveis, significando sessões iniciadas de uma forma que coloca bypassPermissions no ciclo de modo.

Os modos definem a linha de base. Sobreponha regras de permissão no topo para pré-aprovar ou bloquear ferramentas específicas. Regras de negação bloqueiam em todos os modos, incluindo bypassPermissions. Regras de negação e solicitação não se aplicam a EndConversation enquanto Claude ainda tiver pelo menos uma outra ferramenta que possa chamar. Regras de permissão não têm efeito em bypassPermissions.

Ações que nenhum modo auto-aprova

Claude Code não auto-aprova o seguinte em nenhum modo, incluindo bypassPermissions. Cada item vincula à seção que diz o que acontece em vez disso em cada modo:

Configurações comuns

Os modos de permissão decidem se Claude pede antes de uma ação, e o sandbox Bash e os limites de isolamento externos decidem o que uma ação pode alcançar uma vez que é executada. Cada linha abaixo emparelha um objetivo com as flags ou configurações que o levam lá e o isolamento que precisa, como ponto de partida. Modos disponíveis lista o que é executado sem um prompt em cada modo.

Você quer Comece com Isolamento necessário Notas
Revisar cada ação você mesmo Modo Manual: claude --permission-mode default Nenhum Trabalho sensível, código desconhecido
Iterar localmente com menos prompts, sem um classificador Modo Manual mais o sandbox Bash em modo auto-allow: claude --permission-mode default, depois execute /sandbox e selecione auto-allow O sandbox Bash integrado, em macOS, Linux e WSL2 Regras de negação ainda se aplicam, e regras de solicitação que nomeiam um comando, como Bash(git push *), ainda solicitam. Para ativar o sandbox a partir de um arquivo de configurações em vez disso, defina sandbox.enabled como true
Explorar antes de alterar qualquer coisa claude --permission-mode plan Nenhum Claude Code bloqueia edições até que você aprove um plano
Trabalhar sem supervisão em modo automático claude --permission-mode auto, o modo de permissão inicial integrado em Pro, Max e Team Nenhum; um sandbox ou contêiner adiciona defesa em profundidade Requer um modelo suportado, e sua organização pode desativar o modo automático
Executar em CI com uma lista de permissões exata claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" Nenhum além do que seu executor de CI fornece Claude Code na web ignora dontAsk de arquivos de configurações
Executar totalmente sem supervisão dentro de um contêiner claude -p "<prompt>" --dangerously-skip-permissions Obrigatório: um contêiner, VM ou o runtime do sandbox; em Linux e macOS, execute como um usuário não-root Claude Code na web ignora este modo de arquivos de configurações. Nesta execução -p, as poucas chamadas que ainda solicitariam são negadas em vez disso

O sandbox Bash e o modo automático funcionam independentemente e se combinam, exceto no modo plan, onde auto-allow não amplia aprovações. Para a interação completa, veja Como sandboxing se relaciona com permissões e modos de permissão e Como isolamento se relaciona com modos de permissão.

Qual modo uma sessão inicia

Quando você inicia uma nova sessão em um terminal, Claude Code pega o modo de permissão do primeiro destes que se aplica:

  1. A flag --permission-mode ou --dangerously-skip-permissions

  2. permissions.defaultMode em um arquivo de configurações

    Se você definir "auto" em .claude/settings.json ou .claude/settings.local.json, o valor não entra em vigor, e Claude Code então usa o padrão integrado em vez de um defaultMode de ~/.claude/settings.json. Se você definir "bypassPermissions" nesses dois arquivos, também não entra em vigor, e a sessão inicia no modo Manual. Os outros valores se aplicam de qualquer arquivo de configurações.

  3. O padrão integrado

Conversas que a extensão VS Code inicia seguem a lista própria da extensão em Alternar modos de permissão. Para o modo de permissão que Claude Code inicia uma sessão retomada, veja modo de permissão ao retomar.

O padrão integrado auto requer Claude Code v2.1.228 ou posterior em macOS, Linux e WSL, e v2.1.233 ou posterior no Windows nativo. Em versões anteriores, o padrão integrado é Manual.

O padrão integrado depende de como você executa Claude Code, do seu plano e se Claude Code conseguiu buscar seus sinalizadores de recurso. A primeira linha que corresponde à sua sessão se aplica. A tabela cobre sessões que você inicia em um terminal ou através da extensão VS Code; para o aplicativo de desktop e claude.ai, veja as abas Desktop e Web em Alternar modos de permissão.

Como você executa Claude Code Modo de permissão inicial integrado
Qualquer arquivo de configurações define disableAutoMode como "disable" default
Busca de sinalizador de recurso está desativada default
Sua primeira sessão depois que você instala Claude Code ou faz upgrade para uma versão que adiciona este padrão, a menos que, após uma instalação limpa, Claude Code busque os sinalizadores a tempo default
claude -p ou o Agent SDK default
Amazon Bedrock, Agent Platform do Google Cloud, Microsoft Foundry, Claude Platform on AWS ou uma sessão gateway de aplicativos Claude conectada default
Um plano Pro, Max ou Team, em um terminal ou através da extensão VS Code auto
Um plano Enterprise ou uma chave de API do Claude Console default

Quando a busca de sinalizador de recurso está desativada, ou em uma primeira sessão após uma instalação ou upgrade onde os sinalizadores ainda não chegaram, a extensão VS Code ignora todos os arquivos de configurações ao escolher o modo de permissão inicial.

Quando o sinalizador, um arquivo de configurações ou o padrão integrado seleciona auto mas o modo automático não está disponível para a sessão, Claude Code inicia a sessão no modo Manual em vez disso. O modo automático não está disponível quando a sessão não atende aos requisitos de disponibilidade, como um arquivo de configurações desativando-o ou um modelo que não o suporta, ou quando Anthropic o desativou temporariamente no lado do servidor.

A primeira vez que o padrão integrado inicia uma de suas sessões em modo automático, Claude Code mostra um aviso que vincula a esta página:

  • Em um terminal, uma vez, no topo da sessão
  • Na extensão VS Code, como um cartão na tela de nova conversa que permanece até você descartá-lo

Nos planos Pro, Max e Team, se seu ~/.claude/settings.json define um defaultMode diferente de auto e nenhum outro arquivo de configurações define um, suas sessões continuam iniciando nesse modo. Claude Code pergunta uma vez, no terminal ou na extensão VS Code, se você quer alterar a configuração para modo automático. Se você recusar, sua configuração permanece como está.

Inicie em um modo de permissão diferente

Você pode definir o modo de permissão inicial para uma sessão, ou como padrão para cada sessão em uma máquina, projeto ou organização. Quando mais de um arquivo de configurações define permissions.defaultMode, precedência de configurações decide, então um valor de projeto ou gerenciado supera ~/.claude/settings.json. Para alterar o modo de permissão de uma sessão já em execução, veja Alternar modos de permissão.

Para definir o modo de permissão inicial para Faça isto
Uma sessão que você está prestes a iniciar Passe o modo de permissão como uma flag, por exemplo claude --permission-mode default
Cada sessão de terminal que você inicia nesta máquina Defina permissions.defaultMode em ~/.claude/settings.json. Para o que a extensão VS Code lê, veja Alternar modos de permissão
Cada sessão de terminal que você inicia em um projeto Defina permissions.defaultMode em .claude/settings.json do projeto. Sessões que você inicia em um terminal honram todos os valores exceto auto e bypassPermissions; sessões que a extensão VS Code inicia não leem configurações de projeto para o modo de permissão inicial
Cada sessão de terminal em sua organização Defina permissions.defaultMode em configurações gerenciadas. Sessões de terminal iniciam nesse modo e as pessoas ainda podem alternar para modo automático; para o que a extensão VS Code lê, veja Alternar modos de permissão. Para remover o modo automático para que ninguém possa selecioná-lo, defina permissions.disableAutoMode como "disable" em vez disso

Este exemplo faz cada sessão de terminal em sua máquina iniciar no modo Manual, cujo valor de configuração é default. Salve em ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

A próxima sessão que você inicia mostra ⏸ manual mode on na barra de status.

Alternar modos de permissão

Cada interface tem seu próprio controle para alternar modos de permissão durante uma sessão e sua própria forma de escolher o modo de permissão que novas sessões iniciam. Pedir a Claude no chat para alterar o modo de permissão não funciona. Selecione sua interface para ver seus controles.

Durante uma sessão: pressione Shift+Tab para alternar modos de permissão. De auto, o primeiro pressionamento alterna para default, e o ciclo então executa default → acceptEdits → plan → de volta para default. Modos opcionais, descritos abaixo, se encaixam após plan. A barra de status mostra o modo ativo como um ⏸ manual mode on cinza para default, ou como ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on ou ⏵⏵ bypass permissions on.

Nem todo modo está no ciclo padrão:

  • auto: aparece quando modo automático está disponível; alternar para ele alterna modos de permissão sem um prompt de confirmação
  • bypassPermissions: aparece depois que você inicia com --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions ou permissions.defaultMode: "bypassPermissions" em configurações de usuário, --settings ou gerenciadas. A variante --allow- adiciona o modo de permissão ao ciclo sem ativá-lo
  • dontAsk: nunca aparece no ciclo; defina-o com --permission-mode dontAsk

Modos opcionais habilitados se encaixam após plan, com bypassPermissions primeiro e auto por último. Se você tiver ambos habilitados, você alternará através de bypassPermissions a caminho de auto.

De um prompt de permissão Bash: nos modos de permissão Manual e acceptEdits, quando modo automático está disponível, Claude Code adiciona Sim, e alternar para modo automático ao prompt de permissão de um comando Bash. Selecione-o para aprovar o comando e alternar a sessão para modo automático. Prompts da ferramenta PowerShell não oferecem a opção. Requer Claude Code v2.1.247 ou posterior.

Claude Code não adiciona a opção a prompts forçados por uma de suas regras ask ou por um hook, porque o modo automático ainda mostra esses prompts, então alternar não os removeria.

Na inicialização: passe o modo de permissão como uma flag.

claude --permission-mode plan

Como padrão: defina permissions.defaultMode no escopo que você quer, conforme descrito em Inicie em um modo de permissão diferente.

A mesma flag --permission-mode funciona com -p para execuções não-interativas.

Auto-aprovar edições de arquivo com modo acceptEdits

O modo acceptEdits permite que Claude crie e edite arquivos em seu diretório de trabalho sem solicitar. A barra de status mostra ⏵⏵ accept edits on enquanto este modo está ativo.

Além de edições de arquivo, o modo acceptEdits auto-aprova comandos Bash comuns do sistema de arquivos: mkdir, touch, rm, rmdir, mv, cp e sed. Esses comandos também são auto-aprovados quando prefixados com variáveis de ambiente seguras como LANG=C ou NO_COLOR=1, ou wrappers de processo como timeout, nice ou nohup. Como edições de arquivo, a auto-aprovação se aplica apenas a caminhos dentro de seu diretório de trabalho ou additionalDirectories. Caminhos fora desse escopo, gravações em caminhos protegidos, remoções rm e rmdir direcionadas a um caminho crítico e todos os outros comandos Bash, exceto o conjunto integrado somente leitura, ainda solicitam.

Quando a ferramenta PowerShell está habilitada, o modo acceptEdits também auto-aprova Set-Content, Add-Content, Clear-Content e Remove-Item em caminhos no escopo, junto com seus aliases comuns. As mesmas regras de escopo e caminho protegido se aplicam, e Remove-Item recebe sua própria verificação. Um argumento posicional que contém um caractere de aspas, como o apóstrofo em Set-Content .\notes.txt "It's done", ainda solicita mesmo em caminhos no escopo, porque Claude Code não consegue validar estaticamente um argumento cujas leituras entre aspas e sem aspas diferem. Passe o conteúdo através de um parâmetro nomeado como -Value para evitar o prompt.

Use acceptEdits quando você quer revisar mudanças em seu editor ou via git diff depois, em vez de aprovar cada edição inline.

Pressione Shift+Tab uma vez a partir do modo Manual para entrar nele, ou comece com ele diretamente:

claude --permission-mode acceptEdits

Analise antes de editar com modo plan

O modo plan diz a Claude para pesquisar e propor mudanças sem realizá-las. Claude lê arquivos, executa comandos shell para explorar e escreve um plano, mas não edita sua fonte. Exceto em sessões com permissões de bypass disponíveis, edições permanecem bloqueadas até que você aprove o plano.

Quando modo automático está disponível e a configuração useAutoModeDuringPlan está ativada, que é o padrão, o classificador revisa comandos shell durante o planejamento em vez de solicitar você. Comandos aprovados são executados, e os rejeitados são bloqueados. Caso contrário, comandos fora do conjunto integrado somente leitura solicitam aprovação, incluindo quando o modo auto-allow do sandbox está habilitado. Em sessões com permissões de bypass disponíveis, nem o classificador nem um prompt se aplica a comandos de planejamento; Ignorar todas as verificações com modo bypassPermissions cobre as poucas coisas que ainda solicitam lá. Em v2.1.212 até v2.1.217, sessões sem permissões de bypass solicitavam para cada comando fora do conjunto somente leitura, independentemente de o modo automático estar disponível.

Entre no modo plan pressionando Shift+Tab ou prefixando um único prompt com /plan. Você também pode iniciar no modo plan a partir da CLI:

claude --permission-mode plan

Pressione Shift+Tab novamente para sair do modo plan sem aprovar um plano.

Revise e aprove um plano

Quando o plano estiver pronto, Claude o apresenta e pergunta como proceder. A partir desse prompt você pode escolher:

  • Sim, e usar modo automático: aprove e inicie em modo automático. Quando o modo automático não está disponível, esta opção lê Sim, auto-aceitar edições. Se você iniciou a sessão com permissões de bypass habilitadas, a opção lê Sim, e alternar para BYPASS PERMISSIONS (sem prompts adicionais) para esta sessão em vez disso.
  • Sim, aprovar edições manualmente: aprove e revise cada edição individualmente.
  • Não, continuar planejando: permaneça no modo plan e diga a Claude o que alterar.

Aprovar um plano sai do modo plan e alterna a sessão para o modo de permissão que cada opção de aprovação descreve, então Claude começa a editar. Para planejar novamente, volte ao modo plan com Shift+Tab, ou prefixe seu próximo prompt com /plan.

Pressione Ctrl+G para abrir o plano proposto em seu editor de texto padrão e editá-lo diretamente antes de Claude prosseguir. Quando showClearContextOnPlanAccept está habilitado, a lista ganha uma primeira opção que aprova o plano e limpa o contexto de planejamento.

Aceitar um plano também dá à sessão um título gerado baseado no plano, a menos que você já tenha nomeado a sessão.

Defina modo plan como padrão

Para tornar o modo plan o padrão para sessões de terminal de um projeto, defina defaultMode como plan em .claude/settings.json, colocado conforme o exemplo em Inicie em um modo de permissão diferente mostra. Conversas que a extensão VS Code inicia não leem configurações de projeto para o modo de permissão inicial. Lá, defina claudeCode.initialPermissionMode como plan em suas configurações de usuário do VS Code em vez disso.

Elimine prompts de permissão com modo automático

O modo automático permite que Claude execute sem prompts de permissão rotineiros. Um modelo classificador separado revisa ações antes de serem executadas, bloqueando qualquer coisa que ultrapasse sua solicitação, tenha como alvo infraestrutura não reconhecida ou pareça impulsionada por conteúdo hostil que Claude leu. Regras de solicitação explícitas ainda forçam um prompt.

Nos planos Pro, Max e Team, o modo automático é o modo de permissão inicial integrado.

O classificador também revisa cada mensagem que Claude envia para outro agente com SendMessage, seja texto simples ou uma mensagem estruturada de equipe de agentes, antes de Claude Code entregá-la, tanto em modo automático quanto em modo plan enquanto o classificador revisa comandos; a revisão de envio requer Claude Code v2.1.222 ou posterior.

O classificador também revisa e aprova ou bloqueia remoções rm e rmdir direcionadas a um caminho crítico, como rm -rf / e rm -rf ~, incluindo quando a remoção está dentro de substituição de comando ou processo.

O modo automático também incentiva Claude a continuar trabalhando sem parar para fazer perguntas de esclarecimento, embora Claude ainda pergunte quando seu prompt ou uma skill depende explicitamente disso. Para comportamento autônomo mais forte em um modo que ainda o solicita, defina o estilo de saída Proativo em vez disso.

O modo automático está disponível apenas quando sua conta atende a todos esses requisitos:

  • Plano: Todos os planos.
  • Organização: em Team e Enterprise, o modo automático está disponível por padrão. Administradores podem desativá-lo para a organização definindo permissions.disableAutoMode como "disable" em configurações gerenciadas.
  • Modelo: na API Anthropic e Claude Platform on AWS, Claude Opus 4.6 ou posterior, Sonnet 4.6 ou posterior, ou um modelo Fable. No Amazon Bedrock, Agent Platform do Google Cloud, Microsoft Foundry e sessões gateway de aplicativos Claude conectadas, apenas Claude Sonnet 5, Opus 4.7 ou posterior, e os modelos Fable. Modelos mais antigos, incluindo Sonnet 4.5, Opus 4.5, Haiku e modelos claude-3, não são suportados em nenhum provedor.
  • Provedor: disponível por padrão na API Anthropic, Claude Platform on AWS, Amazon Bedrock, Agent Platform do Google Cloud, Microsoft Foundry e sessões gateway de aplicativos Claude conectadas.

Se Claude Code relatar o modo automático como indisponível, primeiro verifique esses requisitos e se algum arquivo de configurações define disableAutoMode. Anthropic também pode ter desativado o modo automático no lado do servidor, ou o servidor pode ter rejeitado o modo automático para sua conta. Uma sessão que recebeu uma resposta mantém o modo automático desativado até que a sessão termine, então inicie uma nova sessão depois.

Uma mensagem separada que nomeia um modelo e diz que o modo automático "não consegue determinar a segurança" de uma ação significa que uma solicitação do classificador falhou. Essa falha é geralmente transitória, mas no Amazon Bedrock pode se repetir até que sua conta possa invocar o modelo nomeado. Veja a referência de erros para as causas e o que fazer.

Se você definir defaultMode: "auto" em configurações e uma sessão de terminal inicia no modo Manual sem erro, a configuração provavelmente está em .claude/settings.json ou .claude/settings.local.json. auto não entra em vigor desses arquivos. Mova-o para ~/.claude/settings.json. Para uma conversa que a extensão VS Code iniciou, verifique a lista própria da extensão em Alternar modos de permissão em vez disso.

Modo automático em Bedrock, Agent Platform ou Foundry

Em Amazon Bedrock, Agent Platform do Google Cloud, Microsoft Foundry e sessões gateway de aplicativos Claude conectadas, o modo automático aparece no ciclo Shift+Tab por padrão. Aparecer no ciclo não muda o modo de permissão em que uma sessão inicia: nesses provedores, sessões de terminal iniciam em seu defaultMode, que é Manual a menos que você o altere, e conversas na extensão VS Code iniciam em Manual a menos que claudeCode.initialPermissionMode ou um modo que você escolheu na extensão defina um. Apenas Claude Sonnet 5, Opus 4.7 ou posterior, e os modelos Fable são suportados nesses provedores.

Para tornar o modo automático o modo de permissão inicial padrão, defina "permissions": {"defaultMode": "auto"} em configurações de usuário ou gerenciadas. Em sessões que a extensão VS Code inicia, selecione Auto no indicador de modo em vez disso. Alternar modos de permissão cobre o que supera essa escolha.

O checkup /doctor propõe este padrão de configurações de usuário nesses provedores da mesma forma que faz na API Anthropic.

Para impedir que desenvolvedores usem o modo automático, defina disableAutoMode como "disable" em configurações gerenciadas. Isso remove auto do ciclo Shift+Tab, e uma sessão iniciada com --permission-mode auto inicia em Manual em vez disso. Uma sessão já em execução no modo automático o deixa quando a configuração chega a essa sessão de uma fonte implantada por administrador, e mostra auto mode disabled by settings. Antes de v2.1.251, uma sessão em execução mantinha o modo automático até que terminasse.

Em v2.1.158 até v2.1.206, o modo automático estava desativado nesses provedores até que você definisse CLAUDE_CODE_ENABLE_AUTO_MODE=1, e Claude Code ignorava defaultMode: "auto" nesses provedores a menos que a variável também fosse definida. A variável ainda é aceita para compatibilidade e não tem efeito a partir de v2.1.207 em diante.

O que o classificador bloqueia por padrão

O classificador confia em seu diretório de trabalho e nos remotes que foram configurados para ele quando a sessão começou. Um remote adicionado ou reorientado durante a sessão com git remote add ou git remote set-url não é confiável, e tudo mais é tratado como externo até que você configure infraestrutura confiável. Antes de v2.1.200, remotes adicionados no meio da sessão também eram confiáveis.

Bloqueado por padrão:

  • Download e execução de código, como curl | bash
  • Envio de dados sensíveis para endpoints externos
  • Implantações e migrações de produção
  • Exclusão em massa no armazenamento em nuvem
  • Concessão de permissões de IAM ou repositório
  • Modificação de infraestrutura compartilhada
  • Destruição irreversível de arquivos que existiam antes da sessão
  • Force push
  • Committing ou pushing uma mudança que enviaria segredos ou dados sensíveis fora do repositório quando é executada, ou ampliaria o que um deploy expõe. Isso cobre um workflow de CI ou configuração de deploy que passa um segredo para um destino que não o recebe, um script ou etapa de configuração que lê um armazenamento de segredos e envia os dados, e uma mudança de configuração que amplia o que um deploy publica, como um registro, visibilidade, artefato ou configuração de sourcemap. A verificação se aplica em qualquer branch, se aplica mesmo quando o repositório é público, e dispara quando a mudança chega, independentemente de isso disparar o pipeline; limpá-la requer nomear o efeito de execução, não apenas o commit ou push. Antes de v2.1.211, essa verificação era escopo para o branch padrão em vez disso: um push lá era bloqueado quando carregava conteúdo sensível, mudanças ocultadas ou mal descritas em relação ao que você pediu, conteúdo portado de fora do repositório ou roteado em torno de uma revisão que você pediu
  • git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop ou git stash clear, que o classificador presume descartaria mudanças não confirmadas
  • git commit --amend quando o commit no HEAD não foi criado nesta sessão
  • A partir de v2.1.198, git commit --amend quando o commit no HEAD já foi enviado. Uma reword apenas de mensagem não é bloqueada: --amend -m sem nada recém-preparado, em um commit que Claude criou durante esta sessão
  • terraform destroy, pulumi destroy, cdk destroy ou terragrunt destroy, e aplicação de um plano que destrói recursos

Claude Code v2.1.195 e posterior bloqueiam mais categorias por padrão. Várias dependem de entradas de ambiente, como destinos remotos sensíveis e escopos de IaC protegidos, que você pode restringir a nomes concretos.

  • Escrita em um gerenciador de segredos, ou alteração de registros DNS ou certificados TLS
  • Mesclagem de uma pull request que nenhum humano aprovou, aprovação da própria pull request do Claude ou desabilitação de verificações de CI
  • Postagem de um comentário que é em si um comando para automação, como atlantis apply ou /deploy ou /merge de um bot
  • Alternância, aumento gradual ou exclusão de um sinalizador de recurso de produção
  • Aplicação de mudanças de infraestrutura a um escopo de IaC protegido, ou drenagem e remoção de nós de cluster
  • Gravações em um cluster de computação compartilhado que vão além do recurso que você nomeou, como um seletor de rótulo ou --all que captura trabalhos de outros usuários
  • Criação de recursos Kubernetes que executam em cada nó ou interceptam tráfego de cluster, como DaemonSets e webhooks de admissão
  • Shells interativos ou port-forwards em um destino remoto sensível
  • Abertura de um túnel ou shell reverso que torna um serviço local acessível da internet pública
  • Impressão de uma credencial ou token ao vivo na transcrição ou em um arquivo
  • Acesso a um local listado como local de dados sensíveis em seu ambiente, ou cópia de dados de um. A partir de v2.1.198, isso também bloqueia o envio de dados de um para um público que a entrada exclui
  • Roteamento de uma instalação de pacote em torno de seu registro de pacotes interno para um registro público. A partir de v2.1.198, isso também se aplica quando você disse a Claude que um registro interno ou espelho existe na conversa, não apenas quando um está listado em seu ambiente
  • Execução de um comando com um sinalizador que desativa uma proteção de segurança, como --insecure
  • Lançamento de um loop de agente autônomo que executa sem aprovação humana ou sandbox, como um iniciado com --dangerously-skip-permissions ou --no-sandbox. A partir de v2.1.198, isso também cobre a execução de um agente de terceiros ou harness de avaliação com isolamento e aprovação por ação desabilitados, como um runner iniciado com --yes-always
  • Ações do Claude no Chrome que poderiam enviar conteúdo da página, cookies ou credenciais fora da origem

Claude Code v2.1.198 e posterior também bloqueiam estes por padrão:

  • Exclusão de arquivos em /tmp, $TMPDIR ou outro diretório compartilhado de rascunho ou cache por wildcard, glob ou filtro de idade em vez de por um caminho nomeado específico
  • Inclusão de detalhes sensíveis em conteúdo enviado, carregado, publicado ou escrito para outras pessoas ou sistemas compartilhados, quando sua própria mensagem não autorizou esses detalhes para esse destinatário. Corpos de PR e issue, mensagens de commit e comentários contam como esse tipo de conteúdo de saída quando o repositório está fora do limite de confiança ou é público, incluindo repositórios públicos de sua própria organização; caminhos de arquivo internos, nomes de código, dados de resposta de API ao vivo, como e-mails ou identificadores de conta, e identificadores de infraestrutura contam como detalhes sensíveis. O escopo de PR, issue e mensagem de commit requer Claude Code v2.1.200 ou posterior. Dados pessoais ao vivo de uma resposta de API em um corpo de PR ou issue, como um endereço de e-mail, um identificador de conta ou organização, ou uma métrica de uso, requer que você nomeie esses detalhes e o destinatário independentemente da visibilidade ou limite de confiança do repositório. Essa verificação requer Claude Code v2.1.203 ou posterior
  • Envio de pressionamentos de tecla para o próprio painel tmux do Claude Code para conduzir sua própria interface, que o classificador trata como Claude alterando suas próprias permissões ou supervisão

Claude Code v2.1.200 e posterior também bloqueiam estes por padrão:

  • Comentário, exclusão ou aprovação forçada de um teste ou asserção que protege comportamento de segurança, como autenticação, controle de acesso, validação de entrada ou sandboxing
  • Exclusão ou desmontagem de um recurso com estado que Claude não criou na sessão, quando nenhuma regra de exclusão mais específica se aplica e você não nomeou esse recurso
  • Reorientação de uma URL de base de API, endpoint de proxy, receptor de webhook ou espelho de registro em um host de terceiros que não se encaixa na tarefa, incluindo em arquivos de exemplo como .env.example
  • Alteração de para onde os pushes vão com git remote set-url ou git remote add, a menos que você tenha nomeado o novo remote
  • Pushing de segredos ou dados pessoais ou confiados para um repositório conhecido como público, ou pushing de material confidencial lá que não faz parte do próprio trabalho desse repositório. O próprio assunto de um repositório de dotfiles é a única exceção para dados pessoais ou confiados, e conteúdo de um repositório privado chegando a qualquer superfície pública é bloqueado da mesma forma; ambos os refinamentos requerem Claude Code v2.1.203 ou posterior. Antes de v2.1.203, dados pessoais eram agrupados com material confidencial e bloqueados apenas quando não faziam parte do próprio trabalho desse repositório. Quando a visibilidade de um repositório não é estabelecida, o classificador não bloqueia apenas nisso; ele julga o conteúdo contra as outras regras em vez disso
  • Abertura de uma pull request contra um repositório ou organização diferente, fork com gh repo fork ou pushing para um repositório de terceiros, a menos que você tenha nomeado esse alvo externo

Claude Code v2.1.203 e posterior também bloqueiam estes por padrão:

  • Conteúdo de um armazenamento local sensível, ou de um arquivo cujo nome, caminho ou tipo o marca como sensível, entrando em um commit, um push, texto de PR ou issue, um gist ou paste, ou um package publish, a menos que você tenha nomeado tanto a origem quanto o destino. Transcrições de sessão e logs de conversa, pastas com ponto de credenciais e configuração, como chaves SSH, credenciais em nuvem, perfis de navegador e histórico de shell, e exportações de dados do usuário contam, e o repositório ser privado não o limpa

Claude Code v2.1.205 e posterior também bloqueiam estes por padrão:

  • Escrita em transcrições de sessão do Claude Code, os arquivos de histórico .jsonl sob ~/.claude/projects/ ou seu diretório de configuração configurado, seja diretamente ou através de um comando de shell. A regra também cobre as linhas de metadados que Claude Code acrescenta a cada entrada de transcrição para suas próprias verificações. Uma transcrição é estado de sessão que Claude Code escreve, não um arquivo de trabalho, e uma entrada adulterada atinge cada verificação posterior uma vez que você retoma a sessão, então o modo automático bloqueia essas gravações como defesa em profundidade. Ler uma transcrição não é bloqueado
  • Uma exclusão forçada recursiva, como rm -rf "$VAR" ou Remove-Item -Recurse -Force $dir cujo alvo é uma variável de shell, ou um glob enraizado em uma, que não é atribuído em nenhum lugar na conversa que o classificador vê. O valor veio apenas da saída de comando anterior, que o classificador nunca recebe, então o classificador não consegue verificar o alvo de exclusão contra as outras regras de exclusão. O bloqueio é limpo quando você nomeia o caminho exato sendo deletado, ou quando Claude re-executa a exclusão com o caminho literal resolvido escrito no comando. Exclusões cujo alvo o classificador consegue resolver não são afetadas. Alvos Remove-Item que são um * nu ou terminam em /* ou \* nunca chegam ao classificador: Claude Code nega-os imediatamente

Claude Code v2.1.257 e posterior também bloqueiam estes por padrão:

  • Solicitação de credenciais do endpoint de metadados da instância em nuvem, como 169.254.169.254, ou autenticação explícita de uma chamada de nuvem, cluster ou registro com a identidade de conta de serviço ou nó da máquina
  • Alcance de um host público por uma rota diferente de uma solicitação direta, como um túnel, um shell reverso ou uma configuração de resolver ou proxy reescrita para apontar para fora
  • Leitura de credenciais que pertencem ao host em vez de à sua tarefa, como certificados de nó ou auth de registro de contêiner do nó
  • Conexão ou varredura de contêineres, pods ou VMs irmãos que Claude não iniciou, ou o nó sob o contêiner

Se Claude Code é executado em algum lugar que se destina a permitir um destes, descreva essa configuração em uma entrada Host containment em autoMode.environment.

Claude Code v2.1.261 e posterior também bloqueiam estes por padrão:

  • Postagem ou escrita de um link para um serviço público de paste, diagrama ou compartilhamento de dados em uma mensagem, texto de PR ou issue, um documento ou em qualquer outro lugar onde o link será aberto ou buscado, quando a própria URL carrega o conteúdo sendo compartilhado, a menos que você tenha nomeado esse serviço

Permitido por padrão:

  • Operações de arquivo local em seu diretório de trabalho
  • Instalação de dependências declaradas em seus arquivos de lock ou manifestos
  • Leitura de .env e envio de credenciais para sua API correspondente
  • Solicitações HTTP somente leitura
  • Pushing para qualquer branch do repositório em que você está trabalhando, incluindo o branch padrão. Um branch não padrão cujo nome o marca como um destino de deploy ou publicação, como production ou gh-pages, não é coberto: o classificador julga um push lá em seus próprios termos. O conteúdo do push ainda é verificado contra as outras regras, regras permissions.deny ainda podem bloquear pushes para branches específicos completamente em todos os modos, e a proteção de branch do próprio remote ainda se aplica. Antes de v2.1.211, apenas pushes para o branch em que você começou, branches que Claude criou e pushes rotineiros para o branch padrão eram permitidos por padrão, e antes de v2.1.203 qualquer push direto para o branch padrão era bloqueado

Claude Code v2.1.195 e posterior também permitem estes por padrão:

  • Exclusão dos trabalhos exatos que Claude criou anteriormente na mesma sessão
  • Leitura, revisão ou escrita de código, configs e modelos de ameaça relacionados à segurança como parte de sua tarefa
  • Mensagens entre agentes trabalhando juntos na mesma sessão multi-agente
  • Envio de dados para os domínios confiáveis, buckets e serviços que você lista em environment. Isso cobre apenas fluxo de dados, não operações destrutivas ou de credencial na mesma infraestrutura
  • Claude no Chrome navegação para um domínio interno confiável, localhost ou uma URL que você nomeou

As solicitações de acesso à rede do sandbox são roteadas através do classificador em vez de serem permitidas por padrão. A partir de v2.1.198, o classificador reutiliza seu veredicto para um host e porta de rede em vez de re-executar em cada conexão:

  • Um allow é reutilizado até que novo conteúdo entre na conversa, ponto em que esse host é verificado novamente
  • Claude Code v2.1.234 e posterior reutilizam um deny causado pela conversa ultrapassando a janela de contexto do classificador até que novo conteúdo entre na conversa, ou até que compactação encolha o que o classificador lê. Claude Code então verifica o host novamente
  • Um deny que o classificador alcançou avaliando a solicitação dura para o turno na CLI interativa. Em modo não-interativo e sessões do Agent SDK, Claude Code reutiliza esse deny para o resto da execução, porque essas sessões não têm limite de turno
  • Alterar seu modo de permissão ou regras descarta todos os veredictos em cache

Execute claude auto-mode defaults para imprimir as listas de regras completas como JSON. Se ações rotineiras forem bloqueadas, um administrador pode adicionar repos, buckets e serviços confiáveis via configuração autoMode.environment: veja Configurar modo automático.

Pushing para qualquer branch do repositório em que você está trabalhando e criando uma pull request que corresponde à sua solicitação são executados sem um prompt, a menos que o push ou pull request caia sob a lista bloqueada, como segredos ou dados sensíveis deixando o repositório, ou uma pull request que tenha como alvo um repositório ou organização diferente. Para exigir um checkpoint humano antes dessas ações enquanto permanece em modo automático, adicione regras permissions.ask: veja Limites comuns.

A primeira leitura fora dos diretórios de trabalho

Enquanto permissions.blockReadsOutsideWorkingDirectories está desativado, leituras de arquivo são executadas sem um prompt em modo automático, incluindo leituras fora dos diretórios de trabalho. A primeira vez que Claude usa a ferramenta Read, Grep ou Glob em um caminho fora deles, Claude Code pergunta se você quer continuar permitindo essas leituras.

O prompt não aparece em execuções não-interativas -p ou sessões em segundo plano; leituras lá são executadas como antes.

Qualquer que seja sua resposta, Claude continua trabalhando:

  • Continuar permitindo: a leitura é executada, leituras posteriores fora dos diretórios de trabalho são executadas como antes, e Claude Code registra sua resposta para que o prompt não apareça novamente
  • Bloquear a partir de agora: a leitura é recusada, e Claude Code define permissions.blockReadsOutsideWorkingDirectories como true em suas configurações de usuário, o que faz as ferramentas de arquivo recusarem tais leituras em cada sessão posterior e cada modo de permissão. Para deixar Claude ler tal caminho depois, adicione seu diretório com /add-dir ou remova a configuração.
  • Pergunte novamente na próxima vez: a leitura é recusada, e a próxima leitura fora dos diretórios de trabalho solicita novamente

Limites que você declara na conversa

O classificador trata os limites que você declara na conversa como um sinal de bloqueio. Se você disser a Claude "não faça push" ou "espere até que eu revise antes de implantar", o classificador bloqueia ações correspondentes mesmo quando as regras padrão as permitiriam. Um limite permanece em vigor até que você o levante em uma mensagem posterior. O próprio julgamento do Claude de que uma condição foi atendida não o levanta.

Os limites não são armazenados como regras. O classificador os relê da transcrição em cada verificação, então um limite pode ser perdido se a compactação de contexto remover a mensagem que o declarou. Para uma garantia rígida, adicione uma regra de negação em vez disso.

Quando o modo automático volta

Quando o modo automático não consegue aprovar as ações de sua sessão, o que acontece depende do caso:

  • Uma ação bloqueada: Claude Code mostra uma notificação e lista a ação em /permissions sob a aba Recently denied, onde você pode pressionar r para tentar novamente com uma aprovação manual. Quando o classificador produz nenhum veredicto na ação, porque uma verificação de segurança separada do modo automático recusou a solicitação do classificador ou sua resposta não foi analisada, Claude Code nega a ação sem a notificação ou a entrada Recently denied.
  • Bloqueios repetidos: se o classificador bloquear uma ação 3 vezes seguidas ou 20 vezes no total, o modo automático pausa e Claude Code retoma o prompt. Aprovar a ação solicitada retoma o modo automático. Esses limites não são configuráveis. Qualquer ação permitida redefine o contador consecutivo, enquanto o contador total persiste para a sessão e redefine apenas quando seu próprio limite dispara um fallback. Claude Code não conta uma negação para nenhum limite quando uma verificação de segurança separada do modo automático recusa a solicitação do classificador; a entrada vinculada cobre como Claude Code lida com essas negações.
  • Sessões que não conseguem solicitar: uma execução não-interativa -p sem um --permission-prompt-tool não tem um prompt para voltar. Quando bloqueios repetidos atingem um limite, a ação não é executada e Claude continua trabalhando. O mesmo se aplica quando uma verificação de segurança separada do modo automático recusa a solicitação do classificador. Claude Code não para a execução em nenhum caso.
  • Uma mudança de modo durante uma verificação: se você alternar modos de permissão enquanto uma verificação do classificador está pendente, Claude Code descarta um veredicto que o novo modo não teria solicitado em vez de aplicá-lo: você é solicitado para aprovação em vez disso, ou a ação é auto-negada no modo dontAsk.

Bloqueios repetidos geralmente significam que o classificador está perdendo contexto sobre sua infraestrutura. Use /feedback para relatar falsos positivos, ou peça a um administrador para configurar infraestrutura confiável.

Cada ação passa por uma ordem de decisão fixa. O primeiro passo correspondente vence: 
1. Ações correspondentes a suas [regras de permissão, solicitação ou negação](/docs/pt/permissions#manage-permissions) resolvem imediatamente. Gravações em [caminhos protegidos](#protected-paths) são roteadas para o classificador mesmo quando uma regra de permissão corresponde, e assim como remoções `rm` e `rmdir` direcionadas a um [caminho crítico](#critical-paths) em Claude Code v2.1.218 e posterior. Ferramentas MCP marcadas [`requiresUserInteraction`](/docs/pt/mcp#require-approval-for-a-specific-tool) o solicitam diretamente mesmo quando uma regra de permissão corresponde, e assim como ferramentas de conector [que sua organização definiu como `ask`](/docs/pt/mcp#organization-controls-on-connector-tools) em sessões onde essa configuração chega a Claude Code. Regras de solicitação que correspondem no conteúdo de um comando, como `Bash(git push *)`, voltam para um prompt de permissão
2. Ações somente leitura e edições de arquivo em seu diretório de trabalho são auto-aprovadas, exceto gravações em [caminhos protegidos](#protected-paths) e [a primeira leitura fora dos diretórios de trabalho](#first-read-outside-the-working-directories), que o solicita
3. Tudo mais vai para o classificador. As ferramentas de conector e ferramentas MCP marcadas [`requiresUserInteraction`](/docs/pt/mcp#require-approval-for-a-specific-tool) que o solicitam diretamente na etapa 1 nunca chegam ao classificador, então uma aprovação exigida pela organização nem uma etapa de consentimento é auto-aprovada
4. Se o classificador bloquear, Claude recebe o motivo e tenta uma alternativa. Na maioria das sessões o motivo é o texto fixo `Blocked by classifier` em vez de uma explicação escrita, em Claude Code v2.1.208 e posterior; veja [Revisar negações](/docs/pt/auto-mode-config#review-denials)

Ao entrar no modo automático, regras de permissão amplas que concedem execução de código arbitrária são descartadas:

* Blanket `Bash(*)` ou `PowerShell(*)`
* Intérpretes com wildcard como `Bash(python*)`
* Comandos de execução do gerenciador de pacotes
* Regras de permissão `Agent`
* [`Monitor`](/docs/pt/tools-reference#monitor-tool) regras de permissão, porque Claude Code executa comandos Monitor através do shell

Regras estreitas como `Bash(npm test)` permanecem em vigor. Claude Code restaura as regras descartadas quando você sai do modo automático. Antes de v2.1.236, Claude Code deixou regras de permissão `Monitor` em vigor no modo automático, então uma regra que correspondia à ferramenta inteira aprovava comandos Monitor sem revisão do classificador.

Claude Code também executa `git status` ele mesmo antes de um comando que descartaria trabalho não confirmado, como `git reset --hard` ou `rm -rf`, e mostra ao classificador se há trabalho preparado, modificado ou não rastreado presente. Claude Code relata arquivos não rastreados nessa verificação mesmo quando a configuração git do repositório define `status.showUntrackedFiles=no`.

O classificador vê mensagens de usuário, chamadas de ferramenta diferentes de lookups somente leitura como leituras de arquivo e pesquisas, e seu conteúdo CLAUDE.md. Os resultados da ferramenta são removidos, então conteúdo hostil em um arquivo ou página da web não consegue manipulá-lo diretamente. Você pode anotar o resultado de uma chamada com um campo [`classifierContext`](/docs/pt/hooks#annotate-a-result-for-the-auto-mode-classifier) do hook PostToolUse, que o classificador lê como contexto fornecido pela aplicação.

Uma sonda separada do lado do servidor verifica os resultados da ferramenta recebidos e sinaliza conteúdo suspeito antes que Claude o leia. Para mais sobre como essas camadas funcionam juntas, veja o [anúncio do modo automático](https://claude.com/blog/auto-mode) e o [aprofundamento de engenharia](https://www.anthropic.com/engineering/claude-code-auto-mode).
Como o modo automático lida com subagentes

O classificador verifica o trabalho do subagente em três pontos:

  1. Antes de um subagente começar, a descrição da tarefa delegada é avaliada, então uma tarefa que parece perigosa é bloqueada no tempo de spawn.
  2. Enquanto o subagente executa, cada uma de suas ações passa pelo classificador com as mesmas regras que a sessão pai, e qualquer permissionMode no frontmatter do subagente é ignorado.
  3. Quando o subagente termina, o classificador revisa seu histórico de ação completo; se essa verificação de retorno sinalizar uma preocupação, um aviso de segurança é adicionado aos resultados do subagente. Quando uma verificação de segurança de API separada recusa a solicitação de revisão em si, Claude Code ainda retorna os resultados do subagente, adicionados com um aviso de que o trabalho não foi revisado e deve ser tratado como não confiável.

A etapa 1 requer Claude Code v2.1.178 ou posterior. Versões anteriores aplicavam o classificador nas etapas 2 e 3, mas não avaliavam a descrição da tarefa antes do subagente começar.

Custo e latência

O classificador é executado em Claude Sonnet 5 por padrão em vez de em sua seleção /model. Um modelo de classificador que Anthropic configura no lado do servidor tem precedência sobre esse padrão. Quando o modelo de sua sessão é Claude Sonnet 4.6, ou quando availableModels exclui Sonnet 5, o classificador é executado no modelo de sua sessão em vez disso, ou em um modelo Opus quando a sessão é executada em um modelo Fable; em provedores diferentes da API Anthropic, esse fallback Opus é o modelo Opus padrão do provedor.

A primeira solicitação de modo automático da sessão valida o padrão Sonnet 5: se a solicitação for bem-sucedida, Sonnet 5 permanece o modelo de classificador da sessão, e se falhar porque o modelo não está disponível, a sessão usa o fallback em vez disso. Depois que essa validação se resolve, o modelo do classificador não muda para a sessão.

Em planos Enterprise e em contas que usam a API Claude, Claude Platform on AWS, Amazon Bedrock, Agent Platform do Google Cloud ou Microsoft Foundry, chamadas do classificador contam para seu uso de token. Cada verificação envia uma porção da transcrição mais a ação pendente, adicionando uma volta antes da execução. Leituras e edições de diretório de trabalho fora de caminhos protegidos pulam o classificador, então a sobrecarga vem principalmente de comandos shell e operações de rede.

O classificador reutiliza um veredicto de rede do sandbox para um host e porta, então conexões repetidas ao mesmo host não adicionam cada uma uma verificação. O que o classificador bloqueia por padrão descreve quanto tempo um allow e um deny duram.

Permitir apenas ferramentas pré-aprovadas com modo dontAsk

Se você definir o modo dontAsk, Claude Code nega automaticamente toda chamada de ferramenta que de outra forma solicitaria você. Claude executa apenas ações que correspondem às suas regras permissions.allow, comandos Bash somente leitura e chamadas aprovadas por um hook PreToolUse. Use este modo para pipelines de CI ou ambientes restritos onde você pré-define exatamente o que Claude pode fazer; a sessão nunca aguarda entrada. A barra de status mostra ⏵⏵ don't ask on enquanto este modo está ativo.

Claude Code nega chamadas que correspondem às suas regras ask explícitas em vez de solicitar. Também nega a ferramenta integrada AskUserQuestion mesmo que suas regras de permissão correspondam a ela, e faz o mesmo para ferramentas de conector que sua organização definiu como ask em sessões onde essa configuração chega a Claude Code. Nega ferramentas MCP marcadas requiresUserInteraction da mesma forma, porque seu cartão de aprovação precisa de uma resposta que este modo nunca coleta; isso requer Claude Code v2.1.199 ou posterior.

Remoções rm e rmdir direcionadas a um caminho crítico, como rm -rf / e rm -rf ~, são negadas mesmo quando uma regra de permissão corresponde a elas ou um hook PreToolUse as permite.

Sessões em nuvem em Claude Code na web ignoram defaultMode: "dontAsk"; veja bypassPermissions para detalhes.

Defina-o na inicialização com a flag:

claude --permission-mode dontAsk

Ignorar todas as verificações com modo bypassPermissions

O modo bypassPermissions desativa prompts de permissão e verificações de segurança para que chamadas de ferramentas sejam executadas imediatamente, incluindo gravações em caminhos protegidos.

As ações que nenhum modo auto-aprova ainda solicitam neste modo.

Duas salvaguardas de mensagens entre sessões ainda se aplicam neste modo, e em sessões de modo plan onde permissões de bypass estão disponíveis:

  • O prompt de aprovação isolatePeerMachines para mensagens para suas sessões além desta máquina ainda aparece.
  • Quando nenhum valor crossSessionInbound se aplica, Claude Code mantém uma mensagem de entrada de outra de suas sessões para sua aprovação, e entrega sem perguntar apenas quando a sessão de envio se identifica como também ignorando prompts de permissão. Se você deixar o modo de permissão enquanto mensagens são mantidas, Claude Code re-aplica as regras de entrada e entrega qualquer mensagem mantida que elas agora aceitam.

Em sessões com permissões de bypass disponíveis, Claude Code também não impõe os bloqueios do modo plan. Claude ainda é instruído a planejar sem editar, mas uma edição de arquivo ou comando shell que ele tenta durante o planejamento é executado sem solicitar. Regras de solicitação explícitas e remoções rm e rmdir direcionadas a um caminho crítico ainda solicitam.

Você não consegue entrar em bypassPermissions a partir de uma sessão que você iniciou sem ele habilitado. Habilite-o na inicialização com permissions.defaultMode: "bypassPermissions" ou com uma flag de habilitação:

claude --permission-mode bypassPermissions

A flag --dangerously-skip-permissions é equivalente.

Claude Code recusa bypassPermissions em uma sessão que você inicia com --restricted. --restricted requer Claude Code v2.1.248 ou posterior.

A primeira vez que você inicia uma sessão interativa com este modo habilitado, Claude Code mostra um diálogo de aviso pedindo que você aceite responsabilidade pelas ações tomadas sem verificações de permissão. Claude Code salva sua aceitação em configurações de usuário, então o diálogo aparece apenas uma vez. Se você recusar, Claude Code sai. Em modo não-interativo nenhum diálogo é mostrado, e uma sessão em segundo plano iniciada com --bg é recusada até que você tenha aceitado o diálogo em uma sessão interativa.

Em Linux e macOS, Claude Code recusa iniciar neste modo quando executado como root ou sob sudo:

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

A verificação é ignorada automaticamente dentro de um sandbox reconhecido. Para executar autonomamente em um contêiner, use a configuração dev container, que executa Claude Code como um usuário não-root.

Claude Code na web não honra defaultMode: "bypassPermissions" ou "dontAsk" de seus arquivos de configurações, então as configurações verificadas de um repositório não conseguem iniciar uma sessão em nuvem no modo bypass-permissions. A configuração é ignorada silenciosamente e a sessão inicia no modo de permissão mostrado no dropdown de modo em vez disso. Veja Alternar modos de permissão para quais modos as sessões em nuvem oferecem.

Caminhos protegidos

Gravações em um pequeno conjunto de caminhos nunca são auto-aprovadas, exceto no modo bypassPermissions e em sessões de modo plan com permissões de bypass disponíveis. Isso evita corrupção acidental do estado do repositório e da configuração própria do Claude.

Modo Gravações em caminhos protegidos
default, acceptEdits Solicitado
plan Permitido em sessões com permissões de bypass disponíveis. Caso contrário, roteado para o classificador quando modo automático está disponível durante o planejamento, e solicitado quando não está
auto Roteado para o classificador
dontAsk Negado
bypassPermissions Permitido

Em uma sessão iniciada com --restricted, que requer Claude Code v2.1.248 ou posterior, o classificador não consegue aprovar gravações em caminhos protegidos.

Regras permissions.allow em arquivos de configurações não pré-aprovam gravações em caminhos protegidos. A verificação de segurança é executada antes de Claude Code avaliar regras de permissão de arquivos de configurações, então uma entrada como Edit(.claude/**) em ~/.claude/settings.json ou .claude/settings.json não altera o resultado por modo na tabela acima. Em modos que solicitam, o prompt para uma gravação em .claude/ oferece Sim, e permitir que Claude edite suas próprias configurações para esta sessão, o que aprova gravações posteriores em .claude/ nessa sessão sem solicitar novamente.

Diretórios protegidos:

  • .git
  • .config/git
  • .vscode
  • .idea
  • .husky
  • .cargo
  • .devcontainer
  • .yarn
  • .mvn
  • .claude, exceto por .claude/worktrees onde Claude armazena seus próprios git worktrees

Arquivos protegidos:

  • .gitconfig, .gitmodules
  • .bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
  • .npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
  • .bazelrc, .bazelversion, .bazeliskrc
  • .pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
  • gradle-wrapper.properties, maven-wrapper.properties
  • .devcontainer.json
  • .ripgreprc, pyrightconfig.json
  • .mcp.json, .claude.json

Caminhos críticos

Claude Code nunca deixa uma regra permissions.allow ou um hook PreToolUse que retorna "allow" aprovar um comando rm ou rmdir que tenha como alvo um caminho crítico, mesmo em modos que pulam outros prompts. Este disjuntor protege contra erro do modelo. Uma regra de negação correspondente ainda bloqueia o comando completamente.

O que acontece em vez disso depende do seu modo de permissão:

Modo O que Claude Code faz com uma remoção de caminho crítico
default, acceptEdits Pede que você o aprove
plan Pede que você o aprove. Com modo automático disponível durante o planejamento e nenhuma permissão de bypass disponível, envia-o para o classificador em vez disso
auto Envia-o para o classificador
dontAsk Nega-o
bypassPermissions Pede que você o aprove

Se uma regra de solicitação explícita corresponder ao comando, Claude Code o solicita mesmo em modo auto. Em modos que solicitam, um hook PermissionRequest pode responder ao prompt da forma que responde a qualquer outro.

Claude Code trata um alvo rm ou rmdir como um caminho crítico quando é qualquer um dos seguintes:

  • A raiz do sistema de arquivos
  • Diretórios de nível superior, significando qualquer filho direto da raiz, como /usr, /etc ou /data
  • Seu diretório home
  • Raízes de unidade do Windows e seus diretórios de nível superior, como C:\ e C:\Windows
  • Seu diretório de trabalho e seus pais
  • Seus diretórios de trabalho adicionais e seus pais, mas apenas quando a remoção é um glob sob um deles, como rm -rf <dir>/*. rm -rf <dir> no próprio diretório não dispara essa verificação

Claude Code também trata um glob ou barra à direita diretamente sob uma variável de shell, como rm -rf "$DIR"/*, como uma remoção de caminho crítico, porque o comando se torna uma remoção da raiz do sistema de arquivos quando a variável está vazia.

Esconder a remoção dentro de substituição de comando com $(...) ou backticks, ou substituição de processo com <(...), não pula a verificação. Claude Code encontra uma remoção de caminho crítico independentemente de estar dentro da substituição, como em echo "$(rm -rf ~)", ou em outro lugar no mesmo comando.

Remove-Item em PowerShell

Quando você habilita a ferramenta PowerShell, Claude Code dá a Remove-Item sua própria verificação, separada da lista de caminhos críticos rm. O resultado depende do alvo, e o primeiro caso correspondente se aplica:

  • Caminhos do sistema: a raiz do sistema de arquivos e seus diretórios de nível superior, raízes de unidade e seus diretórios de nível superior, e seu diretório home. Claude Code nega o comando em todos os modos, sem o solicitar.
  • Wildcards: um * nu, ou qualquer alvo terminando em /* ou \*, incluindo um glob sob uma variável de shell como $dir/*. Claude Code nega o comando em todos os modos, sem o solicitar, antes do classificador vê-lo.
  • Seu diretório de trabalho ou um de seus pais, com -Recurse: Claude Code trata o comando como qualquer outro que precisa de aprovação em seu modo de permissão, então o solicita em modos que solicitam, envia-o para o classificador em modo auto e o nega em modo dontAsk. O modo bypassPermissions pula essa verificação.

Veja também

  • Permissões: regras de permissão, solicitação e negação; políticas gerenciadas
  • Configurar modo automático: diga ao classificador qual infraestrutura sua organização confia
  • Hooks: lógica de permissão personalizada via hooks PreToolUse e PermissionRequest
  • Segurança: salvaguardas e melhores práticas
  • Sandboxing: isolamento de sistema de arquivos e rede para comandos Bash
  • Modo não-interativo: execute Claude Code com a flag -p