Evite prompts perigosos no Claude Code: sem push automático, sem pular testes

Pedir ao Claude Code “corrija tudo, faça push e deixe os testes para depois” parece rápido. Mas, em uma ferramenta que pode editar arquivos, executar comandos, usar git e consultar documentação, essa frase também pode tirar de você o controle da revisão.

Este guia não é para criar medo. É para prevenir. Eu conferi a documentação oficial do Claude Code em 3 de junho de 2026, especialmente permission modes, /permissions, settings.json e common workflows, e transformei padrões arriscados em prompts seguros para uso real.

flowchart LR
  A["Escrever pedido"] --> B["Permitir investigação"]
  B --> C["Revisar plano"]
  C --> D["Editar com escopo estreito"]
  D --> E["Rodar testes e diff"]
  E --> F["Humano decide push/deploy"]

O que torna um prompt perigoso

Perigoso não significa malicioso. Aqui significa um pedido em que escopo, autoridade ou critério de conclusão ficam vagos enquanto o Claude Code tem acesso a ações poderosas. Para iniciantes: uma fronteira de permissão é o ponto em que o agente precisa pedir confirmação antes de editar arquivos, executar comandos ou sair do projeto.

Claude Code pode ler e buscar arquivos, editar código, executar testes e usar git. A documentação oficial explica que, em uma sessão local, Claude Code pode trabalhar com os arquivos e capacidades de terminal disponíveis ao usuário. Por isso um bom prompt diz o que pode ser feito e também o que não pode.

Formulação arriscada	Substituição segura
Corrija tudo	Nomeie arquivos-alvo e excluídos, depois peça um plano
Faça push quando terminar	Resuma diff e testes; eu decido se faço push
Pule os testes	Proponha a menor verificação útil e explique se não puder rodar
Verifique no banco de produção	Use só dev/staging; gere SQL de produção sem executar
Pule todas as aprovações	Investigue em Plan mode e avance um passo aprovado por vez
Apague coisas antigas	Liste candidatos a exclusão; apague só após aprovação
Atualize tudo para latest	Separe correções de segurança, minor updates e major updates
Pesquise e implemente	Cite fontes oficiais e separe achados de propostas de alteração

Fronteiras de permissão na documentação atual

O permission mode do Claude Code não muda só porque você escreve “faça com segurança” no chat. No CLI, a troca acontece com Shift+Tab ou --permission-mode; em IDEs e Desktop, pelo seletor de modo; padrões persistentes ficam em settings.json.

Em 3 de junho de 2026, os modos principais são: default, que pergunta antes de ações que não sejam leitura; acceptEdits, que aceita automaticamente edições de arquivo e operações comuns de filesystem; plan, ideal para ler, explorar e propor antes de editar; auto, uma research preview com verificações de segurança em segundo plano; dontAsk, que nega ferramentas não pré-aprovadas; e bypassPermissions, reservado para contêineres ou VMs isoladas.

O comando /permissions mostra regras Allow, Ask e Deny. Deny vence, então um time deve negar force pushes, leitura de .env e comandos de deploy em produção em vez de depender da memória de cada pessoa. Regras compartilhadas ficam em .claude/settings.json; experimentos pessoais ficam em .claude/settings.local.json.

settings.json mínimo

Use este exemplo como ponto de partida e ajuste apenas os nomes dos comandos do seu projeto.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

O ponto central é moderação. Uma regra ampla como Bash(*) enfraquece a camada de aprovação. Pré-aprovar checks repetíveis como npm run test e git diff mantém a sessão rápida sem esconder operações arriscadas.

Caso de uso 1: correção de bug

O pedido arriscado é: “Corrija tudo no login e faça push se funcionar”. O escopo é amplo demais e a ação remota fica acoplada à edição.

