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

Com Claude Code v2.1.283 ou posterior, o modo auto é o modo de permissão inicial integrado para sessões de terminal interativo e VS Code. Em versões anteriores, é o modo de permissão inicial integrado apenas nos planos Pro, Max, Ultra e Team. 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".

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, embora você possa desativar o prompt para comandos rm perigosos no modo 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 reconhecidas de rm e rmdir em caminhos críticos, que nenhuma regra allow ou "allow" de hook PreToolUse aprova, e comandos Bash sinalizados com Dangerous rm operation not ruled out

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

• Gravações fora dos diretórios de trabalho enquanto permissions.blockWritesOutsideWorkingDirectories está ativado: Claude Code recusa chamadas de Write, Edit e NotebookEdit nesses locais, exceto para alguns de seus próprios arquivos. A chave não limita comandos de shell, ferramentas MCP ou os programas que os hooks executam, então use sandboxing para limitar onde os comandos de shell gravam. Requer Claude Code v2.1.314 ou posterior.

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. 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 flag, um arquivo de configurações ou o padrão integrado seleciona auto mas o modo auto não está disponível para a sessão, Claude Code inicia a sessão no modo Manual em vez disso. O modo auto 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 auto, 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

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.

Nos planos Pro, Max, Ultra e Team, e em sessões que não buscam sinalizadores de recurso, Claude Code pergunta uma vez se você quer alterar a configuração para modo auto. A pergunta aparece no terminal ou na extensão VS Code e, se você recusar, sua configuração permanece como está.

Chamadas de ferramenta negadas em execuções de claude -p e do Agent SDK

No Claude Code v2.1.302 ou posterior, execuções de claude -p e do Agent SDK sem modo de permissão definido iniciam no modo Manual. Esse modo aparece como default nas opções do SDK e nas configurações. Chamadas que precisam de aprovação são negadas, a menos que você as aprove com uma regra de permissão, hook, callback canUseTool ou --permission-prompt-tool.

Para que essas chamadas sejam aprovadas, adicione regras de permissão ou inicie no modo auto:

• Adicionar regras de permissão: Claude executa as chamadas que você listar. Passe --allowedTools "Bash(npm test)" para claude -p, ou defina a opção de ferramentas permitidas do seu SDK.
• Iniciar no modo auto: um modelo classificador revisa as chamadas, então você não precisa listar nada antecipadamente. Passe --permission-mode auto para claude -p, ou defina a opção de modo de permissão do seu SDK.

Estes exemplos mostram a forma do modo auto para a CLI e cada SDK:

[tab] CLI

claude -p "Run the test suite and fix any failures" --permission-mode auto

[tab] TypeScript

const options = {
  permissionMode: "auto"
};

[tab] Python

from claude_agent_sdk import ClaudeAgentOptions

options = ClaudeAgentOptions(permission_mode="auto")

Antes da v2.1.302, essas execuções podiam iniciar no modo auto se não buscassem sinalizadores de recurso, por exemplo em um provedor de terceiros ou com DISABLE_TELEMETRY.

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.

Modos de permissão com a configuração HIPAA

Em uma organização com a configuração HIPAA aplicada, o padrão integrado auto não se aplica. Uma sessão de terminal ou do VS Code inicia no modo Manual quando nada mais escolhe seu modo de permissão inicial. Uma sessão de terminal também mostra Auto mode isn't the default for your organization · Shift+Tab to switch, e a extensão VS Code não mostra nenhum aviso. Verifique como os desenvolvedores fazem login e se conectam lista as sessões às quais isso se aplica.

O modo auto e bypassPermissions continuam disponíveis:

• Alternar para o modo auto: pressione Shift+Tab ou use o controle da sua interface
• Iniciar no modo auto: passe --permission-mode auto ou defina permissions.defaultMode como auto em suas configurações de usuário, ou em configurações gerenciadas para toda a sua organização. Veja Inicie em um modo de permissão diferente
• Remover o modo auto: defina permissions.disableAutoMode como "disable" em configurações gerenciadas
• Bloquear bypassPermissions: defina permissions.disableBypassPermissionsMode como "disable" em configurações gerenciadas

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.

[tab] CLI

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. Modos opcionais 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.

Observe a barra de status neste clipe de uma sessão que começou no modo auto. Cada vez que você pressiona Shift+Tab, ela muda de auto mode on para manual mode on, accept edits on, plan mode on e de volta para auto mode on.

[tab] VS Code

Durante uma sessão: clique no indicador de modo na parte inferior da caixa de prompt. Ele usa estes rótulos para os modos nesta página:

Rótulo da UI	Modo
Manual	default
Editar automaticamente	acceptEdits
Plan	plan
Auto	auto
Bypass permissions	bypassPermissions

Como padrão: para fixar o modo de permissão que conversas iniciam, defina claudeCode.initialPermissionMode nas configurações de usuário do VS Code como default, manual, acceptEdits, plan ou bypassPermissions. A configuração não aceita auto; para iniciar em Auto, deixe-a indefinida e escolha Auto no indicador de modo uma vez, como o item 2 abaixo descreve. A extensão inicia cada nova conversa no primeiro destes que se aplica:

1. claudeCode.initialPermissionMode
2. O modo que você escolheu por último no indicador de modo, se foi Manual, Editar automaticamente ou Auto. Escolher Plan ou Bypass permissions se aplica apenas a essa conversa
3. permissions.defaultMode de configurações gerenciadas ou ~/.claude/settings.json
4. O padrão integrado para seu plano, provedor e configurações de organização

A extensão nunca lê .claude/settings.json ou .claude/settings.local.json de um projeto para o modo de permissão inicial. Quando claudeCode.claudeProcessWrapper está definido, os itens 3 e 4 não se aplicam: essas conversas iniciam em Manual a menos que o item 1 ou item 2 defina um modo de permissão.

Antes de v2.1.283, o item 3 se aplicava apenas em planos Pro, Max, Ultra e Team em sessões que buscam sinalizadores de recurso.

Auto aparece no indicador de modo quando modo automático está disponível.

Bypass permissions requer o toggle Allow dangerously skip permissions nas configurações da extensão. Sem ele, o modo de permissão não aparece no indicador, e um valor bypassPermissions do item 1 ou item 3 inicia a conversa em Manual em vez disso. Auto de qualquer item também inicia a conversa em Manual quando o modo automático não está disponível.

Veja o guia do VS Code para detalhes específicos da extensão.

[tab] JetBrains

O plugin JetBrains executa Claude Code no terminal do IDE, então alternar modos de permissão funciona da mesma forma que na CLI: pressione Shift+Tab para alternar, ou passe --permission-mode ao iniciar.

[tab] Desktop

Durante uma sessão: na aba Code, use o seletor de modo na linha abaixo da caixa de prompt. Nem todo modo aparece no seletor:

• Auto: aparece quando modo automático está disponível
• Bypass permissions: requer o toggle Allow bypass permissions mode nas configurações do Desktop em planos Pro, Max e Ultra; em planos Team e Enterprise, a política da organização controla isso

O Cowork não usa estes modos. Ele tem seus próprios modos de permissão, habilitados separadamente, e não mostra nenhum seletor de modo até que um modo além de seu padrão seja habilitado para sua conta. Veja a documentação do Cowork.

Para detalhes específicos do desktop, veja Escolha um modo de permissão no guia do Desktop.

Como padrão: defina defaultMode em configurações. O aplicativo de desktop lê os mesmos arquivos de configurações que a CLI e aplica o modo de permissão a novas sessões locais.

Um modo que você escolhe no seletor de modo em uma sessão local é lembrado por pasta e tem precedência sobre um defaultMode nas configurações .claude/ do projeto. Uma nova sessão local ainda pode iniciar em um defaultMode de ~/.claude/settings.json ou de configurações gerenciadas, então verifique o seletor antes da sua primeira mensagem. Se você escolher Plan, ele se aplica apenas a esta sessão.

Para onde defaultMode vai em um arquivo de configurações, veja o exemplo em Inicie em um modo de permissão diferente.

[tab] Web and mobile

Em claude.ai/code, use o dropdown de modo na linha abaixo da caixa de prompt. No aplicativo móvel, toque no botão + na caixa de prompt e depois em Permission. Sessões na nuvem e sessões de Remote Control oferecem modos de permissão diferentes:

