Entenda por que o agente pede licença
No chat do navegador, o pior que pode acontecer é uma resposta errada. No Codex é diferente: ele apaga, renomeia, cria arquivos, roda comandos e acessa a internet. Um engano vira um arquivo perdido, não só um texto ruim.
Por isso ele trabalha dentro de uma caixa de areia e, quando precisa sair dela, pede licença. O Rui aprendeu isso quando pediu "limpe a pasta do site" e o Codex parou para perguntar antes de apagar 40 fotos de produtos.
🆕 Novo aqui? Três palavras deste módulo
- Sandbox (caixa de areia) — área isolada onde os comandos do agente rodam sem acesso ao resto da máquina. O que acontece lá dentro não escapa.
- Aprovação — o momento em que o Codex mostra o que vai fazer e espera você dizer sim ou não.
- Permissão — a regra que diz quais ações precisam de aprovação e quais ele faz direto.
Como ler o desenho: a moldura tracejada é a caixa de areia. Dentro dela, o agente trabalha na pasta do projeto sem perguntar. Para chegar a qualquer coisa à direita, ele passa pela cancela amarela, que é onde a permissão decide se ele pergunta ou segue.
💡 Pedir licença não é defeito
Quem começa costuma achar as perguntas chatas. Elas são o que deixa você usar um agente poderoso sem medo. A meta não é eliminar as perguntas, e sim ajustar para que ele pergunte só o que importa.
Conheça os três modos de permissão
No aplicativo, o seletor de permissão fica embaixo da caixa de mensagem, ao lado de modelo e esforço. O nome do botão pode mudar entre versões, mas hoje são três modos.
Pedir aprovação pergunta antes de editar fora da pasta e antes de usar a internet. Aprovar por mim só pergunta quando a ação parece arriscada, como apagar ou fazer chamadas externas. Acesso total não pergunta nada.
Como ler o desenho: as três luzes são os três modos. Da esquerda para a direita, ele pergunta cada vez menos. A régua de baixo mostra a troca: o que ele ganha em autonomia, você perde em controle.
| Modo no app | Quando pergunta | No terminal, o mais próximo |
|---|---|---|
| Pedir aprovação | Antes de editar fora da pasta e de usar a internet | -s workspace-write com -a on-request |
| Aprovar por mim | Só em ação arriscada: apagar, chamadas externas | --approve-for-me |
| Acesso total | Nunca | -s danger-full-access com -a never |
| (só leitura) | Ele lê, mas não altera nada | -s read-only |
O que olhar na tabela: no terminal são dois controles separados. O -s diz onde ele pode mexer (só ler, editar na pasta ou acesso total). O -a diz quando ele pede aprovação.
Comece pedindo aprovação para tudo
Nas primeiras semanas, fique no modo Pedir aprovação. Cada pergunta dele é uma aula: você vê que comando ele quer rodar, em que arquivo vai mexer e por quê.
A Paula fez isso por duas semanas. No fim, ela já sabia quais pedidos eram sempre seguros (ler clientes, rascunhar propostas) e quais mereciam atenção (enviar coisas para fora, mexer em contratos assinados).
Como ler o desenho: a linha é o andamento da tarefa. Os pontos azuis ele faz sozinho; nos pontos roxos ele para e mostra um cartão com o que pretende fazer. Nada acontece até você clicar em aprovar.
Escolha "Pedir aprovação"
No seletor de permissão, embaixo da caixa de mensagem. No terminal: codex -s workspace-write -a on-request.
Leia cada cartão antes de clicar
Pergunte-se: "eu entendo o que ele vai fazer?". Se não, recuse e peça "explique esse passo em português simples".
Anote o que sempre aprova
Depois de uma ou duas semanas, a lista de "sempre sim" mostra que você está pronto para o próximo modo.
✓ Bom hábito
- ✓ Ler o comando inteiro antes de aprovar
- ✓ Recusar e pedir explicação quando não entender
- ✓ Usar as pausas para aprender o que ele faz
✗ Mau hábito
- ✗ Clicar em aprovar sem ler, só para andar
- ✗ Aprovar apagar arquivos "porque ele sabe o que faz"
- ✗ Pular direto para acesso total no primeiro dia
Passe para a aprovação automática
Quando as perguntas viram rotina, mude para Aprovar por mim. As ações comuns passam sozinhas por uma revisão automática; você só é chamado quando a ação parece arriscada, como apagar arquivos ou fazer chamadas externas.
É o modo do dia a dia para quem já conhece o agente. O Rui usa assim para atualizar o catálogo: o Codex edita dezenas de arquivos sem interromper, mas para quando quer apagar uma foto antiga.
Como ler o desenho: todas as ações passam pelo funil roxo de revisão. As azuis, rotineiras, seguem direto. As vermelhas, que apagam ou mandam dados para fora, são separadas e chegam até você como pergunta.
Objetivo: trabalhar sem interrupções nas tarefas comuns, mantendo a pergunta nas arriscadas. Esse modo funciona com a caixa de areia que edita só dentro da pasta.
cd <caminho-da-sua-pasta> codex --approve-for-me
💡 A revisão automática não lê a sua mente
Ela separa o que parece arriscado em geral. Ela não sabe que a pasta contratos-assinados/ é sagrada para você. Para isso existem as regras do tópico 6.
Saiba quando usar acesso total
Acesso total é o modo sem freio: o agente sai da caixa de areia e não pergunta nada. No aplicativo ele costuma aparecer destacado em laranja, justamente para lembrar do risco.
Ele tem lugar: tarefas longas em que você não vai estar olhando, numa pasta que você pode perder sem dor, como uma cópia de teste ou uma worktree (módulo 2.2). Nunca na pasta com os dados dos seus clientes.
Como ler o desenho: à esquerda, a redoma verde é uma pasta de teste que você pode jogar fora; ali o acesso total só acelera. À direita, a pasta de clientes fica exposta ao agente sem freio, e qualquer engano atinge dados reais.
✓ Acesso total faz sentido
- ✓ Numa cópia de teste ou numa worktree
- ✓ Em tarefa longa que você revisa no fim
- ✓ Quando você tem backup de tudo
- ✓ Por uma sessão, voltando ao modo normal depois
✗ Nunca com acesso total
- ✗ Pasta com dados de clientes ou contratos
- ✗ Computador com e-mail e banco abertos
- ✗ Tarefa que envia algo para fora
- ✗ "Só para parar de perguntar"
💡 Volte ao modo normal ao terminar
No terminal, -s danger-full-access vale só para aquela sessão: feche e abra sem a opção. No aplicativo, confira o seletor antes da próxima conversa; um laranja esquecido é o caminho mais curto para um susto.
Bloqueie ações específicas na configuração
Os três modos são gerais. Às vezes você quer uma regra só sua: "nunca apague nada em clientes/", "nunca envie e-mail sem me mostrar antes". Isso vai para a configuração do projeto.
Você não precisa escrever a configuração à mão. Peça ao Codex: ele sabe onde fica cada coisa (o .codex/ do projeto ou o global, módulo 2.3) e como escrever a regra. A Paula travou a pasta de contratos assinados em dois minutos.
Como ler o desenho: o painel roxo são as regras que a Paula pediu. A seta mostra o efeito na pasta: as subpastas com cadeado ficam protegidas em qualquer modo de permissão, e as outras seguem livres para o trabalho do dia.
Objetivo: registrar regras de bloqueio que valem neste projeto, sem você editar arquivo de configuração.
Quero bloquear algumas ações neste projeto, em qualquer modo de permissão: (1) nunca apagar arquivos dentro de <clientes/>; (2) nunca alterar nada em <contratos-assinados/>; (3) nunca enviar e-mail sem me mostrar o texto antes. Consulte a sua documentação, diga onde essas regras devem ficar (configuração do projeto ou global) e me mostre exatamente o que vai escrever. Só grave depois que eu aprovar.
Teste rápido (opcional): a Paula quer que o Codex trabalhe sem interromper nas tarefas comuns, mas pare antes de apagar arquivos. Qual modo ela escolhe?
🎓 Resumo do módulo
Próximo módulo:
3.4 — Skills: receitas reutilizáveis