Configurar modo automático

• Adicionar um checkpoint humano para pushes e pull requests com permissions.ask
• 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

​

Limites comuns

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

​

Onde o classificador lê a configuração

​

Definir infraestrutura confiável

• Slots de contexto: descrevem sua organização, stack e postura de segurança para que o classificador leia as outras regras em seu contexto. Ao contrário dos outros dois tipos, os slots de contexto não têm regras próprias que os direcionem. Cada um padrão para None configured ou para a suposição conservadora nomeada ao lado:
  • Organização
  • Uso principal do Claude Code: padrão para desenvolvimento de software
  • Provedor(es) de nuvem
  • Visibilidade do repositório: um repositório é assumido como privado a menos que seu host remoto e nome indiquem o contrário, ou uma verificação de visibilidade anterior na conversa que o classificador lê mostre que é público. O classificador lê suas mensagens e os comandos que Claude executa, não sua saída, portanto a evidência tem que ser algo que ele possa ler, como sua própria mensagem nomeando o repositório como público; a saída de um gh repo view por si só não o alcança. A verificação de evidência de transcrição requer Claude Code v2.1.200 ou posterior
  • Compartilhamento interno / hospedagem de snippet: serviços públicos de paste e gist são tratados como fora do limite de confiança até que você nomeie um
  • CLIs específicas da organização
  • Gerenciamento de segredos
  • Branches padrão / protegidos: main e master são tratados como protegidos até que você nomeie outros
  • Alvos de implantação de CI/CD
  • Postura de rede
  • Namespaces / ambientes de implantação protegidos: volta para a heurística de alvos remotos sensíveis até que você nomeie eles
  • Retenção de dados / desclassificação
• 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. A visibilidade de um repositório abrange apenas material confidencial: um repositório privado é um destino aceitável para material confidencial, mas tornar um repositório privado nunca limpa segredos ou dados pessoais ou confiados nele, e o classificador trata o conteúdo portado, repontado ou lido pela primeira vez de fora do repositório de trabalho como não sendo trabalho daquele repositório. Este escopo requer Claude Code v2.1.203 ou posterior.
• Slots de sensibilidade: nomeiam o que as regras de proteção tratam como alto risco. Os slots são Locais de dados sensíveis e públicos, 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 prod ou production como 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.

{
  "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"
    ]
  }
}

• 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 dados sensíveis e públicos: os buckets, bancos de dados ou caminhos que contêm dados pessoais, dados comerciais confidenciais, credenciais, dados regulados ou material similarmente sensível, e os públicos com os quais os dados em cada local podem ser compartilhados, para que o classificador proteja esses locais em vez de adivinhar pelo conteúdo. Claude Code v2.1.195 através de v2.1.197 nomeiam esta entrada Locais de PII / dados regulados e cobrem apenas locais que contêm dados pessoais ou regulados, sem a dimensão de público
• 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

{
  "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}"
    ]
  }
}

​

Substituir as regras de bloqueio e permissão

• autoMode.hard_deny: limites de segurança incondicionais
• autoMode.soft_deny: ações destrutivas que a intenção do usuário pode contornar
• autoMode.allow: exceções às regras de bloqueio soft

• 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.

{
  "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"
    ]
  }
}

​

Rotear todos os comandos shell através do classificador

{
  "autoMode": {
    "classifyAllShell": true
  }
}

​

Inspecionar os padrões e sua configuração efetiva

claude auto-mode defaults

claude auto-mode config

claude auto-mode critique

​

Revisar negações

​

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 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