• Sessões na nuvem: Accept edits, Plan e Auto. Accept edits corresponde ao modo default: sessões na nuvem pré-aprovam edições de arquivo independentemente do modo, então o dropdown mostra Accept edits em vez de Manual. Sessões na nuvem ainda honram defaultMode: "acceptEdits" de configurações. O modo Auto aparece a menos que sua organização o desative e, no claude.ai/code, fica esmaecido se o modelo selecionado não o suportar. Bypass permissions não está disponível.
• Sessões de Remote Control em sua máquina local: Manual, Accept edits, Plan e Auto para uma sessão que você mesmo iniciou, e você não pode selecionar Bypass permissions do aplicativo. Para usar Auto, a sessão precisa atender aos requisitos de disponibilidade do modo auto. Para um thread de projeto executado em seu computador, veja Execute um thread em seu próprio computador.
  • Exceto por Bypass permissions, o dropdown mostra o modo de permissão em que a sessão local está, incluindo um definido do terminal. Ele atualiza quando o modo de permissão muda no aplicativo ou no terminal.
  • Sessões hospedadas pelo aplicativo de desktop ou pela extensão VS Code relatam mudanças de modo de permissão ao claude.ai conforme acontecem, da mesma forma que sessões hospedadas em um terminal.

Para Remote Control, a máquina local executando a sessão deve estar conectada com sua conta claude.ai; chaves de API não são suportadas. Você também pode definir o modo de permissão inicial ao iniciar essa sessão local:

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. Exceto por touch, 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.

Estes ainda solicitam confirmação:

• Caminhos fora desse escopo
• Gravações em caminhos protegidos
• Remoções de caminho crítico reconhecidas de rm e rmdir
• touch com qualquer coisa além de caminhos de arquivo simples, por exemplo uma opção, um glob ou um prefixo como timeout 5 ou LANG=C
• Todos os outros comandos Bash, exceto o conjunto integrado somente leitura

Cada caminho também passa pela verificação de symlink, portanto uma gravação que se resolve fora desse escopo também não é auto-aprovada.

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 o modo de planejamento

O modo de planejamento instrui o Claude a pesquisar e propor alterações sem realizá-las. O Claude lê arquivos, executa comandos de shell para explorar e escreve um plano, mas não edita seu código-fonte. Exceto em sessões interativas de terminal com bypass permissions disponível, as edições permanecem bloqueadas até que você aprove o plano.

O que acontece com um comando de shell durante o planejamento depende da sessão, e aplica-se o primeiro dos casos a seguir que corresponder:

• Sessões interativas de terminal com bypass permissions disponível: nem o classificador nem um prompt se aplicam aos comandos de planejamento. Ignore todas as verificações com o modo bypassPermissions aborda as poucas coisas que ainda solicitam confirmação nesse caso.
• Modo auto disponível e a configuração useAutoModeDuringPlan ativada, o que ocorre por padrão: o classificador revisa os comandos de shell, exceto remoções de caminhos críticos, em vez de solicitar sua confirmação. Os comandos aprovados são executados, e os rejeitados são bloqueados.
• Modo auto não disponível, ou useAutoModeDuringPlan desativada: os comandos fora do conjunto somente leitura integrado solicitam aprovação, inclusive quando o modo de permissão automática do sandbox está ativado.

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

claude --permission-mode plan

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

Revise e aprove um plano

Quando o plano estiver pronto, o Claude o apresenta e pergunta como prosseguir. Nesse prompt, você pode escolher:

• Yes, and use auto mode: aprova e inicia no modo auto. Se o modo auto não estiver disponível para sua sessão, por exemplo porque sua organização o desativou, essa opção aparece como Yes, auto-accept edits. Se você iniciou a sessão com bypass permissions ativado, a opção aparece como Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session.
• Yes, manually approve edits: aprova e revisa cada edição individualmente.
• No, keep planning: permanece no modo de planejamento e informa ao Claude o que alterar.

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

Pressione Ctrl+G para abrir o plano proposto no seu editor de texto padrão e editá-lo diretamente antes que o Claude prossiga. Quando showClearContextOnPlanAccept está ativada, 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 com base no plano, a menos que você já tenha nomeado a sessão.

Defina o modo de planejamento como padrão

Para tornar o modo de planejamento o padrão para as sessões de terminal de um projeto, defina defaultMode como plan em .claude/settings.json, posicionado como mostra o exemplo em Inicie em um modo de permissão diferente. As conversas iniciadas pela extensão do VS Code não leem as configurações do projeto para o modo de permissão inicial. Nesse caso, defina claudeCode.initialPermissionMode como plan nas suas configurações de usuário do VS Code.

Elimine prompts de permissão com o modo auto

O modo auto permite que Claude execute sem prompts de permissão rotineiros. Um modelo classificador separado revisa as ações antes de serem executadas, bloqueando qualquer coisa que escale além da 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.

Com Claude Code v2.1.283 ou posterior, o modo auto é o modo de permissão inicial integrado para sessões de terminal interativo e VS Code em todos os planos e provedores. Em versões anteriores, é o modo de permissão inicial integrado apenas nos planos Pro, Max, Ultra e Team.

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 que Claude Code a entregue, tanto no modo auto quanto no modo de planejamento enquanto o classificador revisa comandos; a revisão de envio requer Claude Code v2.1.222 ou posterior.

Por padrão, o classificador não revisa remoções reconhecidas de rm e rmdir direcionadas a um caminho crítico, como rm -rf / ou rm -rf ~. Caminhos críticos cobre o que acontece com elas em cada modo de permissão.

O modo auto 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 um comportamento mais autônomo em um modo que ainda solicita sua confirmação, defina o estilo de saída Proativo em vez disso.

[!WARNING]

O modo auto reduz prompts de permissão, mas não garante segurança. Use-o para tarefas em que você confia na direção geral, não como substituto para revisão em operações sensíveis.

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

• Plano: Todos os planos.
• Organização: em Team e Enterprise, o modo auto está disponível por padrão. Os 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, Haiku 5.5 ou um modelo Fable. No Amazon Bedrock, na Agent Platform do Google Cloud, no Microsoft Foundry e em sessões gateway de aplicativos Claude conectadas, apenas Claude Sonnet 5 ou posterior, Opus 4.7 ou posterior, Haiku 5.5 e os modelos Fable. Modelos mais antigos, incluindo Sonnet 4.5, Opus 4.5, Haiku 4.5 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 auto como indisponível, primeiro verifique esses requisitos e se algum arquivo de configurações define disableAutoMode. A Anthropic também pode ter desativado o modo auto no servidor, ou o servidor pode ter rejeitado o modo auto para sua conta. Uma sessão que recebeu uma dessas respostas mantém o modo auto 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 auto "não pode determinar a segurança" de uma ação significa que uma requisiçã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. Consulte 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 iniciar em modo Manual sem erro, a configuração provavelmente está em .claude/settings.json ou .claude/settings.local.json. auto não entra em vigor a partir 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 auto 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 auto está disponível por padrão. Se você não definir um modo de permissão nesses ambientes, sessões interativas iniciam no modo auto, e execuções claude -p ou do Agent SDK iniciam no modo Manual, cujo valor de configuração é default:

• Sessões interativas de terminal e VS Code: para iniciá-las em um modo de permissão diferente de auto, defina permissions.defaultMode como Iniciar em um modo de permissão diferente descreve, ou escolha um no indicador de modo da extensão VS Code. Em qual modo uma sessão inicia lista as versões de Claude Code que as iniciam no modo auto.
• Execuções claude -p e do Agent SDK: para iniciar uma no modo auto, passe --permission-mode auto para claude -p, ou passe permissionMode: "auto" em TypeScript ou permission_mode="auto" em Python. Se você não passar nenhum modo de permissão, consulte Chamadas de ferramenta negadas em execuções claude -p e do Agent SDK, que também cobre versões anteriores de Claude Code.

Apenas Claude Sonnet 5 ou posterior, Opus 4.7 ou posterior, Haiku 5.5 e os modelos Fable são suportados nesses provedores. Em qualquer outro modelo, a sessão inicia em Manual em vez disso. O modo auto com Haiku 5.5 nesses provedores requer Claude Code v2.1.293 ou posterior.

Para impedir que desenvolvedores usem o modo auto, 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 auto 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 auto até que terminasse.

Revisão do classificador no servidor

