Pular para o conteúdo principal
Auto mode permite que Claude Code seja executado sem prompts de permissão, roteando cada chamada de ferramenta através de um classificador que bloqueia qualquer coisa irreversível, destrutiva ou direcionada para fora do seu ambiente. Use o bloco de configurações autoMode para dizer ao classificador quais repositórios, buckets e domínios sua organização confia, para que ele pare de bloquear operações internas rotineiras. Pronto para usar, o classificador confia apenas no diretório de trabalho e nos remotes configurados do repositório atual. Ações como fazer push para a organização de controle de código-fonte da sua empresa ou escrever em um bucket de nuvem de equipe são bloqueadas até que você as adicione a autoMode.environment. Para saber como ativar o modo automático e o que ele bloqueia por padrão, consulte Permission modes. Esta página é a referência de configuração. Esta página aborda como:

​
Where the classifier reads configuration

O classificador lê o mesmo conteúdo CLAUDE.md que o próprio Claude carrega, portanto uma instrução como “nunca force push” no CLAUDE.md do seu projeto orienta tanto Claude quanto o classificador ao mesmo tempo. Comece ali para convenções de projeto e regras de comportamento. Para regras que se aplicam em todos os projetos, como infraestrutura confiável ou regras de negação em toda a organização, use o bloco de configurações autoMode. O classificador lê autoMode dos seguintes escopos:
EscopoArquivoUse para
Um desenvolvedor~/.claude/settings.jsonInfraestrutura confiável pessoal
Um projeto, um desenvolvedor.claude/settings.local.jsonBuckets ou serviços confiáveis por projeto, gitignored
Em toda a organizaçãoManaged settingsInfraestrutura confiável distribuída para todos os desenvolvedores
Flag --settings ou Agent SDKJSON inlineSubstituições por invocação para automação
O classificador não lê autoMode de configurações de projeto compartilhadas em .claude/settings.json, portanto um repositório verificado não pode injetar suas próprias regras de permissão. As entradas de cada escopo são combinadas. Um desenvolvedor pode estender environment, allow e soft_deny com entradas pessoais, mas não pode remover entradas que as configurações gerenciadas fornecem. Como as regras de permissão atuam como exceções às regras de bloqueio dentro do classificador, uma entrada allow adicionada por um desenvolvedor pode substituir uma entrada soft_deny da organização: a combinação é aditiva, não um limite de política rígida.
O classificador é um segundo portão que é executado após o sistema de permissões. Para ações que nunca devem ser executadas, independentemente da intenção do usuário ou da configuração do classificador, use permissions.deny em configurações gerenciadas, que bloqueia a ação antes do classificador ser consultado e não pode ser substituída.

​
Define trusted infrastructure

Para a maioria das organizações, autoMode.environment é o único campo que você precisa definir. Ele diz ao classificador quais repositórios, buckets e domínios são confiáveis: o classificador o usa para decidir o que significa “externo”, portanto qualquer destino não listado é um alvo potencial de exfiltração. Definir environment substitui a lista de ambiente padrão, que inclui a entrada que confia no repositório de trabalho e seus remotes. Execute claude auto-mode defaults para imprimir os padrões, depois inclua-os junto com suas próprias entradas para estender a lista em vez de estreitá-la. 
{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}
As entradas são prosa, não regex ou padrões de ferramenta. O classificador as lê como regras em linguagem natural. Escreva-as da forma como você descreveria sua infraestrutura para um novo engenheiro. Uma seção de ambiente completa cobre:
  • Organização: o nome da sua empresa e para que Claude Code é usado principalmente, como desenvolvimento de software, automação de infraestrutura ou engenharia de dados
  • Controle de código-fonte: todas as organizações GitHub, GitLab ou Bitbucket para as quais seus desenvolvedores fazem push
  • Provedores de nuvem e buckets confiáveis: nomes de buckets ou prefixos dos quais Claude deve ser capaz de ler e escrever
  • Domínios internos confiáveis: nomes de host para APIs, painéis e serviços dentro de sua rede, como *.internal.example.com
  • Serviços internos principais: CI, registros de artefatos, índices de pacotes internos, ferramentas de incidentes
  • Contexto adicional: restrições de indústria regulada, infraestrutura multi-tenant ou requisitos de conformidade que afetam o que o classificador deve tratar como arriscado
