Checklist de permissões do Claude Code antes do trabalho real

A auditoria de permissões torna Claude Code mais confiável

Claude Code perde valor quando cada ação exige dúvida. A auditoria transforma essa dúvida em um perfil curto: o que pode ler, editar, pedir aprovação e nunca tocar.

Use depois do checklist dos primeiros 30 minutos e antes de aprofundar com o template CLAUDE.md. A meta não é burocracia, mas terminar uma tarefa real com limite claro.

Crie um perfil de permissões

Não comece por uma política enorme. Comece por algo que Claude Code consiga seguir na sessão.

claude_code_permission_profile:
  workspace: "repo only"
  allowed_without_approval:
    - "read files"
    - "run tests"
    - "edit content files"
  ask_first:
    - "install packages"
    - "change auth or billing code"
    - "deploy production"
  never_allow:
    - "print secrets"
    - "delete git history"
    - "rotate keys without owner approval"
definition_of_done:
  - "git diff reviewed"
  - "proof command captured"
  - "rollback note written"

A definição de pronto é essencial. Permissões seguras não bastam sem revisão do diff, comando de prova e nota de rollback.

Exemplo: site de conteúdo com receita

Em um site multilíngue, MDX de artigos, CTA e descrições de produto costumam ser de baixo risco. Formulários, links de pagamento, analytics e deploy exigem aprovação porque afetam leads, dinheiro ou produção.

Audite este repositório antes da implementação.
Retorne:
1. comandos seguros para executar
2. arquivos seguros para editar
3. ações que exigem aprovação
4. a menor tarefa útil para concluir hoje
5. comando de verificação e nota de rollback

Esse prompt faz Claude Code propor uma tarefa pequena antes da implementação: melhorar CTA, revisar o PDF gratuito, ajustar texto do Gumroad ou clarear a rota de consultoria.

Falha comum: liberar tudo no primeiro dia

O erro é permitir pacotes, auth, deploy em produção e trabalho com segredos na mesma sessão. Parece rápido até o rollback ficar nebuloso.

Também não basta escrever proibições. Não expor segredos é necessário, mas você precisa de provas: build, testes, URL pública, formulário e links do Gumroad.

Rotina de 15 minutos

1. Rode “git status —short” antes de começar.
2. Nomeie diretórios editáveis e protegidos.
3. Separe comandos seguros de comandos com aprovação.
4. Registre comando de prova e rollback.

Assim a revisão discute limites concretos, não confiança vaga.

Próximo passo

Comece pelo cheatsheet gratuito se ainda precisa lembrar comandos. Compre o Setup Guide se permissões, CLAUDE.md, hooks ou MCP travam o uso. Use a consultoria para rollout e receita.