Configurar modo automático

• Adicionar um checkpoint humano para pushes e pull requests com permissions.ask
• Definir infraestrutura confiável com autoMode.environment
• Gerar entradas de ambiente com /auto-mode-setup
• Revisar negações para saber o que adicionar a seguir

​

Limites comuns

​

Adicionar um checkpoint humano

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

​

Onde o classificador lê a configuração

​

Defina infraestrutura confiável

• Context slots: descrevem sua organização, stack e postura de segurança para que o classificador leia as outras regras em seu contexto. Cada um é padronizado para None configured ou para a suposição conservadora nomeada ao lado:
  • Organization
  • Primary use of Claude Code: padronizado para desenvolvimento de software
  • Cloud provider(s)
  • Repository visibility: um repositório é assumido como privado a menos que seu host remoto e nome indiquem o contrário, ou o classificador leia uma verificação de visibilidade anterior na conversa mostrando que é público. Nas solicitações do classificador enviadas pelo Claude Code em si, o classificador lê suas mensagens e os comandos que Claude executa, não sua saída. A evidência deve ser algo que o classificador 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.
  • Internal sharing / snippet hosting: serviços públicos de paste e gist são tratados como fora do limite de confiança até você nomear um
  • Org-specific CLIs
  • Secrets management
  • CI/CD deploy targets
  • Network posture
  • Host containment: padronizado para uma máquina de desenvolvedor comum ou executor de CI com internet aberta. Se Claude Code é executado em um container, VM ou pod com uma lista de permissão de egresso ou vizinhos que não deve tocar, nomeie os hosts permitidos, se o endpoint de metadados da nuvem deve ser alcançável e qual projeto de nuvem, cluster ou registro a tarefa usa e sob qual identidade. Até que esta entrada nomeie essa identidade, o classificador bloqueia solicitações pelas credenciais do próprio host. Requer Claude Code v2.1.257 ou posterior
  • Protected deployment namespaces / environments: volta para a heurística de Sensitive remote targets até você nomeá-los
  • Data retention / declassification
• Trust slots: nomeiam o que o classificador trata como dentro de seu limite. Os slots são Trusted repo, Source control, Trusted internal domains, Trusted cloud buckets, Key internal services e Internal package registry. As entradas de repo e source-control são padronizadas para o repositório de trabalho e seus remotes configurados. Todos os outros slots de confiança são padronizados para None configured, portanto nada mais é confiável até você adicioná-lo. 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 do próprio repositório.
• Sensitivity slots: nomeiam o que as regras de proteção tratam como alto risco. Os slots são Sensitive data locations & audiences, Sensitive remote targets e Protected IaC scopes. Cada um é padronizado para uma heurística ampla, como tratar qualquer host ou namespace cujo nome carregue 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 destinos concretos em um slot de sensibilidade faz com que essas regras se apliquem aos destinos 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"
    ]
  }
}

• Organization: o nome da sua empresa e para o que Claude Code é principalmente usado, como desenvolvimento de software, automação de infraestrutura ou engenharia de dados
• Source control: cada GitHub, GitLab ou Bitbucket org para o qual seus desenvolvedores fazem push
• Cloud providers and trusted buckets: nomes ou prefixos de bucket que Claude deve ser capaz de ler e escrever
• Trusted internal domains: nomes de host para APIs, dashboards e serviços dentro de sua rede, como *.internal.example.com
• Key internal services: CI, registros de artefatos, índices de pacotes internos, ferramentas de incidentes
• Internal package registry: o registro npm, PyPI ou outro privado que as instalações devem rotear, para que instalações que o contornem para um registro público sejam bloqueadas
• Sensitive data locations & audiences: 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.
• Sensitive remote targets: os namespaces, hosts ou containers que contam como produção, portanto shells remotos e port-forwards neles precisam de sua aprovação explícita
• Protected IaC scopes: os recursos de infraestrutura cujo apply ou destroy sempre deve exigir que você nomeie a mudança
• Additional context: 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}"
    ]
  }
}

​

Gerar entradas de ambiente com /auto-mode-setup

​

O que /auto-mode-setup lê

• CLAUDE.md, README.md, arquivos de configuração e remotes git do projeto
• Suas configurações de autoMode e permissions.allow
• Os hosts, buckets e nomes de comando dos comandos que Claude executou em suas sessões recentes neste projeto, nunca suas mensagens

• A primeira palavra de cada comando no seu histórico de shell
• Os hosts remotos e nomes dos repositórios sob seu diretório home

​

Revisar e salvar o rascunho

• Claude Code escreve a lista de environment sem "$defaults", porque o rascunho especifica as entradas integradas que deixou inalteradas
• Claude Code inclui "$defaults" em cada uma das listas allow, soft_deny e hard_deny às quais o rascunho adiciona entradas, a menos que você já tenha escrito uma lista allow sem ela, portanto as regras integradas que você não substituiu permanecem em vigor
• Após salvar, Claude Code oferece remover regras de permissions.allow em ~/.claude/settings.json que o modo automático ignora, como Bash(*), ou que aprovam automaticamente comandos destrutivos

​

Desativar /auto-mode-setup

{
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

​

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

​

Editar regras de /permissions

​

Rotear todos os comandos shell através do classificador

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

​

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

claude auto-mode defaults

claude auto-mode config

{
  "allow": [
    ...
    "Test Artifacts: Hardcoded test API keys, placeholder credentials in examples, or hardcoding test cases. Placeholder means authored as a placeholder — a file or value copied from a real secret or sensitive path is never a test artifact (see Sensitive-Source Provenance).",
    ...
  ],
  "soft_deny": [
    "Git Destructive [named+specifics — **must name:** the destructive operation and its target]: Force pushing (`git push --force`), deleting remote branches, tags, or releases, or rewriting remote history. Also `git commit --amend` when the commit being rewritten is not the agent's own unpushed work: either no prior `git commit` is visible (HEAD pre-dates the session), or a `git push` of the current branch is visible after the most recent commit (it has been pushed). Clears when the user asked to amend/reword/fixup, or when it is a message-only reword (`--amend -m …`, nothing newly staged) of a commit the agent visibly created this session.",
    ...
  ],
  "hard_deny": [...],
  "environment": [
    ...
    "**Trusted repo**: The git repository the agent started in (its working directory) and its configured remote(s). When the repo's public/private visibility is given — by the Repository visibility entry or the user's own message — use it to scope what is OK to commit or push there: confidential material is fine in a private repo; in a public one, only that repo's own work is — and content ported, repointed, or first read from outside this session's repo is not its own work, whoever directed the port. Visibility scopes confidential material only: secrets and sensitive data (personal & entrusted) are never cleared into any repo by its visibility (see Definitions).",
    ...
  ]
}

claude auto-mode critique

claude auto-mode reset

​

Revisar negações

​

Corrigir uma negação com uma regra de permissão, uma entrada de ambiente ou um retry

• Um destino que Claude precisa durante toda a tarefa, como um registro de pacotes, um domínio interno ou um host de repositório: adicione-o a autoMode.environment.
• Um comando que você deseja executar sem revisão a partir de agora: adicione uma regra allow.
• Uma ação única que você pretendia: declare essa intenção em sua próxima mensagem e deixe Claude tentar novamente.

​

Corrigir negações repetidas

​

Veja também

• Modos de permissão: o que é o modo automático, o que ele bloqueia por padrão e quais sessões começam nele
• Configurações gerenciadas: implante a configuração autoMode em toda a sua organização
• Permissões: regras de permitir, perguntar e negar que se aplicam antes do classificador ser executado
• Todas as configurações: todas as chaves de configurações, incluindo autoMode