Objetivo: Corrigir o bug em que a sessão expira logo após o login.
Escopo: Somente src/auth/**, src/session/** e tests/auth/**.
Proibido: git push, deploy, acesso ao banco de produção e leitura de .env.
Processo:
1. Ler arquivos relevantes e listar até 3 causas prováveis.
2. Propor um plano de alteração e esperar minha aprovação.
3. Após aprovação, fazer a menor alteração útil.
4. Rodar npm run test -- auth e resumir falhas, se houver.
5. Encerrar com resumo do git diff e riscos restantes.

Assim Claude Code pode investigar, editar e verificar sem remover os pontos de revisão. Também reduz reescritas não relacionadas.

Caso de uso 2: refatoração

O pedido arriscado é: “Limpe a implementação antiga e apague o que não precisa”. Antigo, limpo e desnecessário são palavras instáveis.

Objetivo: Consolidar validações duplicadas no módulo de billing.
Alterações permitidas: src/billing/validators.ts e seus testes.
Não alterar: migrations/**, prisma/**, public/**, package-lock.json.
Regra de exclusão: Apenas listar candidatos. Não apagar sem aprovação.
Verificação: Rodar npm run test -- billing e npm run lint.
Saída: Relatar motivo, impacto de compatibilidade e testes ainda necessários.

Em refatorações, a lista de exclusões costuma ser a parte mais forte do prompt. Migrations, lockfiles e arquivos gerados podem parecer dispensáveis, mas não são.

Caso de uso 3: revisão antes do deploy

O pedido arriscado é: “CI está lento, pule e mande para produção”. --no-verify pode pular mais que lint; também pode pular hooks e varredura de segredos.

Objetivo: Fazer uma checagem curta antes do release.
Comandos permitidos: git status, git diff, npm run test -- --runInBand, npm run build.
Comandos proibidos: git push, deploy, --no-verify, npm publish.
Critério:
- Parar se testes ou build falharem.
- Resumir só as últimas 80 linhas de qualquer log de erro.
- Reportar status como Pronto / Precisa corrigir / Decisão pendente.

Deploys afetam clientes, cobrança, índices de busca, cache e suporte. Deixe Claude Code preparar evidências; mantenha a ação final de release como decisão humana explícita.

Caso de uso 4: pesquisa e documentação

O pedido arriscado é: “Pesquise o mais recente e atualize o artigo como achar melhor”. Fatos externos mudam, então fontes e escopo de edição precisam ficar separados.

Objetivo: Atualizar o texto sobre permission modes do Claude Code.
Fontes: Priorizar documentação oficial e listar URLs no fim.
Proibido: Não afirmar recursos que a documentação oficial não confirme.
Processo:
1. Criar tabela comparando o texto atual com a documentação oficial.
2. Apenas propor mudanças; esperar antes de editar o artigo.
3. Após editar, verificar links antigos e tamanho da description.

Em pesquisa, trate Claude Code primeiro como verificador de fontes e organizador de diff; só depois como redator.

Falhas concretas

Primeiro, retries ilimitados. “Tente até funcionar” pode transformar uma indisponibilidade em custo extra e pressão de rate limit. Defina tentativas máximas, intervalo e condição de parada.

Segundo, segredos. Chaves reais coladas em prompts podem ficar no histórico, em logs locais e em repasses para subagentes. Valores ficam em variáveis de ambiente ou secret manager; prompts mencionam só os nomes das variáveis.

Terceiro, dependências. “Atualize todos os pacotes para latest” pode trazer versões major com breaking changes. Use npm outdated, separe security fixes de updates normais e revise majors em separado.

Quarto, limpeza e migrations. “Limpe os arquivos do DB” pode ser entendido como apagar histórico de migration. Peça uma lista primeiro e pare em SQL gerado quando houver impacto em dados de produção.

Checklist de revisão

Cole isto no fim de prompts de alto impacto.

Checagem de segurança:
[ ] Nomeei arquivos-alvo e arquivos excluídos
[ ] git push / deploy / publish está proibido ou exige aprovação
[ ] Bloqueei DB de produção, API de produção e operações com custo
[ ] Bloqueei leitura de .env, chaves privadas e dados pessoais
[ ] Pedi Plan mode ou um plano antes de editar
[ ] Incluí ao menos um test, lint ou build
[ ] Pedi para parar e resumir logs em caso de falha
[ ] Pedi diff final, comandos executados e riscos restantes

Se você quer modelos reutilizáveis em vez de reescrever essas regras sempre, a página de produtos inclui pacotes de prompts e checklists. Para adoção em equipe, CLAUDE.md, permissões, gates de revisão e exercícios de onboarding podem ser desenhados com seu repositório real em treinamento e consultoria Claude Code.

Links oficiais

Resultado de testar na prática: no fluxo de Masa, o que mais ajudou foi começar em Plan mode, limitar mudanças a dois até cinco arquivos e manter push/deploy como decisão humana. Evitar prompts perigosos não desacelera o Claude Code; torna a passagem de bastão precisa o bastante para avançar mais rápido e revisar com menos tensão.