Como rodar o Claude Code sem supervisão sem se arrepender

Comece pela máquina, não pelas opções

Cada proteção abaixo fica mais fácil quando o agente roda em uma máquina que não guarda mais nada. No seu notebook, “permitir tudo” significa o seu e-mail, o seu gerenciador de senhas, as suas credenciais de produção e as suas fotos. Em uma máquina dedicada com um repositório e um token limitado, “permitir tudo” significa esse repositório e esse token. A própria Anthropic orienta que o modo bypass seja usado em um ambiente isolado. Coloque o agente em um e o resto desta página fica mais simples.

Os modos de permissão do Claude Code

O Claude Code tem quatro modos. Escolha um por tarefa, não um para sempre.

• default. Pergunta antes de editar arquivos e de rodar comandos no shell. Certo para trabalho interativo. Errado para a noite.
• acceptEdits. Edita arquivos na pasta de trabalho sem perguntar. Ainda pergunta antes de comandos no shell. Um bom meio-termo para refatorações em que os testes são o juiz.
• plan. Lê e pensa, mas não muda nada. Use para obter um plano que você revisa antes da execução de verdade.
• bypassPermissions. Nenhuma pergunta. Este é o modo sem supervisão. Use só em uma máquina isolada com as regras de negação abaixo no lugar.

Defina o modo ao iniciar.

claude --permission-mode acceptEdits

Ou deixe um deles como padrão de um projeto no arquivo de ajustes. Você pode fazer commit dele para a equipe toda compartilhar.

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

As regras de negação valem em todos os modos

Esta é a parte que a maioria das pessoas não percebe. As regras de permissão ficam por cima do modo, e uma regra de negação bloqueia a ação mesmo no modo bypass. Isso faz das regras de negação a rede de segurança real para execuções sem supervisão. As regras de permitir aprovam antes as coisas para as quais você diria sim toda vez, para o agente não travar nelas.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push origin HEAD:*)"
    ],
    "deny": [
      "Bash(git push:*--force*)",
      "Bash(git push origin main:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)"
    ]
  }
}

Leia a lista de negação como uma política, porque é isso que ela é. Nada de force push. Nada de push na main. Nada de exclusão recursiva. Nada de requisições externas inventadas pelo agente. Nada de ler arquivos de segredos. Ajuste para o seu projeto, mas mantenha uma lista de negação em toda máquina sem supervisão.

Hooks para as regras que um padrão não expressa

Algumas regras dependem do contexto. Um hook roda um script antes de uma chamada de ferramenta e pode aprovar, bloquear ou alterar essa chamada. Um hook comum bloqueia qualquer comando que mencione um hostname de produção, seja qual for o comando.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/block-prod.sh" }
        ]
      }
    ]
  }
}

O script lê a chamada da ferramenta pela entrada padrão e sai com um código diferente de zero para bloquear. Mantenha os hooks pequenos e simples. Um hook que pode falhar sem ninguém perceber é pior do que nenhum hook.

O git é a sua melhor proteção

Os ajustes dentro do agente são uma camada. O repositório é uma segunda camada que não liga para qual agente está rodando.

• Proteja a main. Exija um pull request e uma execução de CI verde para fazer merge. Assim um push descontrolado não consegue colocar nada lá.
• Uma branch por tarefa. O agente começa em uma branch nova e faz push só dessa branch.
• Dê ao agente um token que pode fazer push de branches e abrir pull requests, e nada mais. Sem escopo de admin. Sem escopo de exclusão. Um token fine-grained do GitHub limitado a um repositório faz isso.
• Os testes são o juiz. Se a suíte falhar, o pull request fica vermelho e você vê isso de manhã.

Credenciais: mínimas e separadas

Nunca coloque uma credencial pessoal em uma máquina sem supervisão. Crie uma conta ou um token separado para o agente, com o menor escopo que permite fazer a tarefa. Staging, não produção. Só leitura quando ler basta. Se o agente precisa entrar em um serviço pelo navegador, entre com uma conta de teste. Troque o token quando o projeto acabar.

Execuções headless com um teto

Para uma tarefa em script, o modo print roda um prompt e sai. Dê a ele um limite de turnos para que um agente confuso não fique em loop a noite toda.

claude -p "Fix the failing tests in packages/api and open a PR" \
  --permission-mode acceptEdits \
  --max-turns 60

Salve a saída em um arquivo de log. De manhã você quer ler o que ele fez, não adivinhar.

As mesmas regras para o Codex

O Codex CLI separa duas perguntas. Quando ele pede aprovação, e no que ele pode mexer. Para uma tarefa sem supervisão dentro de um repositório, a combinação é nunca perguntar e escrever só dentro do workspace.

codex -a never -s workspace-write exec "Fix the failing tests and commit"

O Codex também tem uma opção que remove as aprovações e o sandbox ao mesmo tempo. Trate essa opção exatamente como o modo bypass do Claude Code. Máquina isolada ou nada.

A lista do nunca

Seja qual for a ferramenta, um agente sem supervisão não deve poder fazer nenhuma destas coisas. Se a sua configuração permite alguma delas, corrija isso antes da primeira noite.

• Fazer push em uma branch protegida ou force push em qualquer lugar.
• Ler ou enviar um segredo de que não precisava para a tarefa.
• Mexer em dados de produção, mesmo só para ler.
• Gastar dinheiro. Nada de consoles de nuvem, páginas de pagamento ou contas de anúncio.
• Enviar mensagens para pessoas. Nem e-mail, nem chat, nem redes sociais.
• Apagar qualquer coisa fora da árvore de trabalho.