> ## Documentation Index > Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # 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](#eliminate-prompts-with-auto-mode), um segundo modelo, o classificador, revisa as ações em vez de você; [como o classificador avalia ações](#how-the-classifier-evaluates-actions) lista quais ações ele revisa e quais o ignora. Com Claude Code v2.1.283 ou posterior, o modo automático é 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 e Team. [Qual modo uma sessão inicia](#which-mode-a-session-starts-in) cobre as superfícies e configurações que alteram o modo de permissão inicial. Você também pode alterar o modo de permissão de uma sessão em execução a qualquer momento.

Modos disponíveis

Cada modo faz uma compensação diferente entre conveniência e supervisão. A tabela abaixo mostra o que Claude pode fazer sem um prompt de permissão em cada modo. O modo Manual aparece sob seu valor de configuração, `default`. | Modo | O que é executado sem perguntar | Melhor para | | :- | :- | :- | | `default` | Apenas leituras | Revisar cada ação você mesmo, trabalho sensível | | [`acceptEdits`](#auto-approve-file-edits-with-acceptedits-mode) | 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`](#analyze-before-you-edit-with-plan-mode) | Leituras, mais comandos aprovados pelo classificador quando [modo automático](#eliminate-prompts-with-auto-mode) está disponível | Explorando uma base de código antes de alterá-la | | [`auto`](#eliminate-prompts-with-auto-mode) | Tudo, com verificações de segurança em segundo plano | Tarefas longas, reduzindo fadiga de prompts | | [`dontAsk`](#allow-only-pre-approved-tools-with-dontask-mode) | Leituras de arquivos dentro dos seus diretórios de trabalho e ferramentas pré-aprovadas; qualquer coisa que geraria um prompt é negada | CI bloqueado e scripts | | [`bypassPermissions`](#skip-all-checks-with-bypasspermissions-mode) | 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"`. As gravações em [caminhos protegidos](#protected-paths) 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](#switch-permission-modes). Os modos definem a linha de base. Sobreponha [regras de permissão](/docs/pt/permissions#manage-permissions) 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`](/docs/pt/tools-reference#endconversation-tool-behavior) enquanto Claude ainda tiver pelo menos uma outra ferramenta que possa chamar. Regras de permissão não têm efeito em `bypassPermissions`.

Ações que nenhum modo auto-aprova

Claude Code não auto-aprova o seguinte em nenhum modo, incluindo `bypassPermissions`. Cada item vincula à seção que diz o que acontece em vez disso em cada modo: * Ferramentas correspondidas por uma [regra de solicitação](/docs/pt/permissions#manage-permissions) explícita * Ferramentas de conector que sua organização [definiu como `ask`](/docs/pt/mcp#organization-controls-on-connector-tools), em sessões onde essa configuração chega a Claude Code * Ferramentas que requerem interação do usuário: a ferramenta integrada `AskUserQuestion` e ferramentas MCP marcadas [`requiresUserInteraction`](/docs/pt/mcp#require-approval-for-a-specific-tool) * Remoções `rm` e `rmdir` direcionadas a um [caminho crítico](#critical-paths), que nenhuma regra de permissão ou hook `PreToolUse` `"allow"` aprova * As [salvaguardas de mensagens entre sessões](#skip-all-checks-with-bypasspermissions-mode) * Leituras fora dos diretórios de trabalho enquanto [`permissions.blockReadsOutsideWorkingDirectories`](/docs/pt/settings-reference#permissions-blockreadsoutsideworkingdirectories) está ativado: comandos Bash reconhecidos de leitura de arquivo e qualquer [retry não-sandboxizado](/docs/pt/sandboxing#the-unsandboxed-retry-escape-hatch) 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](/docs/pt/sandboxing) e o sandbox impõe o bloqueio.

Configurações comuns

Os modos de permissão decidem se Claude pede antes de uma ação, e o [sandbox Bash](/docs/pt/sandboxing) e os [limites de isolamento](/docs/pt/sandbox-environments) 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](#available-modes) lista o que é executado sem um prompt em cada modo. | Você quer | Comece com | Isolamento necessário | Notas | | :- | :- | :- | :- | | Revisar cada ação você mesmo | Modo Manual: `claude --permission-mode default` | Nenhum | Trabalho sensível, código desconhecido | | Iterar localmente com menos prompts, sem um classificador | Modo Manual mais o sandbox Bash em [modo auto-allow](/docs/pt/sandboxing#sandbox-modes): `claude --permission-mode default`, depois execute `/sandbox` e selecione auto-allow | O sandbox Bash integrado, em macOS, Linux e WSL2 | Regras de negação ainda se aplicam, e regras de solicitação que nomeiam um comando, como `Bash(git push *)`, ainda solicitam. Para ativar o sandbox a partir de um arquivo de configurações em vez disso, defina [`sandbox.enabled`](/docs/pt/settings-reference#sandbox-enabled) como `true` | | Explorar antes de alterar qualquer coisa | `claude --permission-mode plan` | Nenhum | Claude Code bloqueia edições até que você [aprove um plano](#review-and-approve-a-plan) | | Trabalhar sem supervisão em modo automático | `claude --permission-mode auto`, o [modo de permissão inicial integrado](#which-mode-a-session-starts-in) com v2.1.283 ou posterior | Nenhum; um sandbox ou contêiner adiciona defesa em profundidade | Requer um [modelo suportado](#eliminate-prompts-with-auto-mode), e sua organização pode [desativar o modo automático](#eliminate-prompts-with-auto-mode) | | Executar em CI com uma lista de permissões exata | `claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"` | Nenhum além do que seu executor de CI fornece | [Cloud sessions](/docs/pt/claude-code-on-the-web) ignora `dontAsk` de arquivos de configurações | | Executar totalmente sem supervisão dentro de um contêiner | `claude -p "" --dangerously-skip-permissions` | Obrigatório: um contêiner, VM ou o [runtime do sandbox](/docs/pt/sandbox-environments#sandbox-runtime); em Linux e macOS, execute como um [usuário não-root](#skip-all-checks-with-bypasspermissions-mode) | Cloud sessions ignora este modo de arquivos de configurações. Nesta execução `-p`, as [poucas chamadas que ainda solicitariam](#skip-all-checks-with-bypasspermissions-mode) são negadas em vez disso | O sandbox Bash e o modo automático funcionam independentemente e se combinam, com as exceções listadas em [Sandbox modes](/docs/pt/sandboxing#sandbox-modes). Para a interação completa, veja [Como sandboxing se relaciona com permissões e modos de permissão](/docs/pt/sandboxing#how-sandboxing-relates-to-permissions-and-permission-modes) e [Como isolamento se relaciona com modos de permissão](/docs/pt/sandbox-environments#how-isolation-relates-to-permission-modes).

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](/docs/pt/settings#where-settings-live) 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](#switch-permission-modes). Para o modo de permissão que Claude Code inicia uma sessão retomada, veja [modo de permissão ao retomar](/docs/pt/sessions#permission-mode-on-resume). 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](#switch-permission-modes). | Como você executa Claude Code | Modo de permissão inicial integrado | | :- | :- | | Qualquer arquivo de configurações define `disableAutoMode` como `"disable"` | `default` | | `claude -p` ou o [Agent SDK](/docs/pt/agent-sdk/permissions#permission-modes) | `default` em sessões que [buscam sinalizadores de recurso](/docs/pt/env-vars#features-that-need-feature-flag-fetching). Em sessões que não buscam, como em um provedor de terceiros ou com telemetria desativada, `auto` com Claude Code v2.1.285 ou posterior e `default` em versões anteriores. Uma sessão em uma organização cuja política retém o padrão `auto` inicia em `default` em vez disso | | Sua organização tem a [configuração HIPAA](#hipaa-configuration) aplicada e a sessão é [elegível para ela](/docs/pt/hipaa-setup#check-how-developers-sign-in-and-connect) | `default` com Claude Code v2.1.285 ou posterior; o modo auto continua disponível para alternar | | Em um terminal ou através da [extensão VS Code](/docs/pt/vs-code) | `auto` com Claude Code v2.1.283 ou posterior; em versões anteriores, `auto` em planos Pro, Max ou Team em sessões que [buscam sinalizadores de recurso](/docs/pt/env-vars#features-that-need-feature-flag-fetching), e `default` caso contrário | Em sua [primeira sessão após uma instalação ou upgrade](/docs/pt/env-vars#first-session-after-an-install-or-upgrade), Claude Code pode escolher o modo de permissão inicial antes de seus sinalizadores de recurso chegarem. Essa sessão pode iniciar em um modo de permissão diferente do que a tabela fornece. 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](#eliminate-prompts-with-auto-mode), 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 e Team, e em sessões que [não buscam sinalizadores de recurso](/docs/pt/env-vars#features-that-need-feature-flag-fetching), Claude Code pergunta uma vez, no terminal ou na extensão VS Code, se você quer alterar a configuração para modo auto. Se você recusar, sua configuração permanece como está.

Inicie em um modo de permissão diferente

Você pode definir o modo de permissão inicial para uma sessão, ou como padrão para cada sessão em uma máquina, projeto ou organização. Quando mais de um arquivo de configurações define `permissions.defaultMode`, [precedência de configurações](/docs/pt/settings#settings-precedence) 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](#switch-permission-modes). | Para definir o modo de permissão inicial para | Faça isto | | :- | :- | | Uma sessão que você está prestes a iniciar | Passe o modo de permissão como uma flag, por exemplo `claude --permission-mode default` | | Cada sessão de terminal que você inicia nesta máquina | Defina `permissions.defaultMode` em `~/.claude/settings.json`. Para o que a extensão VS Code lê, veja [Alternar modos de permissão](#switch-permission-modes) | | Cada sessão de terminal que você inicia em um projeto | Defina `permissions.defaultMode` em `.claude/settings.json` do projeto. Sessões que você inicia em um terminal honram todos os valores exceto `auto` e `bypassPermissions`; sessões que a extensão VS Code inicia não leem configurações de projeto para o modo de permissão inicial | | Cada sessão de terminal em sua organização | Defina `permissions.defaultMode` em [configurações gerenciadas](/docs/pt/managed-settings). Sessões de terminal iniciam nesse modo e as pessoas ainda podem alternar para modo auto; para o que a extensão VS Code lê, veja [Alternar modos de permissão](#switch-permission-modes). Para remover o modo auto para que ninguém possa selecioná-lo, defina `permissions.disableAutoMode` como `"disable"` em vez disso | Este exemplo faz cada sessão de terminal em sua máquina iniciar no modo Manual, cujo valor de configuração é `default`. Salve em `~/.claude/settings.json`: ```json theme={null} { "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](/docs/pt/hipaa-setup) 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](/docs/pt/hipaa-setup#check-how-developers-sign-in-and-connect) 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](#switch-permission-modes) * **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](#start-in-a-different-mode) * **Remover o modo auto**: defina [`permissions.disableAutoMode`](/docs/pt/settings-reference#disableautomode) como `"disable"` em configurações gerenciadas * **Bloquear `bypassPermissions`**: defina [`permissions.disableBypassPermissionsMode`](/docs/pt/settings-reference#permissions-disablebypasspermissionsmode) como `"disable"` em configurações gerenciadas Requer Claude Code v2.1.285 ou posterior, a [versão mínima para a configuração HIPAA](/docs/pt/hipaa-setup#update-claude-code-and-claude-desktop).

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. **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`. **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](/docs/pt/managed-settings) ou `~/.claude/settings.json` 4. O [padrão integrado](#which-mode-a-session-starts-in) 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 e Team em sessões que [buscam sinalizadores de recurso](/docs/pt/env-vars#features-that-need-feature-flag-fetching). Auto aparece no indicador de modo quando [modo automático está disponível](#eliminate-prompts-with-auto-mode). 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](/docs/pt/vs-code) para detalhes específicos da extensão. 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. **Durante uma sessão**: na aba Code, use o seletor de modo ao lado do botão enviar. Nem todo modo aparece no seletor: * **Auto**: aparece quando [modo automático está disponível](#eliminate-prompts-with-auto-mode) * **Bypass permissions**: requer o toggle **Allow bypass permissions mode** nas configurações do Desktop em planos Pro e Max; em planos Team e Enterprise, a política da organização controla isso A aba Cowork não usa estes modos. Cowork tem seus próprios modos de permissão, habilitados separadamente, e a aba Cowork 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](https://claude.com/docs/cowork/overview). Para detalhes específicos do desktop, veja [Escolha um modo de permissão](/docs/pt/desktop#choose-a-permission-mode) no guia do Desktop. **Como padrão**: defina `defaultMode` em [configurações](/docs/pt/settings#where-settings-live). 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 é lembrado por pasta e tem precedência sobre `defaultMode` para essa pasta. Plan é a exceção: escolhê-lo se aplica apenas à sessão atual. Para onde `defaultMode` vai em um arquivo de configurações, veja o exemplo em [Inicie em um modo de permissão diferente](#start-in-a-different-mode). Em [claude.ai/code](https://claude.ai/code), use o dropdown de modo ao lado 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](/docs/pt/claude-code-on-the-web)**: 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 apenas quando sua organização o permite e o modelo selecionado o suporta. Bypass permissions não está disponível. * **[Sessões de Remote Control](/docs/pt/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](#eliminate-prompts-with-auto-mode) do modo auto. Para um thread de projeto executado em seu computador, veja [Execute um thread em seu próprio computador](/docs/pt/claude-projects#run-a-thread-on-your-own-computer). * 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](/docs/pt/desktop) ou pela [extensão VS Code](/docs/pt/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. * Antes de v2.1.202, sessões conectadas com `/remote-control` ou `claude --remote-control` não relatavam seu modo de permissão, então claude.ai e o aplicativo móvel poderiam mostrar um modo em que a sessão não estava. A incompatibilidade afetava apenas o rótulo. Claude Code gerou prompts de permissão a partir do modo de permissão real da sessão, e eles ainda apareciam no aplicativo para aprovação. 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: ```bash theme={null} claude remote-control --permission-mode acceptEdits ```

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

O modo `acceptEdits` permite que Claude crie e edite arquivos em seu diretório de trabalho sem solicitar. A barra de status mostra `⏵⏵ accept edits on` enquanto este modo está ativo. Além de edições de arquivo, o modo `acceptEdits` auto-aprova comandos Bash comuns do sistema de arquivos: `mkdir`, `touch`, `rm`, `rmdir`, `mv`, `cp` e `sed`. Esses comandos também são auto-aprovados quando prefixados com variáveis de ambiente seguras como `LANG=C` ou `NO_COLOR=1`, ou wrappers de processo como `timeout`, `nice` ou `nohup`. Como edições de arquivo, a auto-aprovação se aplica apenas a caminhos dentro de seu diretório de trabalho ou `additionalDirectories`. Cada caminho também passa pela [verificação de symlink](/docs/pt/permissions#symlinks), portanto uma gravação que se resolve fora desse escopo também não é auto-aprovada. Caminhos fora desse escopo, gravações em [caminhos protegidos](#protected-paths), remoções `rm` e `rmdir` direcionadas a um [caminho crítico](#critical-paths) e todos os outros comandos Bash, exceto o [conjunto integrado somente leitura](/docs/pt/permissions#read-only-commands), ainda solicitam. Quando a [ferramenta PowerShell](/docs/pt/tools-reference#powershell-tool) 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](#remove-item-in-powershell). 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: ```bash theme={null} claude --permission-mode acceptEdits ```

Analise antes de editar com modo plan

O modo plan diz a Claude para pesquisar e propor mudanças sem realizá-las. Claude lê arquivos, executa comandos shell para explorar e escreve um plano, mas não edita sua fonte. Exceto em sessões interativas de terminal com [permissões de bypass disponíveis](#skip-all-checks-with-bypasspermissions-mode), edições permanecem bloqueadas até que você aprove o plano. O que acontece com um comando shell durante o planejamento depende da sessão, e o primeiro destes casos que se aplica é: * **Sessões interativas de terminal com permissões de bypass disponíveis**: nem o classificador nem um prompt se aplica a comandos de planejamento. [Ignorar todas as verificações com modo bypassPermissions](#skip-all-checks-with-bypasspermissions-mode) cobre as poucas coisas que ainda solicitam lá. * **[Modo automático](/docs/pt/auto-mode-config) disponível e a configuração `useAutoModeDuringPlan` ativada**, que é o padrão: o classificador revisa comandos shell diferentes de [remoções de caminho crítico](#critical-paths) em vez de solicitar você. Comandos aprovados são executados, e os rejeitados são bloqueados. * **Modo automático não disponível, ou `useAutoModeDuringPlan` desativado**: comandos fora do [conjunto integrado somente leitura](/docs/pt/permissions#read-only-commands) solicitam aprovação, incluindo quando o [modo auto-allow](/docs/pt/sandboxing#sandbox-modes) do sandbox está habilitado. 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: ```bash theme={null} claude --permission-mode plan ``` Pressione `Shift+Tab` novamente para sair do modo plan sem aprovar um plano.

Revise e aprove um plano

Quando o plano estiver pronto, Claude o apresenta e pergunta como proceder. A partir desse prompt você pode escolher: * **Sim, e usar modo automático**: aprove e inicie em [modo automático](#eliminate-prompts-with-auto-mode). Se o modo automático não está [disponível para sua sessão](#eliminate-prompts-with-auto-mode), por exemplo porque sua organização o desativou, esta opção lê **Sim, auto-aceitar edições**. Se você iniciou a sessão com permissões de bypass habilitadas, a opção lê **Sim, e alternar para BYPASS PERMISSIONS (sem prompts adicionais) para esta sessão** em vez disso. * **Sim, aprovar edições manualmente**: aprove e revise cada edição individualmente. * **Não, continuar planejando**: permaneça no modo plan e diga a Claude o que alterar. Aprovar um plano sai do modo plan e alterna a sessão para o modo de permissão que cada opção de aprovação descreve, então Claude começa a editar. Para planejar novamente, volte ao modo plan com `Shift+Tab`, ou prefixe seu próximo prompt com `/plan`. Pressione `Ctrl+G` para abrir o plano proposto em seu editor de texto padrão e editá-lo diretamente antes de Claude prosseguir. Quando [`showClearContextOnPlanAccept`](/docs/pt/settings-reference#showclearcontextonplanaccept) está habilitado, a lista ganha uma primeira opção que aprova o plano e limpa o contexto de planejamento. Aceitar um plano também dá à sessão um [título gerado](/docs/pt/sessions#name-your-sessions) baseado no plano, a menos que você já tenha nomeado a sessão.

Defina modo plan como padrão

Para tornar o modo plan o padrão para sessões de terminal de um projeto, defina `defaultMode` como `plan` em `.claude/settings.json`, colocado conforme o exemplo em [Inicie em um modo de permissão diferente](#start-in-a-different-mode) mostra. Conversas que a [extensão VS Code](/docs/pt/vs-code) inicia não leem configurações de projeto para o modo de permissão inicial. Lá, defina `claudeCode.initialPermissionMode` como `plan` em suas configurações de usuário do VS Code em vez disso.

Elimine prompts de permissão com 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](/docs/pt/permissions#manage-permissions) 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](#which-mode-a-session-starts-in) 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 e Team. O classificador também revisa cada mensagem que Claude envia para outro agente com [`SendMessage`](/docs/pt/tools-reference), seja texto simples ou uma mensagem estruturada de [equipe de agentes](/docs/pt/agent-teams), antes que Claude Code a entregue, tanto no modo auto quanto no [modo de planejamento enquanto o classificador revisa comandos](#analyze-before-you-edit-with-plan-mode); a revisão de envio requer Claude Code v2.1.222 ou posterior. Por padrão, o classificador não revisa remoções de `rm` e `rmdir` direcionadas a um caminho crítico, como `rm -rf /` ou `rm -rf ~`. [Caminhos críticos](#critical-paths) 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](/docs/pt/output-styles) em vez disso. 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](/docs/pt/managed-settings). * **Modelo**: na API Anthropic e [Claude Platform on AWS](/docs/pt/claude-platform-on-aws), Claude Opus 4.6 ou posterior, Sonnet 4.6 ou posterior, Haiku 5.5 ou um [modelo Fable](/docs/pt/model-config#work-with-fable). No Amazon Bedrock, na Agent Platform do Google Cloud, no Microsoft Foundry e em sessões [gateway de aplicativos Claude](/docs/pt/claude-apps-gateway) 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`](/docs/pt/settings-reference#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](/docs/pt/errors#auto-mode-cannot-determine-the-safety-of-an-action) para as causas e o que fazer. Se você definir `defaultMode: "auto"` em [configurações](/docs/pt/settings-reference#all-settings) 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](#switch-permission-modes) em vez disso.

Modo auto em Bedrock, Agent Platform ou Foundry

Em [Amazon Bedrock](/docs/pt/amazon-bedrock), [Agent Platform do Google Cloud](/docs/pt/google-vertex-ai), [Microsoft Foundry](/docs/pt/microsoft-foundry) e sessões [gateway de aplicativos Claude](/docs/pt/claude-apps-gateway) conectadas, o modo auto está disponível por padrão. Quando nada mais define um modo de permissão, também é o [modo de permissão inicial integrado](#which-mode-a-session-starts-in), nas versões que a tabela dessa seção lista. Para escolher o modo de permissão inicial você mesmo, defina `permissions.defaultMode` como [Iniciar em um modo de permissão diferente](#start-in-a-different-mode) descreve, ou escolha um modo de permissão no indicador de modo da extensão VS 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](/docs/pt/managed-settings). 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](/docs/pt/managed-settings#which-managed-source-claude-code-uses) 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. Da v2.1.158 até a v2.1.206, o modo auto estava desativado nesses provedores até você definir `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 da v2.1.207.

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](#how-the-classifier-evaluates-actions) 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](/docs/pt/vs-code) e [aplicativo desktop](/docs/pt/desktop), qualquer que seja seu plano ou tipo de conta, conforme a Anthropic disponibiliza o recurso. Em sessões de terminal interativo, isso requer Claude Code v2.1.271 ou posterior nos planos Pro, Max e Team, e v2.1.278 ou posterior nos planos Enterprise e contas da API Claude. Em sessões `-p`, Agent SDK, extensão VS Code e aplicativo desktop, isso requer Claude Code v2.1.281 ou posterior. A partir da v2.1.282, uma sessão que [não busca feature flags](/docs/pt/env-vars#features-that-need-feature-flag-fetching), 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](/docs/pt/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](/docs/pt/llm-gateway), qualquer que seja seu plano. Pedir por padrão requer Claude Code v2.1.278 ou posterior. * **Uma sessão [gateway de aplicativos Claude](/docs/pt/claude-apps-gateway) conectada**: requer Claude Code v2.1.280 ou posterior 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](/docs/pt/auto-mode-classifier-billing) 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](/docs/pt/errors#the-server-returned-no-safety-verdict) cobre a mensagem de negação, o que acontece quando negações se repetem e 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`](/docs/pt/env-vars). 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](/docs/pt/llm-gateway-protocol#disable-pre-release-capabilities) descreve.

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](/docs/pt/auto-mode-config). **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. Antes da v2.1.211, essa verificação era restrita ao branch padrão: um push para ele era bloqueado quando carregava conteúdo sensível, alterações ocultadas ou mal descritas em relação ao que você pediu, conteúdo trazido de fora do repositório, ou quando contornava uma revisão que você pediu * `git reset --hard`, `git checkout -- .`, `git restore .`, `git clean -fd`, `git stash drop` ou `git stash clear`, que o classificador presume 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](/docs/pt/auto-mode-config#define-trusted-infrastructure), 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](/docs/pt/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. Essa verificação requer Claude Code v2.1.203 ou posterior * 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; ambos os refinamentos requerem Claude Code v2.1.203 ou posterior. Antes da 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 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 Várias dessas categorias dependem de entradas de [ambiente](/docs/pt/auto-mode-config#define-trusted-infrastructure), como alvos remotos sensíveis e escopos IaC protegidos, que você pode restringir a nomes concretos. 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 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 Claude Code v2.1.205 e posterior também bloqueiam estes por padrão: * 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](#critical-paths). Alvos de `Remove-Item` que são um `*` simples ou terminam em `/*` ou `\*` nunca chegam ao classificador: Claude Code [os nega imediatamente](#remove-item-in-powershell). 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](/docs/pt/auto-mode-config#define-trusted-infrastructure) 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 do push ainda é verificado segundo as outras regras, [regras `permissions.deny`](/docs/pt/permissions#manage-permissions) ainda podem bloquear comandos de push [como escritos](/docs/pt/permissions#bash-rule-limits) em todos os modos, e a proteção de branch do próprio remoto ainda se aplica. Antes da v2.1.211, apenas pushes para o branch em que você iniciou, branches que Claude criou e pushes rotineiros para o branch padrão eram permitidos por padrão, e antes da v2.1.203 qualquer push direto para o branch padrão era bloqueado * 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`](/docs/pt/auto-mode-config#define-trusted-infrastructure). Isso cobre apenas fluxo de dados, não operações destrutivas ou de credenciais na mesma infraestrutura * Navegação do [Claude in Chrome](/docs/pt/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](/docs/pt/sandboxing#per-command-allowed-domains-in-auto-mode) 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](/docs/pt/auto-mode-config). 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](#what-the-classifier-blocks-by-default), 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](/docs/pt/permissions#bash-rule-limits): consulte [Limites comuns](/docs/pt/auto-mode-config#common-boundaries).

A primeira leitura fora dos diretórios de trabalho

Enquanto [`permissions.blockReadsOutsideWorkingDirectories`](/docs/pt/settings-reference#permissions-blockreadsoutsideworkingdirectories) estiver desativado, leituras de arquivo que não sejam [leituras de caminhos de rede](/docs/pt/permissions#network-paths) executam sem um prompt no modo auto, incluindo leituras fora dos [diretórios de trabalho](/docs/pt/permissions#working-directories). 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`](/docs/pt/settings-reference#permissions-blockreadsoutsideworkingdirectories) como `true` em suas configurações de usuário, o que faz as ferramentas de arquivo recusarem tais leituras em cada sessão posterior e em cada modo de permissão. Para deixar Claude ler tal caminho depois, adicione seu diretório com `/add-dir` ou remova a configuração. * **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](/docs/pt/costs#reduce-token-usage) remover a mensagem que o declarou. Para uma garantia rígida, adicione uma [regra de negação](/docs/pt/permissions#permission-rule-syntax) 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`](/docs/pt/auto-mode-config#override-the-block-and-allow-rules). * **Alguns bloqueios permanecem em vigor**: [a ordem de precedência do classificador](/docs/pt/auto-mode-config#override-the-block-and-allow-rules) estabelece quais bloqueios sua aprovação pode alcançar. Para executar uma etapa que ela não libera, [saia do modo auto](#switch-permission-modes) 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 denied**, onde você pode pressionar `r` para tentar novamente com uma aprovação manual. * **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](#repeated-block-thresholds) 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 nega a ação sem a notificação ou a entrada em **Recently denied**. Consulte [Auto mode cannot determine the safety of an action](/docs/pt/errors#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](#server-side-classifier-review), Claude Code nega uma ação para a qual o servidor não dá veredito, e interrompe o turno após dez respostas seguidas sem veredito. Consulte [O servidor não retornou veredito de segurança](/docs/pt/errors#the-server-returned-no-safety-verdict). * **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`](#allow-only-pre-approved-tools-with-dontask-mode).

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](/docs/pt/headless) sem um [`--permission-prompt-tool`](/docs/pt/cli-reference#cli-flags) 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](/docs/pt/auto-mode-config).

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. 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](/docs/pt/permissions#manage-permissions) são resolvidas imediatamente, com estas exceções: * Escritas em [caminhos protegidos](#protected-paths) 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](#protected-paths) descreve * Nenhuma regra de permitir aprova remoções de `rm` e `rmdir` direcionadas a um [caminho crítico](#critical-paths) * Ferramentas MCP marcadas com [`requiresUserInteraction`](/docs/pt/mcp#require-approval-for-a-specific-tool) pedem sua confirmação diretamente mesmo quando uma regra de permitir corresponde, assim como ferramentas de conector que [sua organização definiu como `ask`](/docs/pt/mcp#organization-controls-on-connector-tools) em sessões onde essa configuração chega a Claude Code * Um comando de shell que carrega [domínios permitidos por comando](/docs/pt/sandboxing#per-command-allowed-domains-in-auto-mode) também é roteado para o classificador mesmo quando uma regra de 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](/docs/pt/permissions#symlinks) 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](/docs/pt/permissions#network-paths) 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](#protected-paths) e [a primeira leitura fora dos diretórios de trabalho](#first-read-outside-the-working-directories), que pede sua confirmação * Em uma sessão com [revisão do classificador no servidor](#server-side-classifier-review), comandos de shell somente leitura e [em sandbox](/docs/pt/sandboxing#sandbox-modes) 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](/docs/pt/permissions#symlinks) resolve para um local fora dele pede sua confirmação * Quando Claude lê um [artefato que outra pessoa criou](/docs/pt/artifacts#read-an-artifact-shared-with-you), os casos de aprovação listados nessa seção se aplicam * Uma leitura de um [caminho de rede](/docs/pt/permissions#network-paths) pede sua confirmação 3. Todo o resto vai para o classificador, exceto [remoções de caminho crítico](#critical-paths) 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](/docs/pt/auto-mode-config#review-denials) Um [mod](/docs/pt/plugins/mods/overview) que você instala e que trata `tool.check` pode aprovar uma ação antes da etapa 3, e o classificador não verifica uma ação que o mod aprova. Consulte [Estender permissões com hooks](/docs/pt/permissions#extend-permissions-with-hooks). Na extensão VS Code, a forma como as ações de navegador do [Claude in Chrome](/docs/pt/chrome) são aprovadas depende de como a sessão se conectou ao navegador: consulte [Prompts de permissão em sessões VS Code](/docs/pt/chrome#permission-prompts-in-vs-code-sessions). 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`](/docs/pt/tools-reference#monitor-tool), 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](/docs/pt/hooks#annotate-a-result-for-the-auto-mode-classifier), 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](https://claude.com/blog/auto-mode) e o [aprofundamento de engenharia](https://www.anthropic.com/engineering/claude-code-auto-mode). O classificador verifica o trabalho de [subagentes](/docs/pt/sub-agents) 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](#how-the-classifier-evaluates-actions) 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. O classificador executa em Claude Sonnet 5 por padrão, em vez de na sua seleção de `/model`. Um modelo classificador que a Anthropic configura no servidor tem precedência sobre esse padrão. Quando o modelo de sua sessão é Claude Sonnet 4.6, ou quando [`availableModels`](/docs/pt/model-config#restrict-model-selection) exclui Sonnet 5, o classificador executa no modelo da sessão em vez disso, ou em um modelo Opus quando a sessão executa em um [modelo Fable](/docs/pt/model-config#work-with-fable). Em provedores diferentes da API Anthropic, esse fallback Opus é o modelo que você define em [`ANTHROPIC_DEFAULT_OPUS_MODEL`](/docs/pt/model-config#environment-variables), ou Opus 5 se você não tiver definido um. A primeira requisição de modo auto da sessão valida o padrão Sonnet 5: se a requisição for bem-sucedida, Sonnet 5 permanece como o modelo classificador da sessão, e se falhar porque o modelo não está disponível, a sessão usa o fallback em vez disso. Em planos Enterprise e em contas que usam a API Claude, [Claude Platform on AWS](/docs/pt/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](#server-side-classifier-review). Acesso à rede em sandbox não adiciona requisições do classificador por conexão. O classificador julga [os hosts que um comando nomeia](/docs/pt/sandboxing#per-command-allowed-domains-in-auto-mode) 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ê. 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](/docs/pt/permissions#read-only-commands), além de ações que correspondem às suas regras `permissions.allow` e chamadas aprovadas por um [hook PreToolUse](/docs/pt/permissions#extend-permissions-with-hooks). 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` enquanto este modo está ativo. Claude Code nega chamadas que correspondem às suas [regras `ask`](/docs/pt/permissions#manage-permissions) 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`](/docs/pt/mcp#organization-controls-on-connector-tools) em sessões onde essa configuração chega a Claude Code. Nega ferramentas MCP marcadas [`_meta["anthropic/requiresUserInteraction"]`](/docs/pt/mcp#require-approval-for-a-specific-tool) da mesma forma, porque seu cartão de aprovação precisa de uma resposta que este modo nunca coleta. Remoções `rm` e `rmdir` direcionadas a um [caminho crítico](#critical-paths), como `rm -rf /` e `rm -rf ~`, são negadas mesmo quando uma regra de permissão corresponde a elas ou um hook `PreToolUse` as permite. Uma leitura de um [caminho de rede](/docs/pt/permissions#network-paths) é negada da mesma forma. Sessões em nuvem em [Claude Code na web](/docs/pt/claude-code-on-the-web) ignoram `defaultMode: "dontAsk"`; veja [bypassPermissions](#skip-all-checks-with-bypasspermissions-mode) para detalhes. Defina-o na inicialização com a flag: ```bash theme={null} 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](#protected-paths). As [ações que nenhum modo auto-aprova](#actions-no-mode-auto-approves) ainda solicitam neste modo. Ler [o artefato público de outra organização](/docs/pt/artifacts#read-an-artifact-shared-with-you) requer sua aprovação, e este modo não a solicita, então Claude não consegue ler um. As [Remove-Item no PowerShell](#remove-item-in-powershell) negações também se aplicam neste modo. Duas [salvaguardas de mensagens entre sessões](/docs/pt/cross-session-messaging) 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`](/docs/pt/settings-reference#isolatepeermachines) para mensagens para suas sessões além desta máquina ainda aparece. * Quando nenhum valor [`crossSessionInbound`](/docs/pt/cross-session-messaging#control-inbound-messages) 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 plan](#analyze-before-you-edit-with-plan-mode). 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](/docs/pt/permissions#manage-permissions) explícitas e remoções `rm` e `rmdir` direcionadas a um [caminho crítico](#critical-paths) 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](/docs/pt/headless) com `-p`, sessões do [Agent SDK](/docs/pt/agent-sdk/permissions#plan-mode-plan), e conversas no painel de chat da [extensão VS Code](/docs/pt/vs-code). Lá, `--allow-dangerously-skip-permissions` torna `bypassPermissions` selecionável depois. 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"`](/docs/pt/settings-reference#permissions-defaultmode) ou com uma flag de habilitação: ```bash theme={null} claude --permission-mode bypassPermissions ``` A flag `--dangerously-skip-permissions` é equivalente. Claude Code recusa `bypassPermissions` em uma sessão que você inicia com [`--restricted`](/docs/pt/cli-reference#cli-flags). `--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`](/docs/pt/settings-reference#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](/docs/pt/headless) nenhum diálogo é mostrado. Uma [sessão em segundo plano](/docs/pt/agent-view) 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 até que você aceite o diálogo em uma sessão interativa. * Com `skipDangerousModePermissionPrompt` definido apenas em `.claude/settings.local.json`, a sessão em segundo plano inicia com a requisição de bypass ignorada e fixa o aviso `Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true`. Para que o bypass seja respeitado, adicione essa chave a `~/.claude/settings.json` e, em seguida, inicie uma nova sessão em segundo plano. Em Linux e macOS, Claude Code recusa iniciar neste modo quando executado como root ou sob `sudo`: ```text theme={null} --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](/docs/pt/devcontainer), que executa Claude Code como um usuário não-root. [Sessões em nuvem](/docs/pt/claude-code-on-the-web) 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](#switch-permission-modes) para quais modos as sessões em nuvem oferecem. `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](#eliminate-prompts-with-auto-mode) em vez disso. Administradores podem bloquear este modo definindo `permissions.disableBypassPermissionsMode` como `"disable"` em [configurações gerenciadas](/docs/pt/managed-settings).

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](#skip-all-checks-with-bypasspermissions-mode) disponíveis. Isso evita corrupção acidental do estado do repositório e da configuração própria do Claude. | Modo | Gravações em caminhos protegidos | | :- | :- | | `default`, `acceptEdits` | Solicitado | | `plan` | Permitido em sessões de terminal interativo com [permissões de bypass](#skip-all-checks-with-bypasspermissions-mode) disponíveis. Caso contrário, roteado para o classificador quando [modo automático](#eliminate-prompts-with-auto-mode) está disponível durante o planejamento, e solicitado quando não está | | `auto` | Roteado para o classificador | | `dontAsk` | Negado | | `bypassPermissions` | Permitido | Em uma sessão iniciada com [`--restricted`](/docs/pt/cli-reference#cli-flags), que requer Claude Code v2.1.248 ou posterior, o classificador não consegue aprovar gravações em caminhos protegidos. Nos modos que roteiam gravações em caminhos protegidos para o classificador, uma gravação que a [verificação de symlink](/docs/pt/permissions#symlinks) resolve para um caminho protegido solicita você em vez disso quando o caminho que Claude solicitou não é em si protegido. Regras [`permissions.allow`](/docs/pt/permissions#manage-permissions) 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`](/docs/pt/settings-reference#plansdirectory) que você definir * O próprio diretório de rascunho de uma [sessão em segundo plano](/docs/pt/agent-view#where-state-is-stored) em `~/.claude/jobs//tmp/` * Arquivos markdown no diretório de [memória automática](/docs/pt/memory#storage-location) do projeto, como `~/.claude/projects//memory/`, em uma sessão iniciada sem `--restricted` * Arquivos markdown em um diretório de [memória de subagente](/docs/pt/sub-agents#enable-persistent-memory), como `.claude/agent-memory/`, em uma sessão iniciada sem `--restricted` * Um diretório que você carregou com [`--plugin-dir`](/docs/pt/plugins/mods/create#change-a-mod-with-claude), porque Claude Code recarrega e executa o código de um mod a partir dele quando um arquivo muda 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` * O arquivo para o qual seu [arquivo de configurações](/docs/pt/settings#settings-files-and-who-they-affect) 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 nunca deixa uma regra [`permissions.allow`](/docs/pt/permissions#manage-permissions) ou um hook [`PreToolUse`](/docs/pt/permissions#extend-permissions-with-hooks) que retorna `"allow"` aprovar um comando `rm` ou `rmdir` que tenha como alvo um caminho crítico, mesmo em modos que pulam outros prompts. Este disjuntor protege contra erro do modelo. Uma regra de negação correspondente ainda bloqueia o comando completamente. O que acontece em vez disso [depende do seu modo de permissão](#critical-path-removals-in-each-permission-mode). `Remove-Item` e os built-ins de remoção `cmd` têm suas próprias verificações, cobertas em [Remove-Item em PowerShell](#remove-item-in-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 /*`. `rm -rf ` no próprio diretório não dispara essa verificação 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. | Alvo | Exemplo | Por que conta | | :- | :- | :- | | Um glob ou barra à direita diretamente sob uma variável de shell | `rm -rf "$DIR"/*` | O comando se torna uma remoção da raiz do sistema de arquivos quando a variável está vazia | | A mesma forma sob um parâmetro posicional como `$1` ou `$@`, quando nada no comando lhe dá um valor | `rm -rf "$1"/*` | O comando se expande para uma remoção da raiz | | Uma variável de shell seguida por um nome de diretório de nível superior comum, como `mnt`, `tmp`, `usr` ou `Users` | `rm -rf "$TMPDIR/mnt"` | Quando a variável se expande vazia, o comando remove `/mnt` | | Uma variável que o mesmo comando atribui de uma substituição de impressão de diretório, como `$(pwd)` ou `$(git rev-parse --show-toplevel)` | `D=$(pwd); rm -rf "$D"` | O valor pode nomear seu diretório de trabalho ou raiz do repositório | | Um alvo que é apenas a saída de uma substituição de comando, quando o `rm` é recursivo | `rm -rf "$(pwd)"` | Claude Code não pode verificar o alvo antes do comando ser executado | | Uma substituição de comando à direita após um caminho crítico | `rm -rf ~/$(cmd)` | Claude Code verifica o caminho que permaneceria se a substituição se expandisse vazia, aqui seu diretório home | | Um alvo que é apenas barras invertidas | `rm -rf "\\"` | Git Bash no Windows lê uma barra invertida solitária como a raiz da unidade atual, então a verificação se aplica em todas as plataformas | | Um caminho do Windows que nomeia um volume por GUID em vez de uma letra de unidade | `rm -rf '\\?\Volume{GUID}\work\build'` | O caminho não diz em qual unidade está, então pode ser um caminho crítico. Requer Claude Code v2.1.292 ou posterior | | Alguns alvos que terminam em `/*` ou `/*/` | `rm -rf logs/*/*`, `rm -rf logs/*/`, `cd logs && rm -rf a/*` | Claude Code não consegue determinar, antes do comando ser executado, quais diretórios eles alcançam | 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`](/docs/pt/env-vars#variables) 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`](/docs/pt/env-vars#variables) 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](#other-targets-that-count-as-critical-paths) 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](#critical-paths) 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.

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: | Modo | Resultado | | :- | :- | | `default`, `acceptEdits` | Pede que você o aprove | | `plan` | Pede que você o aprove. Quando [o classificador revisa comandos durante o planejamento](#analyze-before-you-edit-with-plan-mode) e nenhuma permissão de bypass está disponível, trata como em modo `auto` | | `auto` | Pede que você o aprove no terminal, com um [limite de tempo](#time-limits-and-denials-in-auto-and-bypasspermissions-modes). Em outro lugar, nega-o | | `dontAsk` | Nega-o | | `bypassPermissions` | Pede que você o aprove, com um limite de tempo no terminal | Se uma [regra de solicitação](/docs/pt/permissions#manage-permissions) 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`](/docs/pt/hooks#permissionrequest) pode responder ao prompt.

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. Em modo `auto`, onde quer que Claude Code não possa mostrar um prompt de terminal, nega o comando imediatamente, por exemplo em [execuções não interativas](/docs/pt/headless) com `-p`, em sessões do [Agent SDK](/docs/pt/agent-sdk/permissions) e no painel de chat da extensão VS Code e no aplicativo Desktop. A negação diz a Claude para relatar o que queria deletar e deixar a remoção para você. O tratamento de `auto` e `bypassPermissions` requer Claude Code v2.1.281 ou posterior. Para desativá-lo, defina [`CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1`](/docs/pt/env-vars#variables) no ambiente que inicia Claude Code. Em modo `auto`, as remoções de caminho crítico vão para o classificador em vez disso, e em modo `bypassPermissions` o prompt não tem limite de tempo.

Remove-Item em PowerShell

Quando você habilita a [ferramenta PowerShell](/docs/pt/tools-reference#powershell-tool), 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](#eliminate-prompts-with-auto-mode) 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`](/docs/pt/env-vars#variables) 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](/docs/pt/permissions): regras de permissão, solicitação e negação; políticas gerenciadas * [Configurar modo automático](/docs/pt/auto-mode-config): diga ao classificador qual infraestrutura sua organização confia * [Hooks](/docs/pt/hooks): lógica de permissão personalizada via hooks `PreToolUse` e `PermissionRequest` * [Segurança](/docs/pt/security): salvaguardas e melhores práticas * [Sandboxing](/docs/pt/sandboxing): isolamento de sistema de arquivos e rede para comandos Bash * [Modo não-interativo](/docs/pt/headless): execute Claude Code com a flag `-p`