SpyBara
Go Premium

permission-modes.md 2026-07-13 23:57 UTC to 2026-07-14 23:01 UTC

158 added, 151 removed.

2026
Tue 21 23:00 Mon 20 23:01 Sat 18 16:02 Fri 17 22:57 Thu 16 22:59 Wed 15 22:00 Tue 14 23:01 Mon 13 23:57 Sat 11 19:03 Fri 10 17:00 Thu 9 23:58 Wed 8 16:02 Tue 7 16:02 Mon 6 23:57 Sat 4 03:01 Fri 3 23:00 Thu 2 23:59 Wed 1 21:01

Escolha um modo de permissão

Controle se Claude pede permissão antes de editar arquivos ou executar comandos. Alterne modos com Shift+Tab na CLI ou use o seletor de modo no VS Code, Desktop e claude.ai.

Quando Claude quer editar um arquivo, executar um comando shell ou fazer uma solicitação de rede, ele pausa e pede que você aprove a ação. Os modos de permissão controlam com que frequência essa pausa acontece. O modo que você escolhe molda o fluxo de uma sessão: o modo Manual faz você revisar cada ação conforme ela chega, enquanto modos mais flexíveis permitem que Claude trabalhe em trechos mais longos e ininterruptos e relate quando terminar. Escolha mais supervisão para trabalhos sensíveis, ou menos interrupções quando você confia na direção.

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.

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

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

Em todos os modos, exceto bypassPermissions, as gravações em caminhos protegidos nunca são auto-aprovadas, protegendo o estado do repositório e a configuração do próprio Claude contra corrupção acidental.

Os modos definem a linha de base. Sobreponha regras de permissão para pré-aprovar ou bloquear ferramentas específicas. Regras de negação e regras de solicitação explícita se aplicam em todos os modos, incluindo bypassPermissions. Regras de permissão não têm efeito nesse modo porque tudo mais já está aprovado.

Alternar modos de permissão

Você pode alternar modos durante uma sessão, na inicialização ou como padrão persistente. O modo é definido através desses controles, não pedindo ao Claude no chat. Selecione sua interface abaixo para ver como alterá-lo.

Durante uma sessão: pressione Shift+Tab para alternar default → acceptEdits → plan. O modo atual aparece na barra de status. {/* min-version: 2.1.203 */}O modo manual, default nesse ciclo, mostra um badge cinza ⏸ manual mode on. Antes da v2.1.203, a barra de status não mostrava nenhum badge no modo Manual.

Nem todo modo está no ciclo padrão:

  • auto: aparece quando sua conta atende aos requisitos do modo automático; alternar para ele muda os modos sem um prompt de confirmação
  • bypassPermissions: aparece depois que você inicia com --permission-mode bypassPermissions, --dangerously-skip-permissions ou --allow-dangerously-skip-permissions; a variante --allow- adiciona o modo ao ciclo sem ativá-lo
  • dontAsk: nunca aparece no ciclo; defina-o com --permission-mode dontAsk

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

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

claude --permission-mode plan

Como padrão: defina defaultMode em settings.

{
"permissions": {
"defaultMode": "acceptEdits"
}
}

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

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

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

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

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.

Use acceptEdits quando você quiser revisar as alterações 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 plan

O modo plan instrui Claude a pesquisar e propor alterações sem realizá-las. Claude lê arquivos, executa comandos shell para explorar e escreve um plano, mas não edita sua fonte. Os prompts de permissão se aplicam como fazem no modo Manual, a menos que modo automático esteja disponível e useAutoModeDuringPlan esteja ativado, que é o padrão. Com o modo automático ativo, o classificador aprova comandos somente leitura, como pesquisas e leituras de arquivo, sem solicitar. As edições permanecem bloqueadas de qualquer forma até que você aprove o plano.

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

claude --permission-mode plan

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

Revise e aprove um plano

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

  • Aprovar e iniciar no modo automático
  • Aprovar e aceitar edições
  • Aprovar e revisar cada edição manualmente
  • Continuar planejando com feedback
  • Refinar com Ultraplan para revisão baseada em navegador

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

Pressione Ctrl+G para abrir o plano proposto em seu editor de texto padrão e editá-lo diretamente antes de Claude prosseguir. Quando showClearContextOnPlanAccept está ativado, cada opção de aprovação também oferece limpar o contexto de planejamento primeiro.

