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.
Auto mode está disponível para todos os usuários na API Anthropic. No Amazon Bedrock, Google Cloud Vertex AI e Microsoft Foundry, você deve primeiro definir CLAUDE_CODE_ENABLE_AUTO_MODE. Se Claude Code relatar que o auto mode não está disponível para sua conta, verifique os requisitos completos, que também cobrem os modelos suportados e a habilitação de administrador nos planos Team e Enterprise.
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:

​
Onde o classificador lê a configuração

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, soft_deny e hard_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 suave 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.

​
Definir infraestrutura confiável

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. A lista de ambiente padrão confia no repositório de trabalho e seus remotes configurados. Para adicionar suas próprias entradas junto com esse padrão, inclua a string literal "$defaults" no array. As entradas padrão são inseridas nessa posição, portanto suas entradas personalizadas podem vir antes ou depois delas. 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "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": [
      "$defaults",
      "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.

​
Substituir as regras de bloqueio e permissão

Três campos adicionais permitem que você substitua as listas de regras integradas do classificador: autoMode.hard_deny para limites de segurança incondicionais, autoMode.soft_deny para ações destrutivas que a intenção do usuário pode contornar, e autoMode.allow para exceções. Cada um é uma matriz de descrições em prosa, lidas como regras em linguagem natural. Para bloqueios baseados em padrões de ferramentas que são executados antes do classificador, use permissions.deny. Dentro do classificador, a precedência funciona em quatro camadas:
  • Regras hard_deny bloqueiam incondicionalmente. A intenção do usuário e exceções allow não se aplicam.
  • Regras soft_deny bloqueiam em seguida. A intenção do usuário e exceções allow podem substituir estas.
  • Regras allow então substituem regras soft_deny correspondentes como exceções.
  • A intenção explícita do usuário substitui os bloqueios soft restantes: 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. Para afrouxar, 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 destrutivos específicos do seu ambiente que os padrões perdem, ou a hard_deny para limites de segurança que nunca devem ser ultrapassados. Para manter as regras integradas enquanto adiciona as suas próprias, inclua a string literal "$defaults" na matriz. As regras padrão são inseridas nessa posição, portanto suas regras personalizadas podem vir antes ou depois delas, e você continua a herdar atualizações conforme a lista integrada muda entre versões. 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "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": [
      "$defaults",
      "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"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}
Definir qualquer um de environment, allow, soft_deny ou hard_deny sem "$defaults" substitui a lista padrão inteira para essa seção. Uma matriz soft_deny sem "$defaults" descarta todas as regras de bloqueio integradas, incluindo force push, curl | bash e implantações em produção. Uma matriz hard_deny sem "$defaults" descarta as regras integradas de exfiltração de dados e bypass de auto-mode.
Cada seção é avaliada independentemente, portanto definir environment sozinho deixa as listas padrão allow, soft_deny e hard_deny intactas. Omita "$defaults" apenas quando você pretender assumir a propriedade total da lista. Para fazer isso com segurança, execute claude auto-mode defaults para imprimir as regras integradas, copie-as para seu arquivo de configurações e depois revise cada regra em relação ao seu próprio pipeline e tolerância ao risco.

​
Inspecione os padrões e sua configuração efetiva

Três subcomandos CLI ajudam você a inspecionar e validar sua configuração. Imprima as regras environment, allow, soft_deny e hard_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, soft_deny e hard_deny personalizadas: 
claude auto-mode critique
Execute claude auto-mode config após salvar suas configurações para confirmar que as regras efetivas são o que você espera, com "$defaults" expandido no lugar. 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. Se você precisar remover ou reescrever uma regra integrada em vez de adicionar ao lado dela, salve a saída de claude auto-mode defaults em um arquivo, edite as listas e cole o resultado em seu arquivo de configurações no lugar de "$defaults".

​
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