No modo auto, Claude Code pode pedir ao servidor para verificar as ações que a ordem de decisão envia para revisão, como parte das requisições ao modelo da sessão, em vez de enviar suas próprias requisições do classificador. Estas sessões pedem:

• Uma conexão direta com a API Anthropic: em sessões de terminal interativo e em sessões -p, Agent SDK, extensão VS Code e aplicativo desktop, qualquer que seja seu plano ou tipo de conta, conforme a Anthropic disponibiliza o recurso. Verifique seu tipo de sessão segundo estas versões mínimas de Claude Code:
  • Em sessões de terminal interativo, pedir ao servidor requer Claude Code v2.1.271 ou posterior nos planos Pro, Max, Ultra e Team. Nos planos Enterprise e contas da API Claude, essas sessões requerem v2.1.278 ou posterior.
  • Em sessões -p e da extensão VS Code, pedir ao servidor requer Claude Code v2.1.278 ou posterior
  • Em sessões do Agent SDK e do aplicativo desktop, pedir ao servidor requer Claude Code v2.1.281 ou posterior
  • A partir da v2.1.282, uma sessão que não busca feature flags, por exemplo porque você desativou a telemetria, pede ao servidor por padrão em qualquer tipo de sessão
• Um provedor de nuvem, ou um gateway de LLM ou proxy: 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 de LLM ou proxy, qualquer que seja seu plano. Pedir por padrão requer Claude Code v2.1.278 ou posterior.
• Uma sessão gateway de aplicativos Claude conectada: requer Claude Code v2.1.280 ou posterior
• Uma sessão na nuvem em um ambiente hospedado pela Anthropic: qualquer que seja seu plano, quando você a inicia pela web, pelo aplicativo móvel ou pelo aplicativo desktop com Cloud selecionado. Sessões iniciadas por uma tarefa agendada na nuvem pedem ao servidor conforme a Anthropic disponibiliza o recurso.

Onde o servidor revisa as ações, seus vereditos as decidem. Dois outros resultados são possíveis:

• O servidor não revisa a sessão: uma resposta é concluída sem resultados de revisão, ou o servidor responde que não revisa essa sessão. As causas mais comuns são um gateway de LLM ou proxy que descarta a requisição de revisão ou os resultados, e uma plataforma, região ou credencial que ainda não tem verificações no servidor. Claude Code recorre às suas próprias requisições do classificador. Uma vez que esse fallback se mantém pelo resto da sessão, ele mostra um aviso sobre cobranças de requisições do classificador em contas onde essas requisições são cobradas.

• O servidor não dá veredito para uma ação: Claude Code nega a ação em vez de executá-la sem revisão. Em qualquer conexão, isso acontece quando a resposta termina antes de os resultados de revisão chegarem ou quando os resultados chegam em uma forma que Claude Code não consegue ler. Um gateway de LLM ou proxy que corta respostas ou reescreve os resultados pode causar qualquer um dos dois. Em uma conexão direta com a API Anthropic, também acontece quando a verificação do servidor falha para a ação, por exemplo ao expirar o tempo limite. O servidor não retornou veredito de segurança cobre a mensagem de negação, o que acontece quando negações se repetem e o que fazer.

  Se um hook ou mod alterar a entrada de uma ação após a revisão do servidor, Claude Code pode negar a ação sem veredito. Em sessões de terminal interativo e VS Code em uma conexão direta com a API Anthropic, o texto da negação inclui a hook changed this call's input after auto mode reviewed it. Sua entrada de erro cobre o que fazer.

Para deixar de consultar o servidor e sempre usar as próprias requisições do classificador de Claude Code, defina CLAUDE_CODE_AUTO_MODE_SERVER=0. Em uma conexão direta com a API Anthropic, a variável requer Claude Code v2.1.281 ou posterior. Defini-la como 1 nesse caso ativa a revisão do servidor em uma sessão que ainda não a tem, a menos que você também tenha definido CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. 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, exceto como Desabilitar capacidades de pré-lançamento descreve.

Modelo classificador padrão

Por padrão, as requisições do classificador vão para Claude Sonnet 5. Se /status mostrar Auto mode server como Enabled, elas são enviadas apenas para chamadas fora da revisão do servidor.

Encontre a primeira linha desta tabela que corresponde à sua sessão. Você obtém o modelo dessa linha em vez de Sonnet 5.

Se Sonnet 5 ou o modelo em ANTHROPIC_DEFAULT_SONNET_MODEL não estiver disponível em seu provedor ou for excluído pela política de modelos da sua organização, Claude Code usa um modelo de fallback. Esse é o modelo da sua sessão, ou um modelo Opus em uma sessão Fable.

Escolher o modelo classificador

Com Claude Code v2.1.302 ou posterior, defina CLAUDE_CODE_AUTO_MODE_MODEL como um ID de modelo completo para executar o classificador em um modelo diferente do padrão. Os próprios IDs de modelo completos do seu provedor de nuvem também funcionam. Este exemplo de ~/.claude/settings.json define Claude Sonnet 4.6:

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "claude-sonnet-4-6"
  }
}

Quando o seu modelo não é o que está revisando

Se várias situações se aplicarem, siga a primeira listada.

Verificar qual modelo o classificador usou

No seu shell, inicie uma sessão no modo auto com --debug-file:

claude --permission-mode auto --debug-file classifier-debug.log

Para dar ao classificador um comando para revisar, peça a Claude para executar curl https://example.com e, em seguida, pesquise no log por classifier_request_started:

• Seu modelo após model=: a variável entrou em vigor
• Um modelo diferente após model=: pesquise no log por ignoring CLAUDE_CODE_AUTO_MODE_MODEL, que dá o motivo e qualquer etapa a seguir
• Nenhuma linha assim: leia Auto mode server em /status no prompt de Claude Code:
  • Enabled: o servidor está configurado para revisar as chamadas desta sessão.
  • Disabled: esta verificação ainda não testou o seu modelo. Certifique-se de que o modo de permissão é auto e de que nenhuma regra de permissão corresponde a curl e, em seguida, execute a verificação novamente com o sandbox desativado.

O que o classificador bloqueia por padrão

O classificador confia em seu diretório de trabalho e nos remotos que foram configurados para ele quando a sessão iniciou. Um remoto adicionado ou reapontado durante a sessão com git remote add ou git remote set-url não é confiável, e todo o resto é tratado como externo até você configurar infraestrutura confiável.

Bloqueado por padrão:

• Baixar e executar código, como curl | bash

• Enviar 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 IAM ou de repositório

• Modificação de infraestrutura compartilhada

• Destruição irreversível de arquivos que existiam antes da sessão

• Force push

• Fazer commit ou push de uma alteração que, ao ser executada, enviaria segredos ou dados sensíveis para fora do repositório, ou ampliaria o que uma implantação expõe. Isso cobre um workflow de CI ou configuração de implantação que passa um segredo para um destino que ainda não o recebe, um script ou etapa de setup que lê um armazenamento de segredos e envia os dados para fora, e uma mudança de configuração que amplia o que uma implantação publica, como uma opção de registro, visibilidade, artefato ou sourcemap. A verificação se aplica em qualquer branch, se aplica mesmo quando o repositório é público e dispara quando é feito commit ou push da alteração, independentemente de esse commit ou push disparar o pipeline; liberá-la requer nomear o efeito de execução, não apenas o commit ou push

• git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop ou git stash clear, que o classificador presume que descartariam alterações sem commit

• git commit --amend quando o commit no HEAD não foi criado nesta sessão

• A partir da v2.1.198, git commit --amend quando já foi feito push do commit no HEAD. Uma reescrita apenas da mensagem não é bloqueada: --amend -m sem nada recém-adicionado ao stage, em um commit que Claude criou durante esta sessão

• terraform destroy, pulumi destroy, cdk destroy ou terragrunt destroy, e aplicar um plano que destrói recursos

• Escrita em um gerenciador de segredos, ou alteração de registros DNS ou certificados TLS

• Mesclar um pull request que nenhum humano aprovou, aprovar o próprio pull request de Claude ou desabilitar 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 uma feature flag de produção

• Aplicação de alterações de infraestrutura a um escopo IaC protegido, ou drenagem e remoção de nós de cluster

• Escritas 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 atinge 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 para um alvo remoto sensível

• Abertura de um túnel ou shell reverso que torna um serviço local acessível pela internet pública

• Impressão de uma credencial ou token ativo na transcrição ou em um arquivo

