Guia de Approval e Sandbox para Claude Code | Configuracao segura para o trabalho diario

Ter approval ligado nao significa, por si so, que Claude Code esta seguro. Quando aparecem confirmacoes demais, as pessoas param de ler. Quando o allow fica amplo demais, o agente pode executar acoes que deveriam continuar sob controle humano.

Depois do getting started, a pergunta real costuma ser esta: o que deve rodar automaticamente, o que deve pedir approval e o que deve ser bloqueado? Para o contexto maior, combine este artigo com harness engineering, permissions guide e security failure cases.

Approval nao e a mesma coisa que seguranca

Uma configuracao diaria confiavel normalmente precisa de tres camadas:

Controle	Papel	Exemplos
permission rules	Separar allow / ask / deny	secrets, comandos destrutivos, deploy
approval flow	Parar antes de efeitos irreversiveis	git push, publish, send
sandbox	Reduzir o alcance da shell	build, verificacao, scripts exploratorios

As referencias oficiais continuam sendo permissions, settings e hooks. A ideia central e: o que e reversivel deve ser rapido; o que nao e reversivel deve ser deliberadamente lento.

Divisao pratica para o uso diario

Acao	Regra recomendada	Motivo
Ler arquivos, buscar, revisar diff	allow	Baixo risco
build, test, lint, analytics	allow	Nao devem travar a iteracao
Editar codigo em uma branch	ask ou allow por sessao	Depende do repo
git push, deploy, publish, send	ask	Ha efeito externo
Ler .env, rm -rf, git reset --hard	deny	Raio de dano alto
Escritas em APIs externas	ask	Afetam sistemas reais

Base util para .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

Se o seu ambiente nao suporta sandbox, compense movendo mais acoes com side effects para ask.

Hooks para reduzir erros repetidos

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

O padrao importante e:

• bloquear secrets antes do commit
• forcar build antes do deploy
• rodar verificacao deterministica depois de editar

Tres fluxos reais

1. Site de conteudo: analytics, tema, novos locais, build, deploy, URL publica e Playwright no mobile.
2. Repo de app: leitura, diff, refactor e testes podem ser rapidos; push, migracoes e producao devem ficar em ask.
3. Outreach / backoffice: pesquisar e rascunhar pode ser automatico; enviar e publicar nao.

Falhas comuns

1. Colocar tudo em ask e aprovar sem ler.
2. Normalizar --dangerously-skip-permissions.
3. Tratar build com sucesso como release com sucesso.

No terceiro caso, o build fica verde, mas a URL publica continua velha ou uma locale nao foi publicada.

O que mudamos hoje na pratica

No ClaudeCodeLab a regra diaria ficou mais dura:

• cada run precisa publicar um artigo novo
• tambem precisa avancar uma tarefa existente
• Playwright precisa verificar o mobile
• todas as URLs de idiomas do mesmo slug precisam ser checadas em producao

Seguranca real vem de regras operacionais claras, nao de avisos vagos.

Proximo passo

Comece pelo cheatsheet gratuito. Se quiser configuracoes, hooks e exemplos prontos para copiar, veja a English products page. Se precisar de ajuda com rollout, review flow ou limites seguros de automacao, use a consultation page.