Claude Code com dados reais: o que configurar antes de apontar o agente para a produção

Tem uma diferença absurda entre o agente errar numa edição de arquivo e o agente errar na base de produção

Na edição feita pelas ferramentas de edição de arquivo do Claude, você dá /rewind e segue a vida

Agora num rm disparado no Bash, num deploy, numa migration no banco? Não tem rewind, o que foi já foi

Por isso usar o Claude Code com dados reais é trabalho de configuração ANTES, nunca depois do susto

Este post é um checklist montado em cima do que a documentação oficial define: modos de permissão, ordem das regras, sandbox e o que o checkpointing simplesmente não cobre

Sem fórmula mágica, sem prompt secreto pra segurar o agente, só configuração 🙂

O que você precisa ter pronto antes de começar:

Antes de sair escrevendo regra, junta essas quatro coisas

• Uma cópia restaurável da base, ou um ambiente espelho: o checkpointing do Claude Code só rastreia as edições feitas pelas ferramentas de edição de arquivo do Claude, então o que passa por comando bash fica de fora, e ações que afetam sistemas remotos (banco de dados, API e deploy) também estão fora do que o /rewind consegue restaurar
• Sistema operacional compatível com o sandbox embutido: ele roda em macOS, Linux e WSL2, e Windows nativo não é suportado (no macOS ele usa o Seatbelt e nem exige instalação)
• Acesso aos arquivos de settings: é ali que ficam as regras de permissão e o bloco de sandbox
• A lista dos seus servidores MCP e hooks ativos: anota mesmo, porque eles são processos separados e rodam sem restrição no host, fora do sandbox de Bash

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

E tem um detalhe de escopo que muita gente ignora

Por padrão o Claude Code tem acesso aos arquivos do diretório onde foi iniciado, e esse acesso só se estende pra outros lugares via chave additionalDirectories nos settings

Os arquivos desses diretórios extras seguem as MESMAS regras de permissão do diretório de trabalho, ou seja, adicionar pasta é aumentar a superfície de contato

Montar espelho e testar em cópia significa repetir rodada, e repetir rodada consome sessão: se isso te preocupa, vale ver antes como gastar menos no Claude Code

Checklist passo a passo: como configurar o Claude Code antes de tocar em dado real

A ordem aqui importa, cada passo fecha uma porta que o seguinte assume fechada

1. Comece em modo plano

O plan mode é um estado de pesquisa: o Claude lê arquivos e explora, propõe as mudanças, mas não executa e não edita o código-fonte

Você entra com Shift+Tab (que cicla os modos no CLI) ou prefixando o prompt com /plan

O erro comum deste passo: pedir pro agente "dar uma olhada rápida" já no modo que executa, achando que ele só vai olhar

2. Escreva as regras entendendo a ordem de avaliação

As regras são avaliadas em deny, depois ask, depois allow, e a primeira correspondência decide

A especificidade da regra NÃO altera essa ordem, não existe "a regra mais detalhada ganha"

O erro comum deste passo: escrever regra de cabeça e errar o nome da ferramenta, o que te deixa com uma falsa sensação de proteção

3. Não conte com allow abrindo exceção dentro de um deny amplo

Uma regra deny ampla bloqueia todas as chamadas que ela casa, mesmo as que também casam com um allow mais estreito

Na prática: Bash(aws *) no deny bloqueia até Bash(aws s3 ls) que esteja no allow

Deny não aceita exceção de allowlist, então a lista de negação tem que ser desenhada pensando no que você AINDA quer poder rodar

4. Trate as ferramentas de MCP como cidadãs de primeira classe nas regras

Elas seguem o padrão mcp__<nome-do-servidor>__<nome-da-ferramenta>, tipo mcp__github__list_issues

O coringa mcp__* casa com toda ferramenta MCP de todos os servidores, e vale pra deny e ask

O erro comum deste passo: tentar usar glob desancorado no allow, que é ignorado com aviso

5. Saiba até onde vai o deny de Read e Edit

Ele vale pras ferramentas internas de arquivo e pros comandos de arquivo que o Claude Code reconhece no Bash, como cat, head, tail e sed

Mas ele NÃO vale pra subprocesso arbitrário que abre arquivo por conta própria

Um script Python ou Node passa por fora disso, e é exatamente por isso que a documentação manda habilitar o sandbox quando você quer bloqueio em nível de sistema operacional

6. Ligue o sandbox e feche o sistema de arquivos

O painel de configuração abre com /sandbox dentro do Claude Code

No sandbox, a escrita fica por padrão limitada ao diretório de trabalho atual e seus subdiretórios, enquanto a leitura cobre o sistema inteiro exceto o que você negar explicitamente

O bloco fica assim:

   {
     "sandbox": {
       "filesystem": {
         "denyRead": ["~/"],
         "allowRead": ["."]
       }
     }
   }

O denyRead bloqueia o acesso dos subprocessos a caminhos específicos, e o allowRead reabre caminhos dentro de uma região negada

O erro comum deste passo: querer "só afrouxar um pouquinho" e desligar filesystem.disabled, que é a única coisa que desliga a proteção do denyRead, e derruba o isolamento de arquivos pra TODOS os caminhos

7. Cuide da rede antes que ela cuide de você

O acesso de rede dentro do sandbox passa por um proxy que roda fora do sandbox, e nenhum domínio vem pré-liberado por padrão

Na primeira vez que um comando precisa de um domínio novo, o Claude Code pede aprovação, e esse sim vale pelo resto da sessão

Se você já sabe onde ele precisa chegar, pré-autoriza com allowedDomains

O erro comum deste passo: aprovar no automático no meio do fluxo e esquecer que aquele sim ficou de pé até o fim da sessão

8. Desligue o allowUnsandboxedCommands em ambiente sensível