• Acesso a um local listado como local de dados sensíveis em seu ambiente, cópia de dados de um deles, ou envio de dados de um deles para um público que a entrada exclui

• Roteamento de uma instalação de pacote contornando seu registro de pacotes interno em direção a um registro público. Isso se aplica quando um registro interno ou espelho está listado em seu ambiente ou quando você disse a Claude na conversa que existe um

• Execução de um comando com uma flag 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. Isso inclui 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 de navegador do Claude in Chrome que poderiam enviar conteúdo de página, cookies ou credenciais para fora da origem

• 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 os próprios repositórios públicos da sua organização; caminhos de arquivo internos, codinomes, dados ativos de respostas de API como emails ou identificadores de conta, e identificadores de infraestrutura contam como detalhes sensíveis. Dados pessoais ativos de uma resposta de API em um corpo de PR ou issue, como um endereço de email, um identificador de conta ou organização ou uma métrica de uso, exigem que você nomeie esses detalhes e o destinatário independentemente da visibilidade ou do limite de confiança do repositório

• Envio de pressionamentos de tecla para o próprio painel tmux de Claude Code para conduzir sua própria interface, o que o classificador trata como Claude alterando suas próprias permissões ou supervisão

• Comentar, excluir ou forçar a aprovação 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

• Reapontamento de uma URL base de API, endpoint de proxy, receptor de webhook ou espelho de registro para um host de terceiros que não se encaixa na tarefa, incluindo em arquivos de exemplo como .env.example

• Alteração do destino dos pushes com git remote set-url ou git remote add, a menos que você tenha nomeado o novo remoto

• Push de segredos ou dados pessoais ou confiados para um repositório sabidamente público, ou push para ele de material confidencial 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. Quando a visibilidade de um repositório não está estabelecida, o classificador não bloqueia apenas com base nisso; em vez disso, ele julga o conteúdo segundo as outras regras

• Abertura de um pull request contra um repositório ou organização diferente, criação de fork com gh repo fork ou push para um repositório de terceiros, a menos que você tenha nomeado esse alvo externo

• 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 uma publicação de pacote, a menos que você tenha nomeado tanto a origem quanto o destino. Transcrições de sessão e logs de conversa, pastas ocultas de credenciais e configuração como chaves SSH, credenciais de nuvem, perfis de navegador e histórico de shell, e exportações de dados de usuário contam, e o fato de o repositório ser privado não libera o bloqueio

