Guia de campo do Claude Code em português

O que ainda aprovar manualmente quando o Claude Code trabalha sozinho

Se for preciso escolher uma ação para manter sob aprovação humana no Claude Code, o envio de código ao repositório remoto é um bom candidato. Ele marca uma passagem verificável entre trabalho local e um ambiente compartilhado, onde outras pessoas ou automações podem ser afetadas. A escolha depende do projeto, mas permite uma divisão prática: o agente prepara a mudança e apresenta os testes; você confere o destino e autoriza o envio.

A fronteira deve acompanhar a consequência

A dúvida não exige escolher entre acompanhar cada edição e liberar qualquer ação. Uma política útil identifica onde o trabalho passa a afetar algo além da pasta local. Em um projeto de software, isso pode acontecer no envio ao repositório, na publicação de uma versão ou na alteração de dados compartilhados.

O critério editorial aqui é reservar a revisão humana para uma consequência que você precisa conferir pessoalmente. Corrigir um arquivo de teste e enviar uma alteração para uma branch usada por outras pessoas têm alcances diferentes. O segundo passo merece uma conferência própria, mesmo quando o primeiro já estava autorizado.

Para entender o funcionamento geral dos modos, consulte o artigo sobre modo automático e permissões. Aqui, o recorte é mais específico: estabelecer uma parada antes do envio de código.

Por que escolher o git push

O modo automático não deve ser interpretado como uma garantia de que todo envio ao repositório vai pedir confirmação. A documentação consultada descreve situações em que pushes no repositório de trabalho podem acontecer sem uma pergunta. Ela também indica regras explícitas de confirmação para quem deseja manter esse ponto sob controle humano.

Isso torna o push um exemplo concreto de uma autorização que convém separar. O agente pode ter permissão para preparar a correção, mas você ainda querer conferir quais commits serão enviados e para onde. Em projetos com publicação automática, vale verificar também o que aquele destino dispara.

Essa é uma recomendação de organização do trabalho. Não significa que todo push seja perigoso nem que uma aprovação manual, sozinha, valide a qualidade da mudança.

Como pedir confirmação antes do envio

No Windows, o arquivo de configuração do projeto pode ser identificado como .claude\settings.json. A p. 27 do Guia de campo do Claude Code apresenta um exemplo com regras de liberação, confirmação e bloqueio. Para o objetivo deste artigo, a parte relevante é a entrada de confirmação para o push.

Se o arquivo já existir, incorpore a entrada à configuração atual. Substituir o conteúdo inteiro por este recorte pode apagar outras regras do projeto.

Trecho de configuração para confirmar o push executado pelo Bash

{
  "permissions": {
    "ask": [
      "Bash(git push *)"
    ]
  }
}

A regra pede confirmação quando a chamada da ferramenta Bash corresponde ao padrão indicado. A documentação registra expressamente que regras de confirmação baseadas no conteúdo do comando, como essa, levam a uma pergunta mesmo no modo automático.

Use /permissions para consultar as regras. O comando permite administrar permissões de liberação, confirmação e bloqueio. Confira se a entrada aparece no escopo pretendido antes de depender dela.

No Windows, confira também a ferramenta usada

O nome da ferramenta faz parte da regra. Uma entrada que começa com Bash não deve ser tratada como uma proteção universal para qualquer execução possível no computador. Se o agente estiver usando PowerShell ou outro caminho para realizar a operação, esse caminho precisa de avaliação própria.

Há outra limitação: o padrão acompanha o texto do comando. O guia alerta, na p. 27, que uma regra de Bash não identifica automaticamente todas as formas de executar o mesmo programa. Uma opção colocada entre o nome do Git e a operação pode produzir uma escrita diferente da prevista pelo padrão.

Portanto, a afirmação verificável é restrita: a configuração exige confirmação para chamadas que correspondam àquela regra. Para exigências de segurança mais fortes, o livro aponta sandbox ou hook como mecanismos a considerar. A documentação oficial de permissões detalha a correspondência e seus limites.

O que conferir quando a pergunta aparecer

A aprovação precisa ter conteúdo. Antes de autorizar, confira pelo menos estes pontos:

Destino: o repositório remoto e a branch correspondem ao trabalho solicitado?
Conteúdo: os commits incluem apenas os arquivos e as mudanças esperadas?
Validação: os testes apresentados exercitam o comportamento alterado?
Efeito seguinte: o envio aciona publicação, implantação ou outra automação?

Se uma resposta estiver ausente, peça a evidência antes de aprovar. Uma descrição confiante do agente não substitui o diff nem o resultado do teste. Também não há motivo para repetir verificações que continuam válidas quando nenhum arquivo mudou.

Teste a parada antes de usar no projeto importante

Faça a primeira verificação em um repositório descartável, com conteúdo sem dados sensíveis. Peça uma operação que corresponda ao padrão configurado e confira se a solicitação de permissão aparece antes da execução. Recuse nessa etapa e verifique que o envio não ocorreu.

Depois, avalie o caminho realmente usado no seu ambiente: ferramenta, escrita do comando e configurações carregadas. Esse teste demonstra o comportamento observado naquele percurso. Ele não prova cobertura para todas as formas alternativas de enviar código.

A resposta prática à dúvida é manter uma aprovação onde ela permite conferir uma consequência concreta. O push é um ponto inicial útil; publicação, exclusão de dados e comunicação com terceiros podem exigir fronteiras próprias. O capítulo 3 do Guia de campo do Claude Code desenvolve essa política de permissões, com o exemplo de configuração e as limitações reunidos na p. 27.