O botão «faz tu»

O que é e porque importa

No modo Manual, o Claude Code pede-te autorização antes da maioria das ações. Ao início lês cada pergunta. Passado um tempo carregas em sim sem ler, e a partir daí a autorização já não te protege.

O botão «faz tu» é o contrário: decides uma única vez, a frio, o que o Claude pode fazer sozinho e o que não pode. Livre dentro do projeto: alterar ficheiros, lançar os testes, arrancar o servidor. Bloqueado em três coisas difíceis de desfazer: apagar, publicar, mexer na base de dados real.

São precisas duas peças: um modo de permissões, que decide quanto o Claude te pergunta, e um ficheiro de regras no projeto, que diz o que passa sempre, o que pergunta sempre e o que é proibido.

1. O modo

Eu trabalho em accept edits: o Claude altera os ficheiros do projeto sem perguntar, e tudo o resto passa pelas regras aqui em baixo. Também aceita sozinho alguns comandos básicos de ficheiros, como mkdir, mv, cp e rm, mas só dentro da pasta do projeto.

Para o ativares carrega em Shift+Tab até leres «accept edits on» por baixo do prompt. Nas versões recentes a sessão arranca já em auto mode, onde um segundo modelo verifica as ações no teu lugar: o primeiro Shift+Tab leva-te para Manual, o segundo para accept edits. Ou escolhes no arranque, a partir do terminal:

claude --permission-mode acceptEdits

Antes de dares um trabalho ao Claude, olha sempre para essa linha. O auto é prático e bloqueia as ações arriscadas, mas a própria documentação diz que não garante a segurança. Com accept edits sabes exatamente o que passa sozinho, e as regras valem nos dois.

2. As regras, de uma vez

Cria o ficheiro .claude/settings.json na pasta do projeto. Se já existir, não o substituas: acrescenta a parte «permissions» ao que lá está. O meu é assim:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run test *)",
      "Bash(npm run dev *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Bash(npm publish *)",
      "Bash(vercel *)",
      "Bash(npx vercel *)",
      "Bash(supabase db push *)",
      "Bash(psql *)",
      "Read(./.env.production)"
    ]
  }
}

Põe os teus comandos no lugar dos meus (os testes, o servidor, o deploy, o cliente da tua base de dados real). Atenção: em accept edits, até o rm dentro do projeto passaria sozinho, por isso está nos deny.

O que faz cada parte

• defaultMode: o modo com que a sessão arranca no terminal. Arrancas em accept edits mesmo que o predefinido fosse auto. O flag --permission-mode ganha ao ficheiro.
• allow: os comandos que o Claude lança sem perguntar: testes, lint, servidor de desenvolvimento. Bash(npm test *) cobre npm test sozinho e com qualquer opção a seguir.
• ask: os comandos sobre os quais queres uma pergunta sempre, em qualquer modo, também em auto. O git push manda o código para a internet: quero vê-lo antes.
• deny: o que nunca pode acontecer: apagar ficheiros, o push forçado, publicar, o deploy, a base de dados real. vercel e npx vercel são duas linhas porque a regra sobre vercel não vê o comando com npx à frente.
• Read(./.env.production): o Claude não lê o ficheiro com as chaves de produção, nem com as suas ferramentas nem com cat, e não o pode alterar.

Não tens de escrever o ficheiro à mão. Podes pedir ao Claude que o adapte:

Lê o package.json e os scripts deste projeto. Depois adapta este ficheiro .claude/settings.json: em allow põe os comandos verdadeiros dos testes, do lint e do servidor de desenvolvimento; em deny, os comandos que apagam ficheiros, publicam a app, fazem o deploy ou mexem na base de dados de produção. Não ponhas em allow nada que apague ou mande alguma coisa para a internet. Mostra-me o ficheiro antes de o guardares.

[cola aqui o ficheiro]

Quando o Claude guarda o ficheiro pede-te autorização mesmo em accept edits: é normal, a pasta .claude está protegida.

3. Três coisas que deves saber

O deny ganha sempre

O Claude Code verifica as regras por esta ordem: primeiro deny, depois ask, depois allow. Decide a primeira que corresponde. Um allow não abre um buraco num deny, nem que seja mais preciso. E os deny valem em todos os modos.

No meu ficheiro: o git push --force está tanto no ask como no deny, e ganha o deny. Já o git push origin main --force, o deny não o vê, porque não começa por «git push --force». Começa, no entanto, por «git push», e o ask faz-te a pergunta. É por isso que mantenho as duas linhas.

As regras leem o texto do comando

As regras leem o texto do comando: bash -c 'rm -rf build' ou /bin/rm passam por baixo de «Bash(rm *)». A regra não os reconhece, e a partir daí decidem o modo e as outras regras.

Para uma guarda a sério usa um hook PreToolUse (o guardião do TIPS 05) ou a sandbox (/sandbox). O hook lê o texto todo de cada comando antes de arrancar, mesmo dentro de bash -c. Com a sandbox é o sistema operativo que limita o que os comandos escrevem fora do projeto e a que sites se ligam. Dentro do projeto, porém, deixa escrever: um rm aí só o hook o trava.

O modo sem controlos

O modo sem controlo nenhum (--dangerously-skip-permissions) usa-o só dentro de um container ou de uma máquina virtual, nunca no computador com os teus ficheiros. Também a documentação o recomenda só em ambientes isolados. Se no teu computador queres menos perguntas, o caminho é accept edits com as regras, ou auto.

4. Verifica

Escreve /permissions dentro do Claude Code: vês todas as regras ativas e de que ficheiro vem cada uma. Se faltar uma regra, normalmente o ficheiro está no sítio errado ou o JSON tem um erro, tipo uma vírgula em falta.

Depois faz um teste a sério. Escreve ao Claude:

Cria um ficheiro vazio chamado teste-permissoes.txt. Depois experimenta estes três comandos, um de cada vez, e para cada um diz-me o que aconteceu: bloqueado por uma regra, pediste-me autorização, ou arrancou sozinho.
- npm test (ou o comando dos testes deste projeto)
- rm teste-permissoes.txt
- git push --dry-run
Se um comando for bloqueado, não procures outras formas de o lançar.

É isto que esperas: testes arrancados sozinhos, rm bloqueado, git push com a pergunta (com --dry-run não manda nada para a internet). O ficheiro de teste apagas tu depois: o Claude não consegue.

Os erros mais comuns

• Copiar o ficheiro sem mudar os comandos: se os teus testes não arrancam com npm test, o allow não serve e o Claude pergunta-te sempre. Põe os comandos verdadeiros do teu projeto.
• Trabalhar em accept edits sem rm nos deny: dentro do projeto o rm passa sozinho. Mantém-no nos deny e os ficheiros para deitar fora apaga-os tu.
• Achar que o deny cobre todas as formas do comando: bash -c ou /bin/rm passam. Para uma guarda a sério, junta o hook ou a sandbox.
• Confiar nas instruções no chat, tipo «não apagues nada»: orientam o Claude mas não bloqueiam nada. O que nunca pode acontecer vai para os deny.
• Não ver em que modo estás: a sessão pode arrancar em auto sem que o tenhas escolhido. Antes de um trabalho longo, lê a linha por baixo do prompt.

Checklist

• Modo escolhido e confirmado por baixo do prompt
• .claude/settings.json com os comandos do teu projeto
• rm, deploy, publish e base de dados real nos deny
• git push no ask
• Regras verificadas com /permissions
• Teste feito: testes livres, rm bloqueado, push com pergunta
• Nada de --dangerously-skip-permissions no teu computador

Perguntas frequentes