Aceitar um plano também nomeia a sessão a partir do conteúdo do plano automaticamente, a menos que você já tenha definido um nome com --name ou /rename.

Defina o modo plan como padrão

Para tornar o modo plan o padrão para um projeto, defina defaultMode em .claude/settings.json:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Elimine prompts de permissão com modo automático

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

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

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

  • Plano: Todos os planos.
  • Proprietário: em Team e Enterprise, um Proprietário deve habilitá-lo nas configurações de administrador do Claude Code antes que os usuários possam ativá-lo. Os administradores também podem desativar o modo automático definindo permissions.disableAutoMode como "disable" nas configurações gerenciadas. Para a aba Code do aplicativo desktop, disableAutoMode é o controle no nível da organização, e o toggle de configurações de administrador não se aplica.
  • Modelo: na API Anthropic, Claude Opus 4.6 ou posterior, ou Sonnet 4.6 ou posterior. No Amazon Bedrock, na Agent Platform do Google Cloud, no Microsoft Foundry e em sessões do gateway de aplicativos Claude conectadas, apenas Claude Sonnet 5, Opus 4.7 e Opus 4.8. Modelos mais antigos, incluindo Sonnet 4.5, Opus 4.5, Haiku e modelos claude-3, não são suportados em nenhum provedor.
  • Provedor: disponível por padrão na API Anthropic, Amazon Bedrock, Agent Platform do Google Cloud, Microsoft Foundry e sessões do gateway de aplicativos Claude conectadas. {/* min-version: 2.1.207 */}Na v2.1.158 até v2.1.206, o modo automático estava desativado em todos esses provedores, exceto na API Anthropic, até que você definisse CLAUDE_CODE_ENABLE_AUTO_MODE=1; v2.1.207 removeu o requisito.

Se Claude Code relatar o modo automático como indisponível, um desses requisitos não foi atendido; isso não é uma interrupção transitória. Uma mensagem separada que nomeia um modelo e diz que o modo automático "não consegue determinar a segurança" de uma ação é uma interrupção transitória do classificador; consulte a referência de erros.

Se você definir defaultMode: "auto" nas configurações e a sessão começar no modo default sem erro, a configuração provavelmente está em .claude/settings.json ou .claude/settings.local.json. Claude Code v2.1.142 e posterior ignoram auto desses arquivos para que um repositório não possa se conceder modo automático. Mova-o para ~/.claude/settings.json.

Modo automático no Bedrock, Agent Platform ou Foundry

No Amazon Bedrock, na Agent Platform do Google Cloud, no Microsoft Foundry e em sessões do gateway de aplicativos Claude conectadas, o modo automático aparece no ciclo Shift+Tab por padrão. Aparecer no ciclo não muda o modo em que uma sessão começa: as sessões ainda começam em seu defaultMode, que é Manual a menos que você o altere. Apenas Claude Sonnet 5, Opus 4.7 e Opus 4.8 são suportados nesses provedores.

Para tornar o modo automático o modo de início padrão, defina "permissions": {"defaultMode": "auto"} nas configurações de usuário ou gerenciadas.

Para impedir que desenvolvedores usem o modo automático, defina disableAutoMode como "disable" nas configurações gerenciadas. Isso remove auto do ciclo Shift+Tab e rejeita --permission-mode auto na inicialização.

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

O que o classificador bloqueia por padrão

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

Bloqueado por padrão:

  • Download e execução de código, como curl | bash
  • Envio de dados sensíveis para endpoints externos
  • Implantações e migrações de produção
  • Exclusão em massa no armazenamento em nuvem
  • Concessão de permissões de IAM ou repositório
  • Modificação de infraestrutura compartilhada
  • Destruição irreversível de arquivos que existiam antes da sessão
  • Force push
  • {/* min-version: 2.1.203 */}Pushing para o branch padrão do repositório quando o push contém conteúdo sensível, como segredos ou dados pessoais ou confiados, contém alterações ocultadas ou mal descritas em relação ao que você pediu, contém conteúdo portado ou lido pela primeira vez de fora do repositório, ou contorna uma pull request, revisão ou verificação que você pediu. Um push simples para o branch padrão não é bloqueado por si só, e limpar um push sinalizado requer nomear o conteúdo sinalizado ou a revisão contornada, não apenas o push. O classificador é uma camada: as regras permissions.deny se aplicam em todos os modos e podem bloquear pushes para o branch padrão completamente, e a proteção de branch do próprio remote ainda se aplica. Antes de v2.1.203, qualquer push direto para o branch padrão era bloqueado
  • {/* min-version: 2.1.182 */}git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop ou git stash clear, que o classificador presume descartaria alterações não confirmadas
  • git commit --amend quando o commit no HEAD não foi criado nesta sessão
  • {/* min-version: 2.1.198 */}A partir de v2.1.198, git commit --amend quando o commit no HEAD já foi enviado. Uma reword apenas de mensagem não é bloqueada: --amend -m sem nada recém-preparado, em um commit que Claude criou durante esta sessão
  • terraform destroy, pulumi destroy, cdk destroy ou terragrunt destroy, e aplicação de um plano que destrói recursos

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

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

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

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

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

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

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

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

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

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

