Escada de segurança de permissões no Claude Code

A decisão difícil para iniciantes não é o prompt. É o que Claude Code pode executar sem perguntar. Tudo em ask fica lento. Tudo em allow fica arriscado. A escada de permissões amplia acesso por etapas controladas.

Quem vem de um guia de permissões precisa de uma ordem aplicável em settings hoje. Este artigo separa permissões seguras na primeira semana de operações que devem continuar deny ou com aprovação humana.

Leituras relacionadas: claude-code-permissions-guide, claude-code-security-best-practices, claude-code-harness-lite-workflow.

Por que este padrão vem antes da primeira edição

Claude Code funciona melhor quando a tarefa tem uma fronteira clara. Uma boa fronteira nomeia arquivos que pode ler, arquivos que pode editar, operações proibidas e a prova que encerra o trabalho. Sem isso, um prompt pequeno de iniciante pode virar reescrita ampla, e uma mudança de conteúdo pode quebrar PDF gratuito, Gumroad ou consultoria.

Esse padrão também ajuda receita porque conecta prova técnica com prova para o leitor. Uma página que builda localmente mas envia o leitor ao produto errado não está pronta. Ao registrar scope, comando, URL pública e CTA, amanhã você melhora por evidência, não por memória.

Fluxo prático

1. Level 0 permite apenas Read, Glob e Grep
2. Level 1 adiciona provas como git status, git diff e build
3. Level 2 mantém Write/Edit em ask para paths limitados como content e tests
4. Level 3 faz checks de deploy apenas com confirmação explícita
5. Secrets, force push, deletes destrutivos e billing ficam deny ou aprovação

Situação	Movimento seguro	Prova
Site pessoal de conteúdo	MDX e imagens ficam em ask, build pode ser allowed, deploy exige confirmação e CTA entra como prova.	build, diff, URL
Dashboard SaaS	Componentes UI e testes podem ser edição limitada; auth, billing e migrations ficam com aprovação.	screenshot, test
Workflow de equipe	O nível de permissão entra no CLAUDE.md para reviewers verem a autonomia do agent.	log, command, handoff

A primeira passada deve ser curta. A auditoria deve gerar uma decisão, não um relatório gigante. Se depois de 20 minutos a decisão ainda está confusa, o passo seguro é ler mais um arquivo, não começar a editar.

Prompt e código copiáveis

Desenhe uma escada de permissões Claude Code em quatro níveis para este repo. Separe read-only, proof commands, limited edits e deploy checks. Liste ações que devem ficar deny.

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm.cmd run build)",
      "Bash(git status --short)",
      "Bash(git diff --stat)"
    ],
    "ask": [
      "Write(site/src/content/**)",
      "Edit(site/src/content/**)",
      "Bash(npm install *)",
      "Bash(npx wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(git push --force*)",
      "Bash(rm -rf*)",
      "Read(.env*)"
    ]
  }
}

O código é pequeno de propósito. Ele transforma uma ideia operacional em objeto verificável: existe scope, existem áreas protegidas e existe ao menos um comando de prova. Você pode adaptar para publicação, app, debug ou handoff.

Três exemplos reais

Site pessoal de conteúdo

MDX e imagens ficam em ask, build pode ser allowed, deploy exige confirmação e CTA entra como prova.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Dashboard SaaS

Componentes UI e testes podem ser edição limitada; auth, billing e migrations ficam com aprovação.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Workflow de equipe

O nível de permissão entra no CLAUDE.md para reviewers verem a autonomia do agent.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Falhas que devem ser evitadas

• Permitir deploy ou push cedo demais publica antes da prova.
• Manter tudo em ask deixa o fluxo lento demais.
• Settings sem deny deixam operações perigosas ambíguas.

Outra falha sutil é drift de localização. O artigo em inglês pode explicar o produto correto enquanto outro idioma mantém CTA antigo. Por isso a verificação pública precisa ler h1, abertura e CTA em cada idioma, não só frontmatter lang.

Como levar o leitor ao PDF, Gumroad e consultoria

Se o leitor ainda precisa dominar comandos, envie para o cheatsheet gratuito. Se o bloqueio está em setup, permissões, CLAUDE.md, hooks, MCP ou CI/CD, o melhor próximo passo pago é o Setup Guide. Para prompts repetidos de review, debugging e refactor, use 50 Prompt Templates. Para rollout de equipe, desenho de workflow ou rota de receita, use a consultoria. Para comparar opções, veja products.

Não empurre todo leitor direto para produto pago. Iniciantes geralmente precisam primeiro de um PDF simples. Quem repete prompts está mais perto de templates. Quem trava em permissões, CLAUDE.md, hooks, MCP ou CI/CD está mais perto do Setup Guide. Times com dúvidas de processo estão mais perto da consultoria.

O que verificar antes e depois de publicar

Verificar este artigo significa conferir h1, abertura do texto, heroImage, links internos, links Gumroad e caminho de consultoria. HTTP 200 não basta se o CTA aponta para a próxima ação errada.

Na publicação multilíngue, verifique japonês, inglês, chinês, coreano, espanhol, francês, alemão, português, hindi e indonésio separadamente. O slug pode bater e o corpo ainda estar antigo. Screenshots mobile mostram abertura e CTA juntos.

Métricas para observar depois

Observe inícios de PDF, cliques Gumroad, visitas a products, visitas a training, origem de busca, países e taxa de clique de artigo para CTA. Se PV sobe sem Gumroad, falta ajuste de produto. Se consulta sobe a partir de artigo técnico, o leitor provavelmente precisa de desenho de workflow.