• Escrita em transcrições de sessão de Claude Code, os arquivos de histórico .jsonl em ~/.claude/projects/ ou em 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 que não é atribuída em nenhum lugar da conversa que o classificador vê, ou um glob enraizado em tal variável. O valor veio apenas de saídas de comando anteriores, que o classificador nunca recebe, então o classificador não consegue verificar o alvo da exclusão segundo as outras regras de exclusão. O bloqueio é liberado quando você nomeia o caminho exato sendo excluído, ou quando Claude executa novamente a exclusão com o caminho literal resolvido escrito no comando. Exclusões cujo alvo o classificador consegue resolver não são afetadas.

  Um glob diretamente sob a variável, como em rm -rf "$VAR"/*, é em vez disso um caminho crítico. Alvos de Remove-Item que são um * simples ou terminam em /* ou \* nunca chegam ao classificador: Claude Code os nega imediatamente.

Várias dessas categorias dependem de entradas de ambiente, como alvos remotos sensíveis e escopos IaC protegidos, que você pode restringir a nomes concretos.

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 de 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 de nó da própria máquina
• Acesso a um host público por uma rota diferente de uma requisição direta, como um túnel, um shell reverso ou uma configuração de resolvedor ou proxy reescrita para apontar para fora
• Leitura de credenciais que pertencem ao host em vez de à sua tarefa, como certificados de nó ou a autenticação 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 do nó sob o contêiner

Se Claude Code executar em algum lugar que se destine a permitir um desses, 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

• Requisições HTTP somente leitura

• Push 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 alvo de implantação ou publicação, como production ou gh-pages, não está coberto: o classificador julga um push para ele por seus próprios méritos.

  O conteúdo de um push ainda é verificado segundo as outras regras do classificador, e regras permissions.deny ainda podem bloquear comandos de push como escritos em todos os modos. A proteção de branch do próprio remoto ainda se aplica.

• 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 multiagente

• Envio de dados para os domínios, buckets e serviços confiáveis que você lista em environment. Isso cobre apenas fluxo de dados, não operações destrutivas ou de credenciais na mesma infraestrutura

• Navegação do Claude in Chrome 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 no próprio comando os hosts de que ele precisa, o classificador os revisa junto 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 alcançar 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 repositórios, buckets e serviços confiáveis por meio da configuração autoMode.environment: consulte Configurar o modo auto.

Push para qualquer branch do repositório em que você está trabalhando e a criação de um pull request que corresponde à sua solicitação executam sem um prompt, a menos que o push ou pull request se enquadre na lista de bloqueios, como segredos ou dados sensíveis saindo do repositório, ou um pull request que tem como alvo um repositório ou organização diferente. Para exigir um checkpoint humano antes desses comandos enquanto permanece no modo auto, adicione regras permissions.ask, que correspondem ao comando como escrito: consulte Limites comuns.

A primeira leitura fora dos diretórios de trabalho

Enquanto permissions.blockReadsOutsideWorkingDirectories estiver desativado, leituras de arquivo que não sejam leituras de caminhos de rede executam sem um prompt no modo auto, incluindo leituras fora dos diretórios de trabalho. Na primeira vez que Claude usa a ferramenta Read, Grep ou Glob em um caminho fora deles, Claude Code pergunta se deve permitir essa leitura.

O prompt não aparece em execuções -p não interativas ou em sessões em segundo plano; leituras nelas executam como antes.

Qualquer que seja sua resposta, Claude continua trabalhando:

• Sim, e continue permitindo qualquer leitura fora dos diretórios de trabalho: a leitura executa, leituras posteriores fora dos diretórios de trabalho executam como antes, e Claude Code registra sua resposta para que o prompt não apareça novamente
• Não, e bloqueie leituras fora dos diretórios de trabalho 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 nesta e em cada sessão posterior e em cada modo de permissão. Para suspender o bloqueio, remova a configuração de cada arquivo de configurações que a define e, em seguida, reinicie cada sessão em execução. Para um diretório nesta sessão, use /add-dir.
• Não, e pergunte novamente na próxima vez: a leitura é recusada, e a próxima leitura fora dos diretórios de trabalho solicita confirmação novamente
• Sim, mas pergunte novamente na próxima vez: a leitura executa, nada é salvo, e a próxima leitura fora dos diretórios de trabalho solicita confirmação novamente

Limites que você declara na conversa

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

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.

Aprovações que você declara na conversa

Se você disser a Claude que uma ação bloqueada é permitida, o classificador lê isso como sua aprovação e pode liberar o bloqueio. A forma como você se expressou decide se a ação executa e até onde a aprovação alcança:

• Nomeie a ação e seus detalhes: sua mensagem tem que nomear a ação e a coisa específica que a torna perigosa, como o branch de um force push. Nomear apenas o verbo não libera nada, então "você pode fazer force-push" mantém o bloqueio em vigor.
• Espere que cubra uma ação: uma aprovação cobre a ação destrutiva que você nomeou, então uma ação posterior é bloqueada novamente a menos que você tenha concedido a aprovação como permanente. Para parar de aprovar um padrão rotineiro uma ação por vez, adicione-o a autoMode.allow.
• Alguns bloqueios permanecem em vigor: a ordem de precedência do classificador estabelece quais bloqueios sua aprovação pode alcançar. Para executar uma etapa que ela não libera, saia do modo auto e responda ao prompt de permissão.

Quando o modo auto recorre a um fallback

Quando o modo auto 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 na aba Recently blocked, onde você pode aprovar a ação para que Claude possa tentar novamente.
• Bloqueios repetidos: se o classificador bloquear uma ação 3 vezes seguidas ou 20 vezes no total, o modo auto pausa e Claude Code volta a solicitar confirmação. Aprovar a ação solicitada retoma o modo auto. Consulte Limites de bloqueio repetido para saber como os bloqueios são contados.
• Sem veredito do classificador: quando uma verificação de segurança separada do modo auto recusa a própria requisição do classificador, ou a resposta do classificador não pode ser analisada, Claude Code bloqueia a ação sem a notificação ou a entrada em Recently blocked. Consulte Auto mode cannot determine the safety of an action para a mensagem que cada caso mostra e o que fazer.
• Sem veredito do servidor: sob a revisão do classificador no servidor, Claude Code nega uma ação para a qual o servidor não dá veredito, e pode interromper o turno após dez respostas seguidas sem veredito. Consulte O servidor não retornou veredito de segurança.
• Uma mudança de modo durante uma verificação: se você mudar de modo de permissão enquanto uma verificação do classificador está pendente, Claude Code descarta um veredito que o novo modo não teria solicitado. Em vez disso, você recebe um prompt de aprovação, ou a ação é negada automaticamente no modo dontAsk.

Limites de bloqueio repetido

Os limites de 3 bloqueios seguidos e 20 bloqueios no total não são configuráveis. O contador total persiste durante a sessão e é redefinido apenas quando seu próprio limite dispara um fallback. Claude Code não conta uma negação para nenhum dos limites quando uma verificação de segurança separada do modo auto recusa a própria requisição do classificador.

Uma execução -p não interativa sem um --permission-prompt-tool não tem prompt ao qual recorrer. Quando bloqueios repetidos atingem um limite, a ação não executa e Claude continua trabalhando. Claude Code não interrompe a execução.

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

Como o modo auto avalia ações

As seções a seguir cobrem a ordem em que Claude Code avalia uma ação, como o classificador revisa o trabalho de subagentes e o que as chamadas do classificador adicionam em custo e latência.

[accordion] Como o classificador avalia ações

Cada ação passa por uma ordem de decisão fixa. O primeiro passo correspondente prevalece:

1. Ações que correspondem às suas regras de permitir, solicitar ou negar são resolvidas imediatamente, com estas exceções:
   • Escritas em caminhos protegidos são roteadas para o classificador mesmo quando uma regra de permitir corresponde. Quando o caminho protegido é o arquivo para o qual um arquivo de configurações com link simbólico aponta, a escrita pode pedir sua confirmação em vez disso, como a lista de caminhos protegidos descreve
   • Nenhuma regra de permitir aprova remoções reconhecidas de rm e rmdir direcionadas a um caminho crítico
   • Ferramentas MCP marcadas com requiresUserInteraction pedem sua confirmação diretamente mesmo quando uma regra de permitir corresponde, assim como ferramentas de conector que sua organização definiu como ask em sessões onde essa configuração chega a Claude Code
   • Um comando de shell que carrega domínios permitidos por comando também é roteado para o classificador mesmo quando uma regra de permitir corresponde, porque uma regra aprova o comando, não seus hosts
   • Regras de solicitação que correspondem ao conteúdo de um comando, como Bash(git push *), recorrem a um prompt de permissão
   • Uma escrita que a verificação de symlink resolve para um caminho protegido pede sua confirmação quando o caminho que Claude solicitou não é em si protegido
   • Uma leitura de um caminho de rede pede sua confirmação mesmo quando uma regra de permitir corresponde
2. Ações somente leitura e edições de arquivo em seu diretório de trabalho são aprovadas automaticamente, exceto escritas em caminhos protegidos e a primeira leitura fora dos diretórios de trabalho, que pede sua confirmação
   • Em uma sessão com revisão do classificador no servidor, comandos de shell somente leitura e em sandbox esperam por essa revisão e são bloqueados se ela os sinalizar
   • Uma escrita dentro de seu diretório de trabalho que a verificação de symlink resolve para um local fora dele pede sua confirmação
   • Quando Claude lê um artefato que outra pessoa criou, os casos de aprovação listados nessa seção se aplicam
   • Uma leitura de um caminho de rede pede sua confirmação
3. Todo o resto vai para o classificador, exceto remoções de caminho crítico sob seu tratamento padrão. As ferramentas de conector e as ferramentas MCP com requiresUserInteraction que pedem sua confirmação diretamente na etapa 1 também nunca chegam ao classificador, então nem uma aprovação exigida pela organização nem uma etapa de consentimento é aprovada automaticamente
4. Se o classificador bloquear, Claude recebe o motivo. Na maioria das sessões, o motivo nomeia a regra que o classificador identificou, como [Data Exfiltration], em vez de dar uma explicação escrita; consulte Revisar negações

Um mod que você instala e que trata tool.check também pode aprovar uma ação. Para os casos em que a aprovação dele não passa por suas regras e hooks, consulte Estender permissões com hooks.

Para saber como as ações de navegador do Claude in Chrome são aprovadas na extensão VS Code, consulte Prompts de permissão em sessões VS Code.

Ao entrar no modo auto, regras de permitir amplas que concedem execução de código arbitrário são descartadas:

• Bash(*) ou PowerShell(*) irrestritos
• Intérpretes com wildcard como Bash(python*)
• Comandos de execução do gerenciador de pacotes
• Regras de permitir Agent
• Regras de permitir Monitor, porque Claude Code executa comandos Monitor através do shell

Regras específicas como Bash(npm test) permanecem em vigor. Claude Code restaura as regras descartadas quando você sai do modo auto. Antes da v2.1.236, Claude Code mantinha regras de permitir Monitor em vigor no modo auto, então uma regra que correspondesse à ferramenta inteira aprovava comandos Monitor sem revisão do classificador.

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

Nas requisições do classificador enviadas pelo próprio Claude Code, o classificador vê mensagens do usuário, chamadas de ferramenta diferentes de consultas somente leitura como leituras de arquivo e buscas, e seu conteúdo de CLAUDE.md. Resultados de ferramenta são removidos dessas requisições, 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 o campo classifierContext de um 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 servidor examina resultados de ferramenta recebidos e sinaliza conteúdo suspeito antes que Claude o leia. Para saber mais sobre como essas camadas funcionam juntas, consulte o anúncio do modo auto e o aprofundamento de engenharia.

[accordion] Como o modo auto lida com subagentes

O classificador verifica o trabalho de subagentes em três pontos:

1. Antes de um subagente iniciar, a descrição da tarefa delegada é avaliada, então uma tarefa que parece perigosa é bloqueada no momento da criação.
2. Enquanto o subagente executa, cada uma de suas ações passa pela mesma ordem de decisão que na sessão pai, com as mesmas regras de bloqueio e permissão. Qualquer permissionMode no frontmatter do subagente é ignorado.
3. Quando o subagente termina, o classificador revisa seu trabalho e seu relatório final antes que o pai leia o relatório. Quando o classificador sinaliza o trabalho ou o relatório do subagente, ou uma verificação de segurança de API separada recusa a revisão, o relatório ainda é entregue, precedido por um aviso de segurança. Quando o classificador não está disponível para a revisão, o relatório chega com uma nota para verificar o trabalho do subagente antes de agir com base nele.

[accordion] Custo e latência

As requisições do classificador de Claude Code podem executar em um modelo diferente da sua seleção de /model. Consulte em qual modelo elas executam.

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 tokens. Cada verificação envia uma parte da transcrição mais a ação pendente, adicionando uma ida e volta antes da execução. Leituras e edições no diretório de trabalho fora de caminhos protegidos pulam o classificador, então a sobrecarga vem principalmente de comandos de shell e operações de rede. Onde o servidor revisa as ações como parte das requisições ao modelo da sessão, não há chamadas separadas do classificador a contar; consulte Revisão do classificador no servidor.

Acesso à rede em sandbox não adiciona requisições do classificador por conexão. O classificador julga os hosts que um comando nomeia junto com o comando em uma única revisão, e Claude Code verifica cada conexão em relação à lista aprovada sem chamar o classificador novamente.

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ê, embora um mod que você instalou ainda possa aprovar algumas dessas chamadas. Para verificar quais chamadas um mod pode aprovar, veja Estender permissões com hooks.

Claude ainda executa ações que não precisam de aprovação no modo Manual, como leituras de arquivo dentro de seus diretórios de trabalho e comandos Bash somente leitura. Ações que correspondem às suas regras permissions.allow e chamadas aprovadas por um hook PreToolUse também são executadas. Use este modo para pipelines de CI ou ambientes restritos onde você pré-define o que Claude pode fazer; a sessão nunca aguarda entrada. A barra de status mostra ⏵⏵ don't ask on neste modo.

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 _meta["anthropic/requiresUserInteraction"] da mesma forma, porque seu cartão de aprovação precisa de uma resposta que este modo nunca coleta.

Uma regra de permissão ou um hook PreToolUse não pode aprovar estes:

• Remoções rm e rmdir reconhecidas de caminhos críticos, como rm -rf / e rm -rf ~
• Leituras de um caminho de rede

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.

Mesmo no modo bypassPermissions, cada uma das ações que nenhum modo auto-aprova recebe um prompt ou uma negação, embora você possa desativar o prompt para comandos rm perigosos. Ler o artefato público de outra organização requer sua aprovação, e este modo não a solicita, então Claude não consegue ler um. As Remove-Item no PowerShell negações também se aplicam neste modo.

Duas salvaguardas de mensagens entre sessões ainda se aplicam neste modo, e em sessões de modo plan interativas 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 de terminal interativas com permissões de bypass disponíveis, Claude Code também não impõe os bloqueios do modo de planejamento. 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 de caminhos críticos reconhecidas via rm e rmdir ainda solicitam.

O modo plan mantém seus bloqueios em qualquer lugar onde Claude Code é executado sem um terminal interativo, incluindo execuções não-interativas com -p, sessões do Agent SDK, e conversas no painel de chat da extensão VS Code. Lá, --allow-dangerously-skip-permissions torna bypassPermissions selecionável depois.

[!WARNING]

Use este modo apenas em ambientes isolados como contêineres, VMs ou dev containers sem acesso à internet, onde Claude Code não consegue danificar seu sistema host.

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:

• Se você aceitar: Claude Code define skipDangerousModePermissionPrompt como true em ~/.claude/settings.json, para que sessões posteriores ignorem o diálogo. Para ver o diálogo novamente, remova a chave desse arquivo ou defina-a como false. A referência skipDangerousModePermissionPrompt lista os outros arquivos de configurações onde você ou sua organização podem defini-la.
• Se você recusar: Claude Code sai.

Em modo não interativo nenhum diálogo é mostrado.

Uma sessão em segundo plano respeita sua aceitação quando ela está registrada nas configurações de usuário ou nas configurações gerenciadas:

• Sem aceitação registrada, claude --bg --permission-mode bypassPermissions é recusado. Aceite o diálogo em uma sessão interativa primeiro.

• Com skipDangerousModePermissionPrompt definido apenas em .claude/settings.local.json, a sessão em segundo plano inicia com a requisição de bypass ignorada:

  • Com --allow-dangerously-skip-permissions ignorada, bypassPermissions fica de fora do seu ciclo de Shift+Tab.
  • Com --permission-mode bypassPermissions ou --dangerously-skip-permissions ignorada, a sessão inicia no modo Manual em vez disso.

  Adicione "skipDangerousModePermissionPrompt": true a ~/.claude/settings.json e, em seguida, inicie uma nova sessão em segundo plano.

Em Linux e macOS, Claude Code recusa iniciar no modo bypassPermissions 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.

Sessões em nuvem não honram 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.

[!WARNING]

bypassPermissions não oferece proteção contra injeção de prompt ou ações não intencionais. Para verificações de segurança em segundo plano com muito menos prompts de permissão, use modo automático em vez disso. Administradores podem bloquear este modo definindo permissions.disableBypassPermissionsMode como "disable" em configurações gerenciadas.

Permissões de bypass ignoradas em uma sessão em segundo plano

Este aviso significa que a sessão em segundo plano não encontrou sua aceitação do aviso de permissões de bypass nas configurações de usuário ou nas configurações gerenciadas, então ela ignorou a requisição de bypass feita na inicialização:

Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true

Adicione "skipDangerousModePermissionPrompt": true a ~/.claude/settings.json e, em seguida, inicie uma nova sessão em segundo plano.

claude agents mostra o aviso de permissões de bypass que as sessões interativas ignoram

Se claude agents mostrar o aviso de permissões de bypass embora suas sessões interativas o ignorem, verifique se skipDangerousModePermissionPrompt está definido em .claude/settings.local.json ou em um arquivo --settings. As sessões interativas consideram a chave ali como sua aceitação do aviso, e claude agents não. Encontrando-a ali ou não, aceite o aviso para adicionar a chave a ~/.claude/settings.json, onde claude agents a procura.

Caminhos protegidos

Gravações em um pequeno conjunto de caminhos nunca são auto-aprovadas, exceto no modo bypassPermissions e em sessões de terminal interativo em 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.

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.

Enquanto permissions.blockWritesOutsideWorkingDirectories estiver ativado, Claude Code recusa gravações de Write, Edit e NotebookEdit em arquivos de configurações em todos os modos de permissão.

Nos modos que roteiam gravações em caminhos protegidos para o classificador, uma gravação que a verificação de symlink resolve para um caminho protegido solicita você em vez disso quando o caminho que Claude solicitou não é em si protegido.

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 na pasta .claude/ do projeto ou em ~/.claude/ pode oferecer uma destas opções com escopo de sessão:

• Para a pasta .claude/ do projeto: Sim, e permitir que Claude edite arquivos na pasta .claude deste projeto para esta sessão
• Para ~/.claude/: Sim, e permitir que Claude edite arquivos em sua pasta ~/.claude para esta sessão

Diretórios protegidos:

• .git
• .config/git
• .vscode
• .idea
• .husky
• .cargo
• .devcontainer
• .yarn
• .mvn
• .claude, com algumas exceções, como:
  • Os próprios git worktrees do Claude em .claude/worktrees/
  • Os próprios arquivos de plano da sessão atual em ~/.claude/plans/, ou no plansDirectory que você definir
  • O próprio diretório de rascunho de uma sessão em segundo plano em ~/.claude/jobs/<id>/tmp/
  • Arquivos markdown no diretório de memória automática do projeto, como ~/.claude/projects/<project>/memory/, em uma sessão iniciada sem --restricted
  • Arquivos markdown em um diretório de memória de subagente, como .claude/agent-memory/, em uma sessão iniciada sem --restricted
• Um diretório que você carregou com --plugin-dir, porque Claude Code recarrega e executa o código de um mod a partir dele quando um arquivo muda
• ~/.claude/dev-mods/, ou dev-mods/ no diretório para o qual CLAUDE_CONFIG_DIR aponta, onde Claude salva os mods que ele escreve para você

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
• remote-settings.json, a cópia armazenada das configurações gerenciadas pelo servidor da sua organização, e os arquivos de assinatura, sincronização e consentimento que Claude Code mantém junto com ela, em ~/.claude ou no diretório para o qual CLAUDE_CONFIG_DIR aponta
• Um arquivo que você passou para --settings, --mcp-config ou --agents ao iniciar a sessão
• O arquivo para o qual seu arquivo de configurações de usuário, de projeto ou local aponta quando o próprio arquivo de configurações é um link simbólico, por exemplo, para um repositório de dotfiles. Nos modos que roteiam gravações em caminhos protegidos para o classificador, uma gravação nesse arquivo solicita você em vez disso, mesmo quando uma regra de permissão corresponde. Se o caminho do próprio arquivo também for o de um arquivo de configurações, como .claude/settings.json em outra pasta, a gravação vai para o classificador como as demais gravações em caminhos protegidos

Caminhos críticos

Os caminhos críticos são os diretórios que Claude Code protege dos comandos rm e rmdir, como a raiz do sistema de arquivos, seu diretório home e seu diretório de trabalho. Claude Code verifica esses comandos antes que sejam executados, e nenhuma regra de permissão aprova um comando cujo alvo ele reconhece como um caminho crítico. A verificação pode deixar passar alguns comandos, então ela não substitui um controle do sistema operacional como o sandboxing.

Uma remoção de caminho crítico é um comando rm ou rmdir cujo alvo Claude Code reconhece como um caminho crítico. Nenhum hook PreToolUse que retorna "allow" aprova uma remoção desse tipo. Uma regra de permissão ou um hook PreToolUse não pode aprová-la nem mesmo nos modos de permissão que pulam outros prompts.

[!WARNING]

Um comando que a verificação deixa passar não recebe nenhum tratamento especial, então qualquer coisa que aprove comandos Bash na sua sessão pode aprová-lo sem prompt. Isso inclui uma regra de permissão, o modo bypassPermissions e o modo de permissão automática do sandbox. A verificação se aplica a rm e rmdir, então outros comandos aprovados também podem excluir caminhos críticos.

Estes controles se aplicam independentemente de a verificação reconhecer ou não um comando:

• Regras de negação: uma regra de negação que corresponde ao comando o bloqueia, embora um mod que você instalou ainda possa aprovar algumas dessas chamadas
• Sandboxing: o sandboxing faz com que o sistema operacional limite em quais caminhos os comandos Bash podem gravar. Comandos em sandbox ainda podem excluir seu diretório de trabalho
• Modo de sandbox estrito: por padrão, um comando em sandbox pode ser executado novamente fora do sandbox, e uma regra de permissão ou o modo bypassPermissions pode aprovar essa nova tentativa sem prompt. O modo de sandbox estrito desativa essa nova tentativa

O que acontece com uma remoção que Claude Code reconhece depende do seu modo de permissão. Remove-Item e os built-ins de remoção cmd têm suas próprias verificações, cobertas em Remove-Item em PowerShell.

Quais caminhos são críticos

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. No Windows, seu nome curto 8.3 também conta, como C:\Users\LONGNA~1
• Raízes de unidade do Windows e seus diretórios de nível superior, como C:\ e C:\Windows. Grafias como \\?\C:\ e \\localhost\C$ contam como C:\
• 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

Para caminhos de unidades montadas como /mnt/c ou /Volumes/USB, consulte O prompt de unidade montada.

As verificações do nome curto 8.3 do diretório home e das grafias \\?\C:\ e \\localhost\C$ requerem Claude Code v2.1.292 ou posterior.

Outros alvos que contam como caminhos críticos

Claude Code também trata os seguintes alvos rm e rmdir como caminhos críticos. A última coluna diz por que cada um conta.

Para desativar a verificação em um alvo que é apenas saída de substituição de comando, defina CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 no ambiente que inicia Claude Code.

Remoções dentro de comandos aninhados e scripts inline

Claude Code também procura dentro dessas construções:

• Comandos aninhados: uma subshell com (...), um grupo de chaves com { ...; }, substituição de comando com $(...) ou backticks, ou substituição de processo com <(...). Claude Code encontra uma remoção de caminho crítico independentemente de estar dentro da forma aninhada, como em (rm -rf ~) ou echo "$(rm -rf ~)", ou em outro lugar no mesmo comando.
• Scripts inline: um script passado para sh, bash, zsh ou um shell POSIX semelhante com -c, como em bash -c 'rm -rf ~'.
  • Quando o script está entre aspas duplas, o shell invocador expande suas variáveis antes que o shell interno receba o script. Em find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \;, o comando se expande para uma remoção da raiz do sistema de arquivos uma vez por correspondência, e Claude Code a trata como uma remoção de caminho crítico.
  • Um script entre aspas simples que vincula $1 a um valor real, como sh -c 'rm -rf "$1"/*' _ {} faz, não é sinalizado.

Para desativar a verificação em um caminho crítico digitado diretamente em um script -c, como ~, defina CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 no ambiente que inicia Claude Code.

Reescrever um comando sinalizado

Como reescrever um comando para que passe na verificação depende de qual dos outros alvos ele usa:

• Um glob ou barra à direita sob uma variável como $DIR: proteja cada expansão para que o shell pare com um erro quando a variável não estiver definida ou vazia, como em rm -rf "${DIR:?}"/*, ou use um caminho literal. Uma remoção cujas expansões estão todas protegidas dessa forma passa nessa verificação, então em modo bypassPermissions ela é executada sem um prompt, a menos que outra verificação de caminho crítico a sinalize.
• Um glob ou barra à direita sob uma variável que normalmente está definida, como $HOME: use um caminho literal.
• Uma variável atribuída de uma substituição de impressão de diretório: use um caminho literal. Uma proteção "${D:?}" não limpa essa verificação, porque a variável não está vazia.
• Um alvo que é apenas saída de substituição de comando: execute a substituição por conta própria primeiro, depois remova os caminhos literais que ela imprime. O prompt diz a Claude para fazer o mesmo.

Para um glob ou barra à direita sob uma variável, o prompt nomeia o rm sinalizado e diz como reescrevê-lo para que a verificação passe.

O prompt Dangerous rm operation not ruled out

O motivo completo diz:

Dangerous rm operation not ruled out — the shell may read this command differently than it was parsed

Esse motivo significa que o shell pode ler o comando de forma diferente de como Claude Code o leu, então uma remoção pode estar em uma parte não verificada, mesmo sem nenhum rm presente. Em modo auto ou bypassPermissions, uma negação com esta frase vem da mesma verificação:

This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed.

Você recebe o prompt ou a negação que uma remoção de caminho crítico recebe no seu modo de permissão, incluindo bypassPermissions, embora você possa desativar esse prompt no modo bypassPermissions. Você não pode aprovar o comando com uma regra de permissão Bash ou Bash(*), com o modo de permissão automática do sandbox ou com um hook PreToolUse que retorna "allow". Leia o comando e, em seguida, aprove o prompt ou, após uma negação, execute-o no seu shell.

O prompt de unidade montada

O prompt de unidade montada aparece no macOS, Linux e WSL quando um rm recursivo tem como alvo um caminho de unidade montada listado, como /mnt/c ou /Volumes/USB/build. Seu motivo diz Dangerous rm operation on mounted drive path: <path>. Um alvo /* recebe o prompt sem a flag recursiva, já que Claude Code lê rm /Volumes/USB/build/* como uma remoção de /Volumes/USB/build.

Mesmo com uma regra de permissão para rm, Claude Code trata o comando como uma remoção de caminho crítico: um prompt ou uma negação dependendo do seu modo de permissão. Aprove o prompt para deixar o rm ser executado, ou desative o prompt.

Caminhos que recebem o prompt de unidade montada

Compare o alvo da sua remoção rm recursiva ou /* com estes formatos de caminho, em que cada espaço reservado como <drive> ou <name> representa exatamente um segmento de caminho:

Para um rm recursivo ou não recursivo no próprio /Volumes, /media ou /mnt, você vê em vez disso o motivo de caminho crítico Dangerous rm operation on critical path: <path>.

Um alvo relativo conta a partir do seu diretório de trabalho, então rm -rf build enquanto você trabalha em /Volumes/USB tem como alvo /Volumes/USB/build e recebe o prompt.

Desativar o prompt de unidade montada

Para deixar de receber o prompt de unidade montada enquanto os prompts de outras causas permanecem, inicie Claude Code com CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1 em seu ambiente. Por exemplo, defina a variável no seu shell e inicie claude a partir dele:

export CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1
claude

Em uma sessão iniciada dessa forma, o prompt de unidade montada deixa de aparecer para uma unidade inteira como /Volumes/USB e para os outros caminhos listados. Se você permitir Bash(rm *), usar o modo Manual e trabalhar em /Volumes/USB, então rm -rf build é executado sem prompt.

Um prompt que ainda mostra Dangerous rm operation on mounted drive path significa que a variável não está chegando à sessão:

• Variável em um arquivo de configurações: Claude Code ignora a variável no bloco env de um arquivo de configurações, qualquer que seja o tipo de arquivo de configurações, então defina a variável onde você inicia claude
• Sessão iniciada sem a variável: inicie claude novamente a partir de um ambiente em que a variável esteja definida, já que uma sessão em execução não a captura

Remoções que ainda solicitam confirmação com o prompt de unidade montada desativado

No modo Manual com uma regra de permissão para rm, um rm em um caminho de unidade montada ainda pode gerar um prompt, sem o motivo Dangerous rm operation on mounted drive path:

• Alvo fora dos seus diretórios de trabalho: rm -rf /Volumes/USB/other enquanto você trabalha em /Volumes/USB/project recebe um prompt. Para interromper esse prompt, adicione um diretório que contenha o alvo à sessão
• Alvo com um *: rm -rf build/* recebe um prompt. Aprove esse prompt para executar o comando, ou peça a Claude para nomear cada alvo sem um *
• Alvo que é um caminho crítico: o próprio /mnt e o próprio diretório de trabalho continuam sendo caminhos críticos, então rm -rf em qualquer um deles recebe um prompt. Aprove esse prompt para deixar o rm ser executado

Remoções de caminho crítico em cada modo de permissão

O que Claude Code faz com uma remoção de caminho crítico depende do seu modo de permissão:

Se uma regra de solicitação explícita corresponder ao comando, Claude Code o solicita em vez disso, mesmo em modo auto e sem um limite de tempo. Em modos que solicitam, um hook PermissionRequest pode responder ao prompt.

Para executar essas remoções sem prompt no modo bypassPermissions, consulte Desativar o prompt de remoção de caminho crítico.

Limites de tempo e negações em modos auto e bypassPermissions

Em modos auto e bypassPermissions, o prompt do terminal para uma remoção de caminho crítico mostra uma contagem regressiva de dois minutos:

• Se a contagem regressiva terminar antes de você responder, Claude Code nega o comando e diz a Claude o que fazer em vez disso, para que uma sessão desatendida continue funcionando.
• Pressione qualquer tecla enquanto o prompt está aberto para parar a contagem regressiva e manter o prompt aguardando sua resposta.
• Após três desses prompts expirarem sem resposta em uma sessão, Claude Code para de mostrá-los e nega remoções de caminho crítico adicionais imediatamente. Enviar uma nova mensagem reinicia a contagem.

O limite de tempo se aplica no Claude Code v2.1.281 e posterior, assim como a negação do modo auto fora do terminal.

Longe do terminal, você não recebe esse prompt:

Onde quer que a remoção seja negada, você pode ler o comando inteiro e executá-lo no seu shell.

Para mudar o que você recebe em cada modo, defina CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT como 1:

• bypassPermissions: o prompt do terminal não tem limite de tempo, e o painel de chat do VS Code pergunta a você
• auto: o classificador decide, no terminal, no painel de chat do VS Code, em execuções com -p e em sessões do Agent SDK

Defina-a no ambiente que inicia Claude Code, como seu shell ou a opção env do SDK, e não em um arquivo de configurações do Claude Code. Para o painel de chat, adicione-a a claudeCode.environmentVariables no settings.json de usuário do próprio VS Code e, em seguida, inicie uma nova conversa:

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT", "value": "1" }
  ]
}

Desativar o prompt de remoção de caminho crítico no modo bypassPermissions

Para executar comandos Bash rm e rmdir que têm como alvo caminhos críticos sem prompt no modo bypassPermissions, inicie Claude Code com CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 em seu ambiente. Isso requer Claude Code v2.1.311 ou posterior. Claude Code lê a variável apenas do ambiente de inicialização e a ignora no bloco env de um arquivo de configurações. Por exemplo, defina-a no seu shell e inicie claude a partir dele:

[tab] macOS, Linux, WSL

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[tab] Windows PowerShell

$env:CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS = "1"
claude --permission-mode bypassPermissions

[tab] Windows CMD

set CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[!WARNING]

Com esta variável definida, você perde um prompt de segurança para exclusões destrutivas: um comando como rm -rf ~ pode ser executado sem perguntar a você. Defina-a apenas em um ambiente isolado cujo conteúdo você possa se dar ao luxo de perder.

As remoções são executadas sem prompt apenas no próprio modo bypassPermissions, não no modo de planejamento, e apenas para o que a verificação de caminho crítico sinaliza nas ferramentas Bash e Monitor. Isso inclui comandos que Claude Code não consegue analisar completamente, que também são executados sem prompt.

Avisos de inicialização sobre o prompt de remoção de caminho crítico

Para verificar se CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS está funcionando, leia a linha que Claude Code imprime na inicialização. Em uma execução com -p, ela aparece no stderr. Em um aplicativo do Agent SDK, passe a opção stderr para lê-la. A linha diz uma destas coisas:

• is set, so dangerous rm commands can run without a prompt: as remoções podem ser executadas sem prompt depois que as configurações gerenciadas e os hooks de plugins forem carregados. Se as remoções continuarem recebendo um prompt ou uma negação, consulte Por que o prompt de remoção de caminho crítico permanece ativo
• has no effect in this session: as remoções mantêm seu prompt ou negação habitual durante toda a sessão. Para mudar isso, encontre seu caso em Por que o prompt de remoção de caminho crítico permanece ativo
• has no effect while the Windows registry cannot be read for managed settings: as remoções mantêm seu prompt ou negação habitual, e a variável entra em vigor sem reinicialização se uma leitura posterior do registro for bem-sucedida. Se as remoções continuarem recebendo um prompt ou uma negação, consulte Por que o prompt de remoção de caminho crítico permanece ativo

A ausência da linha não significa que o prompt está ativo: um aplicativo do Agent SDK sem a opção stderr não vê nenhuma linha, e as remoções ainda podem ser executadas sem prompt. Caso contrário, verifique se você definiu a variável no ambiente de inicialização, se a sessão pode entrar no modo bypassPermissions e se claude não está dentro de outra sessão. Algumas sessões iniciam sem a variável.

Se você vir uma dessas linhas e não tiver definido a variável, encontre onde ela está definida, como no perfil do seu shell, e remova-a.

Por que o prompt de remoção de caminho crítico permanece ativo

Se CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS não tiver efeito e as remoções mantiverem seu prompt ou negação habitual, verifique causas como estas:

• Outra coisa trata os prompts de permissão: uma --permission-prompt-tool ou um callback canUseTool do Agent SDK sem --permission-prompts none, um hook PermissionRequest com qualquer matcher, ou um mod que trata esse evento. Remova o hook, o mod, a ferramenta ou o callback e reinicie claude
• O painel de chat da extensão VS Code ou o aplicativo Desktop executa a sessão: inicie claude em um terminal, como o terminal integrado de um IDE
• Uma regra cobre Bash, Edit ou Read: uma regra de negação ou de solicitação que tem como alvo uma dessas ferramentas, na inicialização ou quando Claude Code a lê durante a sessão, mesmo que você a remova depois. Remova a regra e reinicie claude. Para deixar uma ferramenta de fora, use --tools em vez de uma regra de negação
• permissions.blockReadsOutsideWorkingDirectories está ativada: remova a configuração de todos os arquivos de configurações que a definem como true e, em seguida, reinicie claude
• claude é executado dentro de outra sessão: um claude iniciado a partir da ferramenta Bash de uma sessão ou de um hook, mesmo com a variável em sua linha de comando. Inicie claude a partir do seu próprio shell. Não confie nesse limite de sessões aninhadas como uma fronteira de segurança
• Um hook PreToolUse responde ask para uma remoção: altere o que o hook retorna
• Claude Code inicia a sessão por você: sessões em segundo plano, colegas de uma equipe de agentes em painéis divididos e sessões que um servidor de Remote Control cria iniciam sem a variável. Inicie claude a partir do seu próprio shell
• As configurações gerenciadas não podem ser lidas: Claude Code não conseguiu ler suas fontes de configurações gerenciadas. Se as configurações gerenciadas pelo servidor continuarem falhando ao carregar, consulte Remote managed settings failed to load. Para qualquer outra falha que não seja uma consulta ao registro, peça a quem gerencia essa fonte para corrigi-la
• O registro do Windows não pode ser consultado: no Windows e no WSL, a variável precisa de uma resposta do registro, mesmo quando o WSL não o usa para configurações. A consulta pode falhar durante toda a sessão em um Windows que não está em inglês, no WSL com a interoperabilidade desativada ou em um contêiner em um kernel WSL2. Se a interoperabilidade estiver desativada, ative-a. Caso contrário, execute essas remoções você mesmo

Remove-Item em PowerShell

Quando você habilita a ferramenta PowerShell, Claude Code dá a Remove-Item e aos built-ins cmd rd, rmdir, del e erase suas próprias verificações, separadas da lista de caminhos críticos rm. Para Remove-Item, 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.

O caso de caminhos do sistema também se aplica a rd, rmdir, del e erase quando Claude os executa através de cmd, como em cmd /c rd /s /q C:\Users. Por padrão, Claude Code nega tal comando em todos os modos, sem o solicitar. Esta verificação cmd requer Claude Code v2.1.283 ou posterior.

Ao julgar um alvo cmd, Claude Code trata uma variável PowerShell que segue texto literal como vazia. Isso torna cmd /c rd /s /q "C:\$name" uma remoção de C:\, então também é negada. Um wildcard à direita conta como a pasta que esvazia, então cmd /c del /q C:\* é negado e cmd /c del /q dist\* em seu projeto não é.

Para desativar a verificação cmd, defina CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 no ambiente que inicia Claude Code. Claude Code ignora esta variável no bloco env de um arquivo de configurações. Remove-Item em um caminho do sistema permanece negado de qualquer forma.

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