Configurar modo automático
Diga ao classificador do modo automático quais repositórios, buckets e domínios sua organização confia. Defina o contexto do ambiente, substitua as regras padrão de bloqueio e permissão, e inspecione sua configuração efetiva com os subcomandos CLI do auto mode.
Auto mode permite que Claude Code seja executado sem prompts de permissão rotineiros, roteando chamadas de ferramenta através de um classificador que bloqueia qualquer coisa irreversível, destrutiva ou direcionada para fora do seu ambiente. Regras de negação e solicitação explícita são avaliadas antes do classificador e ainda bloqueiam ou solicitam. 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.
Por padrão, 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:
- Escolher onde definir regras em CLAUDE.md, configurações do usuário e configurações gerenciadas
- Definir infraestrutura confiável com
autoMode.environment - Substituir as regras de bloqueio e permissão quando os padrões não se adequam ao seu pipeline
- Rotear todos os comandos shell através do classificador com
autoMode.classifyAllShell - Inspecionar sua configuração efetiva com os subcomandos
claude auto-mode - Revisar negações para saber o que adicionar a seguir
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:
| Escopo | Arquivo | Use para |
|---|---|---|
| Um desenvolvedor | ~/.claude/settings.json |
Infraestrutura confiável pessoal |
| Um projeto, um desenvolvedor | .claude/settings.local.json |
Buckets ou serviços confiáveis por projeto |
| Em toda a organização | Managed settings | Infraestrutura confiável distribuída para todos os desenvolvedores |
Flag --settings ou Agent SDK |
JSON inline | Substituiçõ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.
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 partir do Claude Code v2.1.195, claude auto-mode defaults imprime dois tipos de entrada de ambiente.
- Slots de confiança: nomeiam o que o classificador trata como dentro de seu limite. Os slots são Repositório confiável, Controle de código-fonte, Domínios internos confiáveis, Buckets de nuvem confiáveis, Serviços internos principais e Registro de pacotes interno. As entradas de repositório e controle de código-fonte padrão para o repositório de trabalho e seus remotes configurados. Todos os outros slots de confiança padrão para
None configured, portanto nada mais é confiável até que você o adicione. - Slots de sensibilidade: nomeiam o que as regras de proteção tratam como alto risco. Os slots são Locais de PII / dados regulados, Alvos remotos sensíveis e Escopos de IaC protegidos. Cada um padrão para uma heurística ampla, como tratar qualquer host ou namespace cujo nome carrega
prodouproductioncomo um alvo remoto sensível, portanto as regras de proteção estão ativas antes de você configurar qualquer coisa. Nomear alvos concretos em um slot de sensibilidade faz com que essas regras se apliquem aos alvos nomeados em vez da heurística.
Versões anteriores a v2.1.195 imprimem apenas os primeiros cinco slots de confiança.
Para adicionar suas próprias entradas junto com os padrões, 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.
O exemplo a seguir mantém as entradas padrão e adiciona repositórios, buckets, domínios e serviços de uma organização.
{
"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
- Registro de pacotes interno: o registro npm, PyPI ou outro privado através do qual as instalações devem ser roteadas, portanto as instalações que o contornam para um registro público são bloqueadas
- Locais de PII / dados regulados: os buckets, bancos de dados ou caminhos que contêm dados pessoais ou regulados, para que o classificador proteja esses locais em vez de adivinhar pelo conteúdo
- Alvos remotos sensíveis: os namespaces, hosts ou contêineres que contam como produção, portanto shells remotos e port-forwards para eles precisam de sua aprovação explícita
- Escopos de IaC protegidos: os recursos de infraestrutura cuja aplicação ou destruição sempre devem exigir que você nomeie a mudança
- 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
As entradas Registro de pacotes interno, Locais de PII / dados regulados, Alvos remotos sensíveis e Escopos de IaC protegidos exigem Claude Code v2.1.195 ou posterior. Versões anteriores ainda as leem como contexto simples, mas não têm as regras integradas que as direcionam.
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: limites de segurança incondicionaisautoMode.soft_deny: ações destrutivas que a intenção do usuário pode contornarautoMode.allow: exceções às regras de bloqueio soft
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_denybloqueiam incondicionalmente. A intenção do usuário e exceçõesallownão se aplicam. - Regras
soft_denybloqueiam em seguida. A intenção do usuário e exceçõesallowpodem substituir estas. - Regras
allowentão substituem regrassoft_denycorrespondentes 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_denycorresponde.
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.
O exemplo a seguir mantém os padrões em todas as quatro listas e adiciona regras específicas da organização a cada uma.
{
"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"
]
}
}
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.
Rotear todos os comandos shell através do classificador
Por padrão, regras de permissão Bash e PowerShell estreitas como Bash(npm test) são mantidas no modo automático e resolvidas antes do classificador ser executado. O modo automático suspende apenas as regras amplas que concedem execução de código arbitrário, como Bash(*) ou intérpretes com caracteres curinga. Isso significa que uma regra estreita ainda pode deixar um argumento destrutivo passar sem o classificador vê-lo, por exemplo um caminho de script ou flag que o prefixo da regra não antecipou.
Defina autoMode.classifyAllShell como true para suspender todas as regras de permissão Bash e PowerShell enquanto o modo automático está ativo, para que o classificador avalie cada comando shell independentemente de sua lista de permissões.
{
"autoMode": {
"classifyAllShell": true
}
}
Isso troca latência por cobertura: um comando que uma regra de permissão teria aprovado instantaneamente agora aguarda uma decisão do classificador, e cada comando shell conta como uma chamada do classificador.
A configuração se aplica apenas enquanto o modo automático está ativo, e suas regras de permissão se comportam normalmente em outros modos de permissão.
Inspecionar 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".
Revisar negações
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.
No Claude Code v2.1.193 e posterior, o motivo do classificador para cada negação aparece ao lado da chamada de ferramenta bloqueada na transcrição, na notificação de negação e sob cada entrada na aba Recently denied. Use o motivo para decidir se a correção é uma entrada environment, uma exceção allow ou tentar novamente com intenção explícita em sua próxima mensagem.
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.
Veja também
- Permission modes: o que é modo automático, o que ele bloqueia por padrão e como ativá-lo
- Managed settings: implante a configuração
autoModeem 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