SpyBara
Go Premium

permission-modes.md 2026-07-09 23:58 UTC to 2026-07-10 17:00 UTC

45 added, 18 removed.

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

Escolha um modo de permissão

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

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

Modos disponíveis

Cada modo faz um tradeoff diferente entre conveniência e supervisão. A tabela abaixo mostra o que Claude pode fazer sem um prompt de permissão em cada modo.

Modo O que é executado sem pedir Melhor para
default Apenas leituras. Rotulado como Manual na CLI e nas extensões IDE Começando, trabalho sensível
acceptEdits Leituras, edições de arquivo e comandos comuns do filesystem (mkdir, touch, mv, cp, etc.) Iterando em código que você está revisando
plan Apenas leituras Explorando uma base de código antes de alterá-la
auto Tudo, com verificações de segurança de fundo Tarefas longas, reduzindo fadiga de prompt
dontAsk Apenas ferramentas pré-aprovadas CI bloqueado e scripts
bypassPermissions Tudo Apenas contêineres e VMs isolados

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

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

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

Alternar modos de permissão

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

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

Nem todo modo está no ciclo padrão:

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

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

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

claude --permission-mode plan

Como padrão: defina defaultMode em settings.

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

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

Auto-approve file edits with acceptEdits mode

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 filesystem: mkdir, touch, rm, rmdir, mv, cp e sed. Esses comandos também são auto-aprovados quando prefixados com variáveis de ambiente seguras como LANG=C ou NO_COLOR=1, ou wrappers de processo como timeout, nice ou nohup. Como edições de arquivo, a auto-aprovação se aplica apenas a caminhos dentro de seu diretório de trabalho ou additionalDirectories. Caminhos fora desse escopo, escritas em caminhos protegidos e todos os outros comandos Bash ainda solicitam.

Quando a ferramenta PowerShell está ativada, o modo acceptEdits também auto-aprova Set-Content, Add-Content, Clear-Content e Remove-Item em caminhos dentro do escopo, junto com seus aliases comuns. As mesmas regras de escopo e caminho protegido se aplicam.

Use acceptEdits quando você quer revisar alterações em seu editor ou via git diff depois do fato em vez de aprovar cada edição inline.

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

claude --permission-mode acceptEdits

Analise antes de editar com plan mode

Plan mode diz a Claude para pesquisar e propor alterações sem fazê-las. Claude lê arquivos, executa comandos shell para explorar e escreve um plano, mas não edita seu código-fonte. Prompts de permissão ainda se aplicam da mesma forma que o modo Manual.

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

claude --permission-mode plan

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

Revise e aprove um plano

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

  • Aprovar e iniciar em auto mode
  • Aprovar e aceitar edições
  • Aprovar e revisar cada edição manualmente
  • Continuar planejando com feedback
  • Refinar com Ultraplan para revisão baseada em navegador

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

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

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

Defina plan mode como o padrão

Para fazer do plan mode o padrão para um projeto, defina defaultMode em .claude/settings.json:

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

Elimine prompts de permissão com auto mode

Auto mode permite que Claude execute sem prompts de permissão rotineiros. Um modelo classificador separado revisa ações antes de serem executadas, bloqueando qualquer coisa que escale além de sua solicitação, direcione infraestrutura não reconhecida ou pareça impulsionada por conteúdo hostil que Claude leu. Regras ask explícitas ainda forçam um prompt.

Auto mode também instrui 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 obter um comportamento autônomo mais forte mantendo prompts de permissão, defina o estilo de saída Proactive output style em vez disso.

Auto mode está disponível apenas quando sua conta atende a todos esses requisitos:

  • Plan: Todos os planos.
  • Owner: em Team e Enterprise, um Owner deve habilitá-lo em configurações de admin do Claude Code antes que os usuários possam ativá-lo. Administradores também podem bloqueá-lo definindo permissions.disableAutoMode para "disable" em configurações gerenciadas.
  • Model: na API Anthropic, Claude Opus 4.6 ou posterior, ou Sonnet 4.6 ou posterior. No Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessões gateway de aplicativos Claude conectadas, apenas Claude Sonnet 5, Opus 4.7 e Opus 4.8. Modelos mais antigos, incluindo Sonnet 4.5, Opus 4.5, Haiku e modelos claude-3, não são suportados em nenhum provedor.
  • Provider: disponível por padrão na API Anthropic. No Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessões gateway de aplicativos Claude conectadas, auto mode está desativado até que você defina CLAUDE_CODE_ENABLE_AUTO_MODE.

Se Claude Code relatar auto mode como indisponível, um desses requisitos não foi atendido; isso não é uma interrupção transitória. Uma mensagem separada que nomeia um modelo e diz que auto mode "não pode determinar a segurança" de uma ação é uma interrupção transitória do classificador; veja a referência de erro.

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

Habilitar auto mode no Bedrock, Agent Platform ou Foundry

No Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessões gateway de aplicativos Claude conectadas, auto mode não aparece no ciclo Shift+Tab até que CLAUDE_CODE_ENABLE_AUTO_MODE seja definido como 1. A variável funciona em Claude Code v2.1.158 e posterior. Apenas Claude Sonnet 5, Opus 4.7 e Opus 4.8 são suportados nesses provedores.

Para habilitá-lo para um desenvolvedor, adicione a variável ao bloco env em ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  }
}

Para habilitá-lo para sua organização, adicione o mesmo bloco env a configurações gerenciadas.