Permitido por padrão:

  • Operações de arquivo local em seu diretório de trabalho
  • Instalação de dependências declaradas em seus arquivos de lock ou manifestos
  • Leitura de .env e envio de credenciais para sua API correspondente
  • Solicitações HTTP somente leitura
  • Pushing para o branch em que você começou ou um que Claude criou

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

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

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

  • Um allow é reutilizado até que novo conteúdo entre na conversa, ponto em que esse host é verificado novamente
  • Na CLI interativa, um deny é descartado quando o turno termina
  • No modo não interativo e sessões do Agent SDK não há limite de turno, então um deny é reutilizado para o resto da execução
  • Alterar seu modo de permissão ou regras descarta todos os veredictos em cache

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

Limites que você declara na conversa

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

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

Quando o modo automático volta

Cada ação negada mostra uma notificação e aparece em /permissions na aba Recently denied, onde você pode pressionar r para tentar novamente com uma aprovação manual.

Se o classificador bloquear uma ação 3 vezes seguidas ou 20 vezes no total, o modo automático pausa e Claude Code retoma o prompt. Aprovar a ação solicitada retoma o modo automático. Esses limites não são configuráveis. Qualquer ação permitida redefine o contador consecutivo, enquanto o contador total persiste para a sessão e redefine apenas quando seu próprio limite dispara um fallback.

No modo não interativo com a flag -p, bloqueios repetidos abortam a sessão, pois não há usuário para solicitar.

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

