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.

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:

• Ferramentas correspondidas por uma regra de solicitação explícita

• Ferramentas de conector que sua organização definiu como ask, em sessões onde essa configuração chega a Claude Code

• Ferramentas que requerem interação do usuário: a ferramenta integrada AskUserQuestion e ferramentas MCP marcadas requiresUserInteraction

• Remoções rm e rmdir direcionadas a um caminho crítico, que nenhuma regra de permissão ou hook PreToolUse "allow" aprova

• As salvaguardas de mensagens entre sessões

• Leituras fora dos diretórios de trabalho enquanto permissions.blockReadsOutsideWorkingDirectories está ativado: comandos Bash reconhecidos de leitura de arquivo e qualquer retry não-sandboxizado que precisa de aprovação para executar fora do sandbox, mesmo em modo automático e modo bypassPermissions. Requer Claude Code v2.1.257 ou posterior.

  Um comando que o analisador de shell não consegue rastrear, como um que muda de diretório mais de uma vez ou executa um subshell, solicita da mesma forma mesmo quando não nomeia nenhum caminho externo. Este prompt não se aplica quando o comando é executado no sandbox e o sandbox impõe o bloqueio.

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.

O sandbox Bash e o modo automático funcionam independentemente e se combinam, com as exceções listadas em Sandbox modes. 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.

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.

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. Selecione sua interface para ver seus controles.

claude --permission-mode plan

claude remote-control --permission-mode acceptEdits

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.

Revisão do classificador no lado do servidor

Em planos Enterprise e em contas que usam a API Claude, em Claude Platform on AWS, Amazon Bedrock, Agent Platform do Google Cloud e Microsoft Foundry, e sempre que você aponta ANTHROPIC_BASE_URL para um gateway LLM ou proxy, Claude Code em modo automático pede ao servidor para revisar as ações que vão para o classificador como parte das solicitações do modelo da sessão. Onde o servidor as revisa, seus veredictos decidem essas ações. Onde não revisa, tipicamente porque um gateway LLM ou proxy interfere no tráfego, ou porque a plataforma, região ou credencial ainda não tem verificações no lado do servidor, Claude Code volta para suas próprias solicitações do classificador, e uma vez que esse fallback se mantém pelo resto da sessão, mostra um aviso sobre cobranças de solicitações do classificador em contas onde essas solicitações são cobradas. Para pular pedir ao servidor e sempre usar as próprias solicitações do classificador do Claude Code, defina CLAUDE_CODE_AUTO_MODE_SERVER=0. A variável não é lida em uma conexão direta com a API Anthropic. Se você definir CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 e deixar CLAUDE_CODE_AUTO_MODE_SERVER indefinido, Claude Code também para de pedir ao servidor.

Pedir ao servidor por padrão requer Claude Code v2.1.278 ou posterior.

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. 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 comandos push conforme escrito 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

Comandos em sandbox não obtêm acesso à rede por padrão. Claude nomeia os hosts que um comando precisa no próprio comando, o classificador os revisa com o comando, e uma lista aprovada abre esses hosts apenas para esse comando. Domínios permitidos por comando cobre o que uma lista pode e não pode abrir e o que acontece quando um comando tenta acessar um host não listado.

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, que correspondem ao comando conforme escrito: 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.

1. Ações correspondentes a suas [regras de permissão, solicitação ou negação](/docs/pt/permissions#manage-permissions) resolvem imediatamente, com estas exceções:
   * 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
   * Um comando shell que carrega [domínios permitidos por comando](/docs/pt/sandboxing#per-command-allowed-domains-in-auto-mode) também é roteado para o classificador mesmo quando uma regra de permissão corresponde, porque uma regra aprova o comando, não seus hosts
   * 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 nomeia a regra que o classificador correspondeu, como `[Data Exfiltration]`, em vez de dar uma explicação escrita; 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`.

Nas solicitações do classificador enviadas por Claude Code, 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 manipular o classificador 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. O campo requer Claude Code v2.1.236 ou posterior.

Uma sonda separada no 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).

claude --permission-mode dontAsk

claude --permission-mode bypassPermissions

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