Um modelo inicial útil: preencha os campos entre colchetes e remova as linhas que não se aplicam. 
{
  "autoMode": {
    "environment": [
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}
Quanto mais contexto específico você fornecer, melhor o classificador poderá distinguir operações internas rotineiras de tentativas de exfiltração. Você não precisa preencher tudo de uma vez. Um rollout razoável: comece com os padrões e adicione sua organização de controle de código-fonte e serviços internos principais, o que resolve os falsos positivos mais comuns, como fazer push para seus próprios repositórios. Adicione domínios confiáveis e buckets de nuvem a seguir. Preencha o resto conforme os bloqueios surgirem.

​
Override the block and allow rules

Dois campos adicionais permitem que você substitua as listas de regras integradas do classificador: autoMode.soft_deny controla o que é bloqueado e autoMode.allow controla quais exceções se aplicam. Cada um é uma matriz de descrições em prosa, lidas como regras em linguagem natural. Não há campo autoMode.deny; para bloquear uma ação de forma rígida, independentemente da intenção, use permissions.deny, que é executado antes do classificador. Dentro do classificador, a precedência funciona em três camadas:
  • Regras soft_deny bloqueiam primeiro
  • Regras allow então substituem bloqueios correspondentes como exceções
  • A intenção explícita do usuário substitui ambas: se a mensagem do usuário descreve direta e especificamente a ação exata que Claude está prestes a executar, o classificador a permite mesmo quando uma regra soft_deny corresponde
Solicitações gerais não contam como intenção explícita. Pedir ao Claude para “limpar o repositório” não autoriza force-push, mas pedir ao Claude para “force-push este branch” autoriza.
Definir qualquer um de environment, allow ou soft_deny substitui a lista padrão inteira para essa seção. Se você definir soft_deny com uma única entrada, todas as regras de bloqueio integradas serão descartadas: force push, exfiltração de dados, curl | bash, implantações em produção e todas as outras regras de bloqueio padrão se tornam permitidas. Para personalizar com segurança, execute claude auto-mode defaults para imprimir as regras integradas, copie-as para seu arquivo de configurações, depois revise cada regra em relação ao seu próprio pipeline e tolerância ao risco. Remova apenas regras para riscos que sua infraestrutura já mitiga.
Para afrouxar: remova regras de soft_deny quando os padrões bloquearem algo que seu pipeline já protege com revisão de PR, CI ou ambientes de staging, ou adicione a allow quando o classificador sinalizar repetidamente um padrão rotineiro que as exceções padrão não cobrem. Para apertar: adicione a soft_deny para riscos específicos do seu ambiente que os padrões perdem, ou remova de allow para manter uma exceção padrão às regras de bloqueio. Em todos os casos, execute claude auto-mode defaults para obter as listas padrão completas, depois copie e edite: nunca comece com uma lista vazia. 
{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",
      "...copy full default soft_deny list here first, then add your rules..."
    ]
  }
}
Cada seção substitui apenas seu próprio padrão, portanto definir environment sozinho deixa as listas padrão allow e soft_deny intactas.

​
Inspect the defaults and your effective config

Como definir qualquer um dos três arrays substitui seus padrões, comece qualquer personalização copiando as listas padrão completas. Três subcomandos CLI ajudam você a inspecionar e validar. Imprima as regras environment, allow e soft_deny integradas como JSON: 
claude auto-mode defaults
Imprima o que o classificador realmente usa como JSON, com suas configurações aplicadas onde definidas e padrões caso contrário: 
claude auto-mode config
Obtenha feedback de IA sobre suas regras allow e soft_deny personalizadas: 
claude auto-mode critique
Salve a saída de claude auto-mode defaults em um arquivo, edite as listas para corresponder à sua política e cole o resultado em seu arquivo de configurações. Após salvar, execute claude auto-mode config para confirmar que as regras efetivas são o que você espera. Se você escreveu regras personalizadas, claude auto-mode critique as revisa e sinaliza entradas que são ambíguas, redundantes ou provavelmente causarão falsos positivos.

​
Review denials

Quando o modo automático nega uma chamada de ferramenta, a negação é registrada em /permissions na aba Recently denied. Pressione r em uma ação negada para marcá-la para retry: quando você sair do diálogo, Claude Code envia uma mensagem dizendo ao modelo que ele pode tentar novamente essa chamada de ferramenta e retoma a conversa. Negações repetidas para o mesmo destino geralmente significam que o classificador está perdendo contexto. Adicione esse destino a autoMode.environment, depois execute claude auto-mode config para confirmar que teve efeito. Para reagir a negações programaticamente, use o hook PermissionDenied.

​
See also

  • Permission modes: o que é modo automático, o que ele bloqueia por padrão e como ativá-lo
  • Managed settings: implante a configuração autoMode em toda a sua organização
  • Permissions: regras de permissão, pergunta e negação que se aplicam antes do classificador ser executado
  • Settings: a referência de configurações completa, incluindo a chave autoMode