Cada ação passa por uma ordem de decisão fixa. O primeiro passo correspondente vence: 
1. Ações correspondentes a suas [regras de permissão ou negação](/anthropic/claude-code/history/docs/pt/2026-07-13-2357..2026-07-14-2301/permissions/#manage-permissions) resolvem imediatamente, exceto escritas em [caminhos protegidos](#protected-paths), que são roteadas para o classificador mesmo quando uma regra de permissão corresponde
2. Ações somente leitura e edições de arquivo em seu diretório de trabalho são auto-aprovadas, exceto escritas em [caminhos protegidos](#protected-paths)
3. Tudo mais vai para o classificador. {/* min-version: 2.1.199 */}A partir de v2.1.199, uma ferramenta MCP marcada com [`_meta["anthropic/requiresUserInteraction"]`](/pt/mcp#require-approval-for-a-specific-tool) pula o classificador e o solicita diretamente, então uma etapa de consentimento nunca é auto-aprovada em nome do autor da ferramenta
4. Se o classificador bloquear, Claude recebe o motivo e tenta uma alternativa

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

* Blanket `Bash(*)` ou `PowerShell(*)`
* Intérpretes com wildcard como `Bash(python*)`
* Comandos de execução do gerenciador de pacotes
* Regras de permissão `Agent`

Regras estreitas como `Bash(npm test)` são mantidas. Regras descartadas são restauradas quando você sai do modo automático.

O classificador vê mensagens de usuário, chamadas de ferramenta e conteúdo de seu CLAUDE.md. Os resultados da ferramenta são removidos, então conteúdo hostil em um arquivo ou página da web não pode manipulá-lo diretamente. Uma sonda separada do lado do servidor verifica os resultados da ferramenta recebidos e sinaliza conteúdo suspeito antes que Claude o leia. Para mais sobre como essas camadas funcionam juntas, consulte o [anúncio do modo automático](https://claude.com/blog/auto-mode) e o [aprofundamento de engenharia](https://www.anthropic.com/engineering/claude-code-auto-mode).
Como o modo automático lida com subagentes

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

  1. Antes de um subagente começar, a descrição da tarefa delegada é avaliada, então uma tarefa que parece perigosa é bloqueada no tempo de spawn.
  2. Enquanto o subagente executa, cada uma de suas ações passa pelo classificador com as mesmas regras que a sessão pai, e qualquer permissionMode no frontmatter do subagente é ignorado.
  3. Quando o subagente termina, o classificador revisa seu histórico de ação completo; se essa verificação de retorno sinalizar uma preocupação, um aviso de segurança é adicionado aos resultados do subagente.

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

Custo e latência

O classificador executa em um modelo configurado pelo servidor que é independente de sua seleção de /model, então alternar modelos não muda a disponibilidade do classificador. As chamadas do classificador contam para seu uso de token. Cada verificação envia uma porção da transcrição mais a ação pendente, adicionando uma volta antes da execução. Leituras e edições de diretório de trabalho fora de caminhos protegidos pulam o classificador, então a sobrecarga vem principalmente de comandos de shell e operações de rede. {/* min-version: 2.1.198 */}A partir de v2.1.198, um veredicto de rede de sandbox para um host e porta é reutilizado em vez de re-classificado em cada conexão, então conexões repetidas ao mesmo host não adicionam cada uma uma verificação. O que o classificador bloqueia por padrão descreve quanto tempo um allow e um deny duram.

Permitir apenas ferramentas pré-aprovadas com modo dontAsk

O modo dontAsk nega automaticamente toda chamada de ferramenta que de outra forma solicitaria confirmação. A barra de status mostra ⏵⏵ don't ask on enquanto este modo está ativo. Apenas ações que correspondem às suas regras permissions.allow e comandos Bash somente leitura podem ser executadas; regras explícitas de ask são negadas em vez de solicitar confirmação. {/* min-version: 2.1.199 */}A partir da v2.1.199, uma ferramenta MCP marcada com _meta["anthropic/requiresUserInteraction"] também é negada neste modo mesmo quando uma regra de permissão corresponde a ela, porque seu cartão de aprovação precisa de uma resposta que este modo nunca coleta. Isso torna o modo totalmente não interativo para pipelines de CI ou ambientes restritos onde você pré-define exatamente o que Claude pode fazer. Sessões em nuvem no Claude Code na web ignoram defaultMode: "dontAsk"; consulte bypassPermissions para detalhes.

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

claude --permission-mode dontAsk

Ignorar todas as verificações com o modo bypassPermissions

O modo bypassPermissions desativa prompts de permissão e verificações de segurança para que as chamadas de ferramentas sejam executadas imediatamente. A partir da v2.1.126, isso inclui escritas em caminhos protegidos, que versões anteriores ainda solicitavam. As regras ask explícitas ainda forçam um prompt neste modo, e remoções direcionadas à raiz do sistema de arquivos ou diretório inicial, como rm -rf / e rm -rf ~, ainda solicitam como um disjuntor contra erros do modelo. {/* min-version: 2.1.199 */}A partir da v2.1.199, ferramentas MCP marcadas com _meta["anthropic/requiresUserInteraction"] também ainda solicitam. Use este modo apenas em ambientes isolados como contêineres, VMs ou dev containers sem acesso à internet, onde Claude Code não pode danificar seu sistema host.

Você não pode entrar em bypassPermissions a partir de uma sessão que foi iniciada sem um dos sinalizadores de habilitação; reinicie com um para habilitá-lo:

claude --permission-mode bypassPermissions

O sinalizador --dangerously-skip-permissions é equivalente.

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

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

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

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

Caminhos protegidos

As gravações em um pequeno conjunto de caminhos nunca são aprovadas automaticamente, em todos os modos, exceto bypassPermissions. Isso evita corrupção acidental do estado do repositório e da configuração própria do Claude.

Modo Gravações em caminhos protegidos
default, acceptEdits, plan Solicitado
auto Roteado para o classificador
dontAsk Negado
bypassPermissions Permitido

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

Diretórios protegidos:

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

Arquivos protegidos:

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

Veja também

  • Permissões: regras de permitir, perguntar e negar; políticas gerenciadas
  • Configurar modo automático: informe ao classificador qual infraestrutura sua organização confia
  • Hooks: lógica de permissão personalizada via hooks PreToolUse e PermissionRequest
  • Ultraplan: execute o modo plan em uma sessão Claude Code na web com revisão baseada em navegador
  • 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