Claude Code pode commitar no seu repositório? Até onde vale delegar o Git

Deixar o agente escrever a mensagem de commit é uma coisa

deixar ele mexer no histórico que o time inteiro puxa é outra completamente diferente

E a documentação do Claude Code é bem direta nisso: ele prepara as mudanças (stage), escreve a mensagem de commit, cria branches e abre pull requests

Ou seja, o fluxo Git de ponta a ponta já está na mão dele

Então a pergunta que interessa não é "o Claude Code consegue commitar?", é até onde vale entregar o volante antes de você ter um combinado escrito

É isso que a gente fecha aqui: a régua do que delegar, o que deixar sob pergunta, o que nunca sai da sua mão, e um combinado mínimo de 6 passos antes do primeiro commit do agente

O que vale delegar ao agente e o que exige mão humana

A régua é simples: delega o que é repetitivo e reversível, segura o que é público ou irreversível

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Só que tem um aviso importante aqui, senão a tabela te engana: isso acima é o COMBINADO que eu recomendo, não o comportamento embutido de qualquer modo

Especificamente na linha do push, o modo auto tem régua própria e bem mais solta (explico ela no cenário de time, logo abaixo)

O que segura o push de verdade é a regra deny ou ask que você escreve, não a boa vontade do modo que estiver ligado

Aquela linha da sessão vinculada ao PR é mais útil do que parece: quando o PR nasce com gh pr create, a sessão fica amarrada nele

Dá pra reabrir depois com claude --from-pr <numero>, que abre o seletor de sessões filtrado por aquele PR, ou colando a URL do PR na busca do /resume

Já os comandos destrutivos da última linha entram na lista de bloqueio do auto mode quando o usuário não pediu pra descartar trabalho local

E tem um detalhe que muita gente descobre tarde: o checkpoint do Claude Code não rastreia arquivos modificados por comando bash

rm, mv e cp não voltam pelo rewind

Só edição feita pelas ferramentas de edição de arquivo é rastreada, e a própria documentação orienta continuar usando Git como histórico permanente

Traduzindo: o rewind não é sua rede de segurança pro repositório, o Git é

O que ter pronto antes de dar acesso ao repositório

Lista curta, tudo verificável antes de soltar o agente:

• Repositório Git de verdade, não uma pasta solta
• gh CLI instalado, se o seu fluxo é GitHub: a doc recomenda porque o Claude sabe usar o gh pra criar issues, abrir pull requests e ler comentários
• Saber em qual arquivo a regra vai morar
• Decidir a atribuição que vai ficar gravada no histórico público

Sobre onde a regra mora, são três níveis:

• ~/.claude/settings.json: usuário, vale em todo projeto
• .claude/settings.json: projeto, compartilhado com o time (esse vai versionado)
• .claude/settings.local.json: local, fora do versionamento

E a atribuição sai pelo campo attribution, que tem precedência sobre o antigo includeCoAuthoredBy (depreciado)

O campo commit controla o texto no commit e o pr controla o texto no pull request

Agora a parte que evita briga boba: a precedência

Os managed settings ficam no topo, e nem argumento de linha de comando passa por cima deles

Um deny em qualquer nível não é liberado por outro nível

--allowedTools não anula um deny de managed settings, e --disallowedTools só acrescenta restrição, nunca afrouxa

Se você está começando agora e ainda está montando a base da ferramenta, vale ver por onde começar no Claude Code antes de sair mexendo em permissão

O combinado mínimo: 6 passos antes do primeiro commit do agente

1. Rode /permissions e olhe o que já existe

/permissions

Ele lista todas as regras e mostra de qual settings.json cada uma veio

O erro comum deste passo: editar o arquivo errado e ficar achando que a regra não pegou, quando na verdade tem outra regra em outro nível decidindo antes 🙂

2. Libere o commit e barre o push

Esse é o coração do combinado: o agente commita à vontade, mas nada sai da sua máquina sem você

{
  "permissions": {
    "allow": ["Bash(git commit:*)"],
    "deny": ["Bash(git push *)"]
  }
}

O erro comum deste passo: achar que uma regra allow mais específica vence o deny

Não vence

As regras são avaliadas na ordem deny, depois ask, depois allow, e a primeira correspondência decide, independente de quão específica a outra seja

3. Escreva o padrão no formato certo

A regra segue Tool ou Tool(especificador), e o sufixo :* é uma forma equivalente de curinga final, reconhecida apenas no fim do padrão

"deny": ["Bash(git push:*)"]

Isso equivale a Bash(git push *)

O erro comum deste passo (e é clássico): escrever Bash(git:* push) achando que o curinga funciona no meio

Não funciona, ali os dois pontos viram caractere literal e o padrão simplesmente não casa

Aí você acha que travou o push e não travou nada

4. Use ask no que você quer conferir toda vez

Às vezes você não quer barrar, quer só ser avisado

"ask": ["Bash(git push:*)"]

Uma regra ask no mesmo escopo força a pergunta mesmo quando o comando seria aprovado automaticamente

5. Ajuste a assinatura que vai pro histórico público

{
  "attribution": {
    "commit": "",
    "pr": ""
  }
}

Pra esconder tudo, commit e pr como string vazia e sessionUrl como false

Tome cuidado aqui: histórico é público e permanente, então decida ANTES do primeiro commit, não depois de 40 deles

6. Feche a porta do bypass

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Esse ajuste costuma ficar em managed settings como política de organização, mas funciona em qualquer escopo

O usuário pode se travar sozinho, e às vezes é exatamente isso que você quer

