O Codex pode mexer no meu código? Como funcionam permissões, sandbox e revisão

Soltar uma IA em cima do repositório do trabalho dá um frio na barriga legítimo

Fala aí, beleza? A dúvida que mais aparece sobre o Codex não é se ele escreve código bom, é se ele vai mexer em coisa que você não pediu

Resposta curta: ele escreve arquivos sim, mas dentro de um limite que VOCÊ define

Neste post eu destrincho os perfis de permissão, a diferença (que confunde muita gente) entre sandbox e aprovação, como travar o alcance antes de rodar e como revisar tudo que ele mexeu antes de aceitar

Bora? 🙂

Os três perfis de permissão do Codex e o que cada um libera

Antes do como, o porquê: o agente precisa de alguma escrita pra ser útil, então a pergunta certa não é "deixo ou não deixo", é "até onde a mão dele alcança"

É isso que os perfis embutidos resolvem, segundo a documentação de permissões do Codex

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Se você já mexeu com permissão de arquivo no Linux, a lógica é bem parecida: o perfil diz o tamanho do braço, não a intenção

E tem um detalhe massa: na abertura o Codex detecta se a pasta está sob controle de versão

Pasta versionada, a recomendação dele é escrita no workspace com aprovações on-request

Repara que essa recomendação junta DUAS coisas: o alcance da escrita (o perfil da tabela) e a política de aprovação, que é outra camada e vem explicada logo na seção seguinte

Pasta não versionada, ele recomenda read-only, porque ali não existe Git pra te salvar de uma mudança indesejada

Quem já configurou permissões e sandbox no Claude Code vai reconhecer o raciocínio na hora

Sandbox e aprovação não são a mesma coisa: entenda as duas camadas

Aqui mora a confusão mais comum

São DUAS camadas diferentes: o sandbox determina quais arquivos e recursos de rede os comandos podem acessar, e as aprovações determinam quando o Codex pausa antes de uma ação

Uma é o que é tecnicamente permitido, a outra é quando ele para e te pergunta, beleza?

No ambiente local o padrão já é conservador: acesso à rede desligado por padrão, com o sandbox aplicado pelo sistema operacional limitando o alcance normalmente ao workspace atual

E ele pede aprovação pra editar arquivos fora do workspace ou pra rodar comandos que exigem acesso à rede

A segunda camada você configura no approval_policy:

Dois avisos: o valor on-failure está descontinuado, e com approval_policy = "never" não existe momento de revisão antes da execução, simplesmente não há nada pra revisar

Tem ainda um caminho do meio bem interessante, que é rotear os pedidos por um agente revisor antes de o Codex executar:

<pre><code>approval_policy = "on-request" approvals_reviewer = "auto_review" </code></pre>

Com essa combinação, pedidos de aprovação elegíveis passam por um agente revisor antes da execução

Como limitar o que o Codex pode tocar antes de rodar no repositório

Antes de mandar o primeiro prompt, gasta dois minutos conferindo o alcance

1. Rode /status pra ver quais diretórios fazem parte do workspace da sessão

O workspace inclui o diretório atual e diretórios temporários como /tmp

O erro comum deste passo: assumir que workspace é exatamente igual à pasta do projeto que você abriu

2. Use /permissions no CLI pra abrir o seletor e trocar o perfil ativo

Quando é só conversa ou planejamento, cai pra somente leitura e pronto

O erro comum deste passo: continuar em perfil de escrita numa sessão em que você só queria entender o código

3. Deixe seus padrões pessoais em ~/.codex/config.toml

Dá pra sobrescrever por projeto adicionando um .codex/config.toml em um projeto ou subpasta confiável

4. Marque como não confiável o que você não conhece

Projetos ou worktrees podem ser marcados como confiáveis ou não confiáveis, e projetos não confiáveis pulam as camadas .codex/ do projeto, incluindo config local, hooks e rules

O erro comum deste passo: clonar repositório de terceiro e sair rodando com a configuração local dele valendo

5. Não misture os dois mundos de configuração

Ou você configura default_permissions e o bloco permissions do TOML, ou configura sandbox_mode / sandbox_workspace_write, nunca os dois juntos