Depois que a variável é definida, auto mode aparece no ciclo Shift+Tab para cada sessão. Para torná-lo o modo de início padrão, também defina "permissions": {"defaultMode": "auto"} em configurações de usuário ou gerenciadas. Nesses provedores, Claude Code ignora defaultMode: "auto" a menos que CLAUDE_CODE_ENABLE_AUTO_MODE também seja definido.

Para impedir que desenvolvedores habilitem auto mode, defina disableAutoMode para "disable" em configurações gerenciadas. Isso substitui a variável de habilitação.

Se você se conectar através de um gateway LLM configurado com ANTHROPIC_BASE_URL, auto mode pode já estar acessível sem a variável de habilitação, porque o gateway roteia solicitações através da API Anthropic. Isso não se aplica a uma sessão gateway de aplicativos Claude conectada, que é sua própria classe de provedor e requer a variável de habilitação. A configuração disableAutoMode se aplica da mesma forma em qualquer configuração.

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 começou. {/* min-version: 2.1.200 */}Um remoto adicionado ou reorientado durante a sessão com git remote add ou git remote set-url não é confiável, e tudo mais é tratado como externo até que você configure infraestrutura confiável. Antes da v2.1.200, remotos adicionados no meio da sessão também eram confiáveis.

Bloqueado por padrão:

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

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

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

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

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

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

  • Comentar, deletar 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
  • Deletar ou desmontar 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
  • Reorientar uma URL de 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
  • Alterar para onde os pushes vão com git remote set-url ou git remote add, a menos que você tenha nomeado o novo remoto
  • Enviar segredos ou dados pessoais ou confiáveis para um repositório conhecido por ser público, ou enviar material confidencial para lá que não faz parte do próprio trabalho desse repositório. {/* min-version: 2.1.203 */}O próprio assunto de um repositório de dotfiles é a única exceção para dados pessoais ou confiáveis, 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 é estabelecida, o classificador não bloqueia apenas por isso; ele julga o conteúdo contra as outras regras em vez disso
  • Abrir uma solicitação de pull contra um repositório ou organização diferente, fazer fork com gh repo fork, ou fazer push para um repositório de terceiros, a menos que você tenha nomeado esse alvo externo

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

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

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

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

Permitido por padrão:

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

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

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

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

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

Execute claude auto-mode defaults para ver as listas de regras completas. Se ações rotineiras forem bloqueadas, um administrador pode adicionar repositórios confiáveis, buckets e serviços via configuração autoMode.environment: veja Configure auto mode.

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 fazer deploy", o classificador bloqueia ações correspondentes mesmo quando as regras padrão as permitiriam. Um limite permanece em vigor até que você o levante em uma mensagem posterior. O próprio julgamento de Claude de que uma condição foi atendida não o levanta.

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 compactação de contexto remover a mensagem que o declarou. Para uma garantia difícil, adicione uma regra de negação em vez disso.

Quando auto mode volta para trás

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

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

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

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

Cada ação passa por uma ordem de decisão fixa. O primeiro passo correspondente vence: 
1. Ações correspondentes às suas [regras de permitir ou negar](/anthropic/claude-code/history/docs/pt/2026-07-09-2358..2026-07-10-1700/permissions/#manage-permissions) resolvem imediatamente, exceto escritas em [caminhos protegidos](#protected-paths), que são roteadas para o classificador 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 auto-aprovadas, exceto escritas em [caminhos protegidos](#protected-paths)
3. Tudo mais vai para o classificador. {/* min-version: 2.1.199 */}A partir da v2.1.199, uma ferramenta MCP marcada com [`_meta["anthropic/requiresUserInteraction"]`](/pt/mcp#require-approval-for-a-specific-tool) pula o classificador e o solicita diretamente, então uma etapa de consentimento nunca é auto-aprovada em nome do autor da ferramenta
4. Se o classificador bloqueia, Claude recebe o motivo e tenta uma alternativa

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

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

Regras estreitas como `Bash(npm test)` são mantidas. As regras descartadas são restauradas quando você sai do auto mode.

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

O classificador verifica trabalho de subagente 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 tempo de geração.
  2. Enquanto o subagente é executado, cada uma de suas ações passa pelo classificador com as mesmas regras que a sessão pai, e qualquer permissionMode no frontmatter do subagente é ignorado.
  3. Quando o subagente termina, o classificador revisa seu histórico de ação completo; se essa verificação de retorno sinaliza uma preocupação, um aviso de segurança é adicionado aos resultados do subagente.

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

Custo e latência

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

Allow only pre-approved tools with dontAsk mode

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

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

claude --permission-mode dontAsk

Pule todas as verificações com o modo bypassPermissions

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

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

claude --permission-mode bypassPermissions

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

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

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

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

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

Caminhos protegidos

Escritas em um pequeno conjunto de caminhos nunca são auto-aprovadas, em todos os modos exceto bypassPermissions. Isso previne corrupção acidental do estado do repositório e da configuração própria de Claude.

Modo Escritas em caminhos protegidos
default, acceptEdits, plan Solicitadas
auto Roteadas para o classificador
dontAsk Negadas
bypassPermissions Permitidas

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

Diretórios protegidos:

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

Arquivos protegidos:

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

Veja também

  • Permissions: regras de permitir, pedir e negar; políticas gerenciadas
  • Configure auto mode: diga ao classificador qual infraestrutura sua organização confia
  • Hooks: lógica de permissão personalizada via hooks PreToolUse e PermissionRequest
  • Ultraplan: execute plan mode em uma sessão Claude Code na web com revisão baseada em navegador
  • Security: salvaguardas e melhores práticas
  • Sandboxing: isolamento de filesystem e rede para comandos Bash
  • Non-interactive mode: execute Claude Code com a flag -p