O porquê: o modo bypassPermissions pula os prompts inclusive pra escrita em caminho protegido como .git e .claude, e a documentação restringe o uso dele a ambiente isolado (container, VM ou dev container sem acesso à internet), onde o Claude Code não pode danificar o sistema hospedeiro

A flag --dangerously-skip-permissions desliga todos os prompts pelo mesmo caminho

Passo opcional, pra quem quer trava dura: um hook PreToolUse

Sair com código 2 bloqueia a chamada de ferramenta antes dela executar, e a razão vai no stderr voltando como feedback pro Claude

O detalhe forte é que esse bloqueio acontece antes da avaliação das regras de permissão, então ele barra mesmo existindo uma regra allow

A alternativa é sair com 0 imprimindo JSON com permissionDecision em deny e o permissionDecisionReason explicando

Quatro cenários e o nível de acesso que cada um pede

1. Projeto pessoal, sem plateia:

Aqui dá pra soltar bastante

Começa no plan mode, em que o Claude lê arquivos e explora mas não altera o código fonte, só propõe

Depois libera o commit e mantém o push sob deny até você pegar confiança no ritmo dele

Os modos documentados são default (manual), acceptEdits, plan, auto, dontAsk e bypassPermissions, então tem bastante espaço pra calibrar

2. Repositório de time:

A regra sai do seu computador e vai pro .claude/settings.json versionado, pra valer pra todo mundo

E aqui o auto mode merece atenção, porque ele funciona como substituto do aprovador humano: é um classificador de transcript rodando no Sonnet 4.6, em dois estágios

Primeiro um filtro rápido de um token (sim pra bloquear, não pra liberar) e, só quando o filtro sinaliza, uma segunda passada com raciocínio em cadeia

Se liga nisso, porque é aqui que a tabela lá de cima deixa de valer sozinha: com o auto ligado, o padrão DELE é permitir push pra qualquer branch do repositório em que se está trabalhando, incluindo a branch padrão

Ou seja, isso é régua do modo auto, que você precisa escolher, e não do default (o modo manual)

Escolheu o auto sem escrever nada? Então o push sai sem te perguntar, e a única coisa que segura ele é a sua regra deny ou ask

Branch com cara de alvo de deploy ou publicação (production, release, gh-pages) fica fora desse padrão e é julgada caso a caso pelo classificador

Já push pra organização de controle de código da empresa fica bloqueado até ser declarado em autoMode.environment

E dá pra manter as regras embutidas e estender com as suas: incluir a string literal "$defaults" no array insere as regras padrão naquela posição, então você herda as atualizações em vez de congelar uma cópia

Se o fluxo do time já passa por pipeline, vale olhar também como automatizar CI/CD com o agente sem abrir mão dessas travas

3. Reescrita de histórico:

Essa é a que fica na mão humana, e o próprio desenho da ferramenta já diz isso

O force push está na lista de bloqueios suaves embutidos do auto mode, junto com curl | bash, deploys de produção e bypass do auto mode

Só que bloqueio suave é suave mesmo: a intenção explícita do usuário sobrepõe

Pedir "limpe o repositório" não autoriza force push

Pedir "force-push nessa branch" autoriza

Ou seja, a trava real contra reescrever trabalho dos outros continua sendo o combinado que VOCÊ escreveu, não a boa vontade do prompt

4. Várias frentes ao mesmo tempo:

Quando você quer duas ou três tarefas rodando sem uma pisar na outra, o caminho são as sessões paralelas em git worktrees isoladas

claude --worktree minha-feature

Também funciona com -w

Por padrão a worktree é criada em .claude/worktrees/<valor>/ na raiz do repositório, numa branch nova chamada worktree-<valor>

A documentação orienta adicionar .claude/worktrees/ ao .gitignore, e um arquivo .worktreeinclude leva arquivos ignorados (tipo .env) pra cada worktree nova

No aplicativo desktop isso já vem de graça: cada sessão nova em repositório Git recebe uma cópia isolada do projeto via git worktree, e as mudanças de uma sessão não afetam as outras até o commit

E tem um caminho de menos atrito pra quem cansou de aprovar comando a comando: o sandbox

Ele aplica isolamento de sistema de arquivos e de rede imposto pelo sistema operacional a cada comando Bash e seus processos filhos

Em vez de aprovar um por um, você define quais arquivos e domínios de rede podem ser tocados

No uso interno da Anthropic, isso reduziu os pedidos de permissão em 84%

Conclusão: o combinado em uma frase e o próximo passo

Delegue o trabalho repetitivo (stage, mensagem de commit, branch, PR) e mantenha na sua mão o que é irreversível ou público (push na branch padrão, force push, reescrita de histórico)

É isso, cabe em uma frase mesmo

E lembra do detalhe que muda tudo na prática: escrever essa régua é trabalho SEU, porque o auto já vem permitindo push por conta própria

Vale lembrar que existe defesa documentada contra prompt injection: o sistema de permissões, detecção de injeção de comando e verificação de confiança

O auto mode ainda acrescenta uma sonda no servidor que varre resultados de ferramentas em busca de conteúdo suspeito, e o classificador nunca vê resultado de ferramenta, então texto injetado não influencia a decisão de aprovação

Mas nada disso substitui você decidir onde fica a linha

Próximo passo concreto, na ordem: roda /permissions pra ver o que já está valendo, escreve o deny do push, e só depois solta o primeiro commit do agente

Depois disso é ir afrouxando conforme a confiança, não antes…

até o próximo post! 😀