Tome cuidado! Esse é o tipo de conflito que faz você jurar que configurou tudo certo e ainda assim ver comportamento estranho

Como revisar as mudanças do Codex antes de aceitar

Permissão limita o estrago, revisão é o que te dá confiança pra aceitar

1. Peça /review pra ele revisar o próprio trabalho

Ele resume os problemas encontrados na working tree, com foco em mudanças de comportamento e testes faltando

2. Depois rode /diff pra olhar com os próprios olhos

O /diff inspeciona o diff do Git e mostra mudanças em stage, mudanças fora do stage e arquivos que o Git ainda não rastreia

O erro comum deste passo: parar no resumo e nunca abrir o diff de verdade

3. No app, use o painel de revisão

Ele reflete o estado do repositório Git: inclui mudanças feitas pelo Codex, mudanças feitas por você e qualquer outra alteração não commitada

O erro comum deste passo: achar que o painel mostra SÓ o que o agente editou, e aceitar coisa sua no meio do pacote

4. Troque a visão conforme a pergunta que você quer responder

Por padrão ele mostra Unstaged, e ainda existem Staged (índice do Git), Commit (um commit selecionado), Branch (diff contra a branch base) e Last turn (o turno mais recente do assistente)

5. Aceite ou descarte no nível que você quiser

Dá pra dar stage, tirar do stage ou reverter no diff inteiro (com botões como Stage all e Revert all), por arquivo individual e por chunk

E dá pra commitar, dar push em uma branch e criar um pull request sem sair do app

6. No GitHub, chame a revisão no pull request

Basta mencionar @codex review em um comentário do PR

Pra revisar todo PR automaticamente, ative Automatic reviews nas configurações do Codex, o que exige o Codex cloud configurado para o repositório

7. Saiba o que esperar do filtro

No GitHub, o Codex sinaliza apenas problemas P0 e P1, então revisão humana continua existindo

O erro comum deste passo: tratar "nenhum comentário" como "nenhum problema"

8. Peça a correção ali mesmo

Depois da revisão publicada, é só deixar outro comentário pedindo que ele corrija os problemas no mesmo pull request

O que o Codex não consegue alterar (e os erros que travam a execução)

Sintoma: ele não mexe no .git mesmo com escrita liberada

Causa: dentro da raiz gravável, o .git fica protegido como somente leitura, inclusive quando é um arquivo ponteiro gitdir: (nesse caso o caminho resolvido também é protegido)

O mesmo vale pra .agents e .codex quando existem como diretório, e a proteção é recursiva

Solução: nada a fazer, isso é proteção de propósito

Como prevenir: operações de histórico do Git continuam sendo tarefa sua

Sintoma: o comando simplesmente não roda e ele recusa executar

Causa: se a política selecionada não puder ser aplicada pelo sandbox da plataforma, o Codex recusa executar o comando em vez de rodar sem sandbox silenciosamente

Solução: ajuste a política pro que a sua plataforma consegue aplicar

Como prevenir: saber com o que você está lidando ajuda, porque o isolamento usa mecanismo nativo de cada sistema

No macOS, perfis de sandbox Seatbelt

No Linux e WSL, bubblewrap e seccomp, com Landlock em caminhos de compatibilidade

No Windows nativo, o sandbox elevado usa usuários de sandbox com privilégio menor, limites de permissão de sistema de arquivos e regras de firewall

Recusar em vez de rodar solto é o comportamento certo, e é melhor tomar um "não" do que descobrir depois que rodou sem isolamento

Sintoma: o perfil que você quer escolher não está disponível

Causa: administradores podem restringir a lista com allowed_permission_profiles no requirements.toml gerenciado, e ela funciona como allowlist fechada

Os perfis omitidos são negados, incluindo os embutidos omitidos e perfis adicionados em versões futuras do Codex

Solução: falar com quem administra a configuração gerenciada

Como prevenir: confira a versão, porque allowed_permission_profiles exige Codex 0.138.0 ou posterior, e versões 0.137.0 e anteriores ignoram tanto allowed_permission_profiles quanto o default_permissions gerenciado