Essa opção vem ligada por padrão e permite repetir fora do sandbox um comando que o sandbox barrou, com autorização do usuário

   "allowUnsandboxedCommands": false

Com ela em false, o parâmetro dangerouslyDisableSandbox é ignorado e todo comando roda no sandbox ou precisa estar em excludedCommands

9. Cheque o que está fora da fronteira

O sandbox de Bash cobre os comandos e os processos filhos, e só

Servidores MCP e hooks são processos separados e rodam sem restrição no host, e ferramentas internas como Read, Edit e WebFetch rodam dentro do processo do Claude Code

Pra colocar TUDO atrás de uma fronteira do sistema operacional, o caminho é rodar o processo inteiro do Claude Code dentro do isolamento (sandbox runtime, dev container ou container próprio)

10. Feche a superfície de escalonamento

Pensa comigo: um comando capaz de editar os arquivos de configuração pode se autoconceder permissão

Ou adicionar um hook, ou um servidor MCP, que o Claude Code executa fora do sandbox

Quem escreve na configuração muda as regras do jogo, então esses arquivos entram na lista de coisas que o agente não toca

11. Use hook PreToolUse pro bloqueio que você quer garantir

Um hook PreToolUse consegue bloquear a chamada de ferramenta: sair com código 2 bloqueia a execução, e o conteúdo do stderr é mostrado ao modelo como o motivo do bloqueio

    #!/usr/bin/env bash
    echo "bloqueado: esse caminho toca dado real" >&2
    exit 2

O erro comum deste passo: sair com código 1 achando que barrou, porque exit 1 é tratado como erro NÃO bloqueante e a ação segue

Se você precisa de controle mais fino, o PreToolUse também aceita JSON estruturado no stdout

12. Leia o aviso de startup

Uma regra deny ou ask cujo nome de ferramenta não casa com nenhuma ferramenta conhecida gera um aviso na inicialização, justamente pra pegar erro de digitação

Nomes com _ ou * são isentos dessa checagem, então ali o aviso não vem e a conferência é sua

E duas coisas que valem pra qualquer configuração acima

O modo bypassPermissions não oferece proteção contra prompt injection nem contra ação não intencional, porque pular os prompts remove a sua chance de revisar as chamadas de ferramenta antes delas rodarem

Já a flag --dangerously-skip-permissions é bloqueada quando o Claude Code roda como root ou via sudo no Linux e no macOS, o que é um ótimo sinal de que aquele caminho não era pra ser o normal do seu dia 😀

O agente apagou algo e o /rewind não trouxe de volta

Sintoma: o agente rodou um rm, um mv ou um cp, ou aplicou uma migration no banco, e você foi no restore atrás do estado anterior… e não veio nada

Causa: o checkpointing do Claude Code não rastreia arquivos modificados por comandos bash

Só as edições feitas pelas ferramentas de edição de arquivo do Claude são rastreadas, então rm file.txt, mv old.txt new.txt e cp source.txt dest.txt não são desfeitos

E ações que afetam sistemas remotos, como banco de dados, API e deploy, não podem ser incluídas no checkpoint

Tem mais um caso que pega gente desprevenida: o checkpointing não restaura arquivo que é symlink ou hard link, esses caminhos são pulados quando você escolhe Restore code ou Restore code and conversation no menu /rewind

Como prevenir, que é o único jeito que funciona aqui:

• manter o irreversível fora do alcance do agente, com deny mais sandbox, em vez de contar com desfazer depois
• exercitar o que precisa ser exercitado numa cópia da base, nunca na viva
• tratar o rewind como rede de segurança das EDIÇÕES feitas pelas ferramentas de edição, e não do mundo lá fora

Tome cuidado com o falso conforto aqui: ver o menu de restore te dá a sensação de que tudo volta, e tudo não volta

Níveis de isolamento: sandbox, dev container, Docker e VM

A documentação lista opções com níveis diferentes de isolamento, e elas resolvem problemas diferentes

A leitura prática da tabela é curta: sandbox de Bash protege comando, não protege sessão

Pra colocar a sessão inteira atrás de uma fronteira do sistema operacional, é preciso rodar o processo inteiro do Claude Code dentro do isolamento

Conclusão: por onde começar hoje

Se você só tem meia hora, a ordem é essa

Modo plano primeiro, pra ele ler e propor sem executar

Depois deny no que é irreversível, lembrando que a primeira correspondência decide e que deny não abre exceção

Depois sandbox ligado, com escrita presa no diretório de trabalho e denyRead no que não é da conta dele

E cópia da base pro que precisa mesmo ser exercitado de verdade

Tem um ponto que faz esse esforço valer: as restrições do sandbox impedem que comandos Bash alcancem recursos fora dos limites definidos MESMO quando um prompt injection contorna a decisão do modelo, porque o limite é aplicado pelo sistema operacional e não pelo julgamento do modelo

No modo auto existe ainda um classificador separado que revisa as ações antes delas rodarem, e bloqueia o que escala além do pedido, mira infraestrutura não reconhecida ou parece dirigido por conteúdo hostil que o Claude leu

Limites declarados na conversa (tipo "não faça push", "espere eu revisar antes de fazer deploy") viram sinal de bloqueio pra esse classificador, e regras ask explícitas continuam forçando o prompt

Anota aí: a partir de 14 de agosto de 2026 o modo auto passa a ser o modo de permissão padrão das sessões novas nos planos Pro, Max e Team, ou seja, revisar suas regras agora é melhor do que descobrir o novo padrão no meio de uma tarefa

Próximo passo é bem concreto: abre o /sandbox e escreve o seu primeiro bloco de deny

Depois disso, o agente perto de dado real deixa de ser aposta e vira processo 😀

Até o próximo post!