Sintoma: a configuração de permissão parece não pegar

Causa: perfis novos convivendo com configuração antiga de sandbox no mesmo arquivo

Solução: escolha um lado, ou default_permissions com o bloco permissions do TOML, ou sandbox_mode / sandbox_workspace_write

Como prevenir: sempre que herdar um config.toml de outra pessoa, abra e limpe antes de sair rodando

Qual perfil usar em cada situação

• Só planejar ou tirar dúvida sobre o código: somente leitura via /permissions, sem chance de escrita acidental
• Mexer no repositório versionado do trabalho: escrita no workspace com aprovações on-request, e revisão obrigatória com /review e /diff antes de aceitar
• Abrir uma pasta que não está sob controle de versão: o próprio Codex recomenda read-only nesse caso, e faz sentido demais
• Repositório de terceiro ou worktree suspeita: marque como não confiável, assim ele pula as camadas .codex/ do projeto (config local, hooks e rules)
• Time com regra própria de revisão: crie um AGENTS.md quando você quer que o Codex siga diretrizes de revisão do próprio repositório
• Ambiente onde ninguém vai revisar: fuja de approval_policy = "never", porque aí não sobra nada pra revisar antes da execução

Como isso se comporta na prática

Se a tua dúvida ainda é qual assistente de código por terminal usar, eu já comparei isso em outro post

Aqui eu quero falar do que eu senti sobre CONTROLE, testando o Codex lado a lado com o Antigravity

Antes de rodar qualquer prompt eu criei um arquivo de instruções do projeto (AGENTS.md) descrevendo stack, regras e comandos, justamente pra deixar o comportamento do agente mais parametrizado

Usei o MESMO arquivo nos dois editores, pra não dar vantagem a ninguém

No editor do Codex isso me deu mais trabalho: acabei abrindo a pasta do projeto pelo próprio Codex e copiando o arquivo pronto de fora, em vez de criar direto pela interface

Outra coisa que eu faço sempre: fecho todo prompt com uma trava explícita de escopo

Algo do tipo "não criar upload, não criar formulários, não criar nada além do que foi pedido"

Isso nasceu de comparações anteriores, onde eu senti os editores passando do que eu tinha pedido

E olha que legal: um espectador me apontou que eu avaliei como ponto positivo um recurso que eu nem tinha pedido, crítica justíssima

Minha conclusão é que extrapolar o pedido pode ser bom ou ruim dependendo do caso, e por isso eu prefiro limitar

No prompt final eu ainda peço que o agente rode o projeto e confirme que o fluxo criado funciona, em vez de só me entregar o código e sumir

Sobre o fluxo em si, eu gosto mais de como o Codex separa planejar de executar: depois do planejamento, o passo seguinte já sai como execução, e essa divisão aparece destacada na tela

No Antigravity eu sempre uso o modo de planejamento e evito o modo rápido, porque na minha experiência o rápido faz as coisas de forma atropelada

Aviso honesto: eu tenho bem mais vivência com Antigravity do que com Codex, então a minha opinião pode estar enviesada por isso 😀

No vídeo acima você vê os dois recebendo o mesmo prompt, com o mesmo arquivo de regras, e dá pra acompanhar onde cada um para, o que ele decide fazer sozinho e como fica a conferência do resultado no fim

Conclusão: você é quem decide o alcance

Recapitulando o que importa: o risco não mora no agente, mora na configuração

São duas camadas independentes, o sandbox dizendo o que é tecnicamente alcançável e a política de aprovação dizendo quando ele para e pergunta

São três perfis embutidos (:read-only, :workspace e :danger-full-access), com a rede desligada por padrão no local e caminhos como .git protegidos mesmo dentro da raiz gravável

O próximo passo é bem concreto: abre o teu projeto, roda /status pra ver o que está dentro do workspace e /permissions pra conferir (ou baixar) o perfil ativo

Depois adota /review mais /diff como rotina antes de aceitar qualquer mudança

Feito isso, as permissões do Codex deixam de ser um mistério e viram só mais uma configuração que você domina 🙂

Até o próximo post!