Permissões, Sandbox e Aprovações: Ajustando o controle conforme sua preferência

📚 Navegação da Série: Anterior 14 · Fluxos de trabalho comuns integrou o Codex ao seu ritmo diário de desenvolvimento. Esta parte muda de dimensão — em vez de gerenciar 'como ele trabalha', focamos em 'o quanto ele pode alterar': de pedir sua permissão para cada comando a dar autonomia total, entenda como ajustar os botões do sandbox e de aprovações, e qual configuração escolher para cada cenário.

Deixe-me contar uma tolice que fiz no inverno passado. Eu recém havia configurado o Codex e, para facilitar, defini permanentemente o sandbox_mode como danger-full-access no arquivo ~/.codex/config.toml, sob a justificativa de que 'janelas de aprovação são chatas'. Então, certo dia, em um diretório temporário que não havia sido inicializado com Git, pedi para ele 'limpar arquivos inúteis'. Ele começou a varrer todo o meu diretório raiz — porque, no modo de acesso total, não havia la barreira da 'área de trabalho' para impedi-lo. Cancelei rapidamente pressionando Esc, com frio na barriga.

Depois de avaliar o ocorrido, percebi que o problema não era o Codex, mas eu: eu havia definido uma configuração perigosa, que deveria ser usada apenas em contêineres isolados, como padrão global. O Codex não errou; fui eu que soltei as rédeas onde não deveria.

Na seção 02, já explicamos os conceitos de sandbox e aprovações usando as metáforas da 'cerca do parquinho' e do 'porteiro + segurança' — esta parte não repetirá definições, mas focará em uma coisa: ensinar passo a passo como configurar e escolher. Qual combinação usar, como alterar temporariamente na linha de comando, como persistir no arquivo de configuração e onde desenhar a linha vermelha do modo perigoso.

Ao ler esta parte, você obterá:

• Como combinar os três modos de sandbox (read-only / workspace-write / danger-full-access) com as três estratégias de aprovação (untrusted / on-request / never), com uma tabela de referência
• Modelos para ajustar temporariamente via --sandbox / --ask-for-approval na linha de comando ou persistir como padrão no config.toml
• Qual é a configuração padrão fornecida ao iniciar o Codex (que depende de a pasta possuir Git ou não) e o porquê
• Configurações padrão cruciais em workspace-write, como rede desativada por padrão e pasta .git sob proteção de apenas leitura
• Onde fica o limite do --yolo (liberação total) e por que ele nunca deve ser usado em computadores locais ou de produção

⚠️ As menções abaixo a comandos específicos, opções de configuração e valores padrão são baseadas na documentação oficial do Codex; versões e nomes de modelos que mudam com as atualizações devem seguir o que for exibido localmente. O recurso de 'perfis de permissão (permission profiles)' mencionado é uma funcionalidade Beta que pode sofrer alterações, detalhada separadamente na seção 05.

---

01 Compreendendo: Você está ajustando dois "botões independentes"

Primeiro, vamos esclarecer o ponto que mais costuma confundir: sandbox e aprovação não são níveis diferentes do mesmo recurso, mas sim dois botões independentes que controlam coisas distintas.

Já fizemos essa analogia na seção 02, e aqui mostramos como isso se traduz na configuração — eles são chaves separadas no config.toml e parâmetros distintos na linha de comando:

Botão	O que controla	Chave de Configuração	Parâmetro de Linha de Comando	Abreviatura
Modo Sandbox (sandbox mode, limite do sistema de arquivos e rede)	O quanto ele pode alterar	sandbox_mode	--sandbox	-s
Estratégia de Aprovação (approval policy, se pausa para confirmar cada operação)	Se ele deve te perguntar	approval_policy	--ask-for-approval	-a

Por que destacar que são 'independentes'? Porque o mal-entendido mais comum dos iniciantes é achar que 'se eu ativar o acesso total, ele vai parar de pedir aprovações' — não. Acesso total (girar o botão de sandbox ao máximo) e não pedir aprovações (girar o botão de aprovação ao máximo) são coisas diferentes. Você pode perfeitamente permitir que ele 'acesse toda a máquina, mas te pergunte a cada passo', ou 'limitar o acesso a apenas leitura, mas deixá-lo ler silenciosamente'. O efeito percebido é a combinação desses dois fatores.

Analogia: A "marcha" e o "limite de velocidade" de um carro. O sandbox é como a marcha engatada — a marcha P (read-only) impede o carro de se mover, a marcha D (workspace-write) permite rodar pelas ruas e a marcha fora de estrada (danger-full-access) permite descer até valas; a aprovação é como o alarme de limite de velocidade que você configura — pode ser 'tocar apenas se exceder o limite' (on-request), 'tocar a cada pedestre que passar' (untrusted) ou 'desativar o alarme e dirigir silenciosamente' (never). A marcha define onde o carro pode ir, o alarme define quando te avisar — um não substitui o outro.

Alguns cenários práticos ajudam a entender essa separação:

• Você quer que ele apenas leia o código e escreva uma análise: mude o sandbox para read-only, e a aprovação tanto faz — como ele não pode alterar nada, janelas de confirmação não farão diferença.
• Você quer que ele altere livremente o projeto, mas te avise se tentar sair dele: use sandbox workspace-write + aprovação on-request, que é a combinação de ouro no dia a dia.
• Você está rodando tarefas em lote em um contêiner isolado e não quer interrupções: use sandbox danger-full-access + aprovação never, girando ambos os botões ao máximo — mas apenas em contêineres, como detalharemos adiante.

💡 Resumo em uma frase: O sandbox (--sandbox) controla 'o quanto ele pode alterar' e a aprovação (--ask-for-approval) controla 'se ele deve te perguntar' — são dois botões independentes e chaves de configuração separadas; o nível de controle que você sente é a combinação deles.

Esta imagem organiza os dois botões em uma matriz bidimensional: o eixo horizontal mostra o modo sandbox (do restrito read-only ao flexível danger-full-access) e o eixo vertical mostra a estratégia de aprovação (do cauteloso untrusted ao silencioso never). O cruzamento azul workspace-write + on-request é a combinação recomendada para o dia a dia, enquanto o cruzamento vermelho no canto inferior direito danger-full-access + never (ou seja, --yolo) deve ser restrito a contêineres isolados.

---

02 Três modos de sandbox: Definindo o limite de alteração

O botão de sandbox possui três posições. A definição oficial é direta, e organizamos em termos de 'alteração de arquivos / acesso à rede / cenário ideal' — esta é a tabela mais importante desta seção:

Modo Sandbox	Altera arquivos?	Acesso à rede?	Cenário Ideal
read-only (Apenas leitura)	❌ Não (exige aprovação para salvar)	❌ Não	Revisar código, criar planos, planejar ("não mexa nos meus arquivos")
workspace-write (Escrita na área de trabalho)	✅ Apenas dentro da área de trabalho	❌ Desativado por padrão, requer ativação manual	Padrão para desenvolvimento diário, pouca interrupção
danger-full-access (Acesso total)	✅ Em toda a máquina	✅ Sim	Contêineres isolados / Máquinas virtuais (o nome danger não é por acaso)

Alguns detalhes que costumam gerar confusão no início:

Primeiro: no modo workspace-write, o acesso à rede vem desativado por padrão. Isso pode parecer contraintuitivo — você pode achar que 'se ele pode alterar arquivos, também deveria conseguir conectar à rede para instalar dependências', mas não. A documentação oficial deixa claro: o acesso à rede vem desativado no modo workspace-write, e você precisa ativá-lo manualmente. Para ativar o acesso à rede, adicione o seguinte trecho no config.toml:

[sandbox_workspace_write]
network_access = true

A primeira vez que pedi ao Codex para rodar npm install no modo workspace-write, ele falhou com vários erros de rede. Achei que fosse um problema com meu proxy e perdi bastante tempo até lembrar que o sandbox desativa o acesso à rede por padrão. Lembre-se disso para poupar tempo.

Segundo: a área de trabalho não inclui apenas a "pasta atual". A documentação oficial explica que ela inclui automaticamente diretórios temporários (como /tmp). Para verificar quais diretórios estão mapeados na sua área de trabalho, execute /status na conversa. A saída será semelhante a:

Sandbox: workspace-write
Approval: on-request
Workspace directories:
  /Users/you/myproject
  /tmp

As linhas Sandbox e Approval indicam os modos ativos, e Workspace directories lista os caminhos onde a escrita é permitida.

Terceiro: mesmo no modo workspace-write, alguns diretórios possuem "proteção de apenas leitura" obrigatória. Essa é uma rede de segurança nativa do Codex — mesmo com permissão de escrita ativa, os seguintes caminhos permanecem bloqueados para alteração:

Caminho protegido	Motivo da proteção
<área_de_trabalho>/.git	Evita alterar o histórico do Git acidentalmente e corromper o repositório
<área_de_trabalho>/.agents	Impede alterar as configurações dos próprios agentes silenciosamente
<área_de_trabalho>/.codex	Mesmo motivo, pasta de configuração do próprio Codex

E essa proteção é recursiva — aplica-se a tudo dentro dessas pastas. Portanto, você não precisa temer que o Codex altere sua pasta .git ao habilitar a permissão de escrita, pois o Codex bloqueia esses caminhos sensíveis por padrão.

Quarto: as restrições do sandbox aplicam-se tanto ao Codex quanto aos comandos gerados por ele. Como mencionamos na seção 02, comandos como git, npm ou scripts de testes rodados pelo Codex herdam o mesmo sandbox — impedindo que subprocessos acessem caminhos externos.

💡 Resumo em uma frase: O modo workspace-write é o padrão para o dia a dia, mas lembre-se de que ele bloqueia rede por padrão e protege as pastas .git, .agents e .codex como apenas leitura; para liberar rede configure network_access, e execute /status para checar os caminhos permitidos.

---

03 Três estratégias de aprovação: Controlando as perguntas

O botão de aprovação também tem três níveis. Enquanto o sandbox desenha a cerca, a aprovação define quando parar e te perguntar ao cruzar a cerca:

Estratégia de aprovação	Comportamento do Codex	Explicação simples
untrusted	Executa apenas consultas seguras conhecidas; pede autorização para qualquer outra operação	Bloqueia comandos desconhecidos, foco em segurança
on-request	Executa tarefas na área de trabalho e pede aprovação apenas para sair dela	Equilíbrio ideal para o dia a dia
never	Não solicita aprovações	Usado para automação; as permissões continuam restritas pelo sandbox

Um detalhe oficial importante: untrusted não significa "apenas leitura". Ele continuará a executar automaticamente leituras conhecidas como seguras, mas qualquer comando que altere estado ou invoque execução externa (como comandos do Git destrutivos ou comandos com parâmetros de configuração customizados) exigirá confirmação. Por isso, a experiência no modo untrusted é de confirmações mais frequentes e cautelosas em comparação ao on-request.

Há também uma configuração avançada: never pode ser combinado com qualquer sandbox. Muitos acham que never (não perguntar) significa liberar todas as permissões, o que está errado. A documentação confirma que --ask-for-approval never pode ser usado com qualquer --sandbox — você pode rodar read-only + never para permitir que ele leia o código sem fazer nenhuma pergunta, o que é o padrão para auditorias em CI por ser altamente seguro. "Não perguntar" e "conceder permissão" são conceitos distintos.

Sobre "como aprovar", o padrão é você mesmo (approvals_reviewer = "user"). O Codex também traz a opção de auto_review (revisão automática) — onde outro agente analisa e aprova as requisições em seu lugar. Esse é um recurso avançado em desenvolvimento; detalharemos seus critérios e riscos na seção 16 · Segurança e limites de risco, mas para o dia a dia, a opção user atende perfeitamente.

💡 Resumo em uma frase: O modo on-request é o padrão de aprovação diário; untrusted é mais restrito (libera leitura e exige confirmação para ações); never elimina as perguntas sem alterar as restrições do sandbox, sendo ideal em CI como read-only + never.

---

04 Como configurar: Ajustes temporários na CLI e persistência no config.toml

Para aplicar essas definições, você pode seguir dois caminhos: parâmetros temporários na linha de comando ou persistência no arquivo de configuração.

Ajuste temporário: Linha de comando (vale para a sessão atual)

Passe os parâmetros ao iniciar o Codex para definir a política daquela sessão. A combinação segura recomendada é:

codex --sandbox workspace-write --ask-for-approval on-request

A cerca fica ativa e ele pergunta se tentar sair dela, trazendo segurança sem atrito. Você pode usar as abreviações -s e -a:

codex -s read-only -a on-request "apenas revise este código, sem alterar"

Quer mudar no meio da conversa? Não precisa sair, execute a instrução de barra:

/permissions

Um menu será exibido para você escolher o nível desejado (Read Only, Auto ou Full Access), aplicando-se imediatamente. A prática recomendada é: ao iniciar em um projeto novo, mude para apenas leitura com /permissions para ele sugerir o plano e, após compreender o código, mude para workspace-write para liberar alterações — isso evita modificações indesejadas em trechos que você ainda não compreendeu.

⚠️ Mudança em versões recentes: a partir do codex-cli 0.142, perfis de permissão permission profiles (recurso Beta sob mudanças) substituem as configurações antigas. A instrução /permissions pode exibir opções como Ask for approval, Approval for me ou Full access baseadas em política de aprovação, sem a opção direta Read Only. Para iniciar como apenas leitura nesses casos, use o parâmetro --sandbox read-only na inicialização ou configure sandbox_mode = "read-only" no ~/.codex/config.toml. As referências de /permissions para apenas leitura no restante do texto seguem este mesmo aviso.

A imagem abaixo ilustra as decisões de sandbox e aprovação:

Ela ilustra o fluxo: ao tentar realizar uma ação, o Codex checa o sandbox (se está dentro do limite permitido) e depois aplica a aprovação (se deve pedir confirmação ao usuário) — duas etapas seguidas para garantir controle.

Persistência: config.toml (vale para todas as inicializações)

Para evitar digitar os parâmetros todas as vezes, salve a combinação padrão no arquivo ~/.codex/config.toml:

approval_policy = "on-request"
sandbox_mode    = "workspace-write"

Quer a configuração mais segura? A combinação recomendada é approval_policy = "untrusted" e sandbox_mode = "read-only", iniciando sempre com o maior nível de restrição e liberando permissões manualmente quando necessário. Útil para computadores compartilhados ou de produção.

Se você utiliza diferentes configurações (ex: "uso diário" e "integração contínua CI"), utilize os perfis de configuração (profile) salvando-os em arquivos específicos e escolhendo-os com --profile:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

E chame o perfil desejado:

codex --profile full_auto

⚠️ Não confunda profile (perfil de configuração) com permission profile (perfil de permissão) da seção 05: o primeiro serve para agrupar parâmetros sob um nome, enquanto o segundo é o novo mecanismo Beta para mapear limites de escrita e rede. A configuração com sandbox_mode + approval_policy descrita aqui é a principal recomendação de uso atual.

💡 Resumo em uma frase: Ajustes temporários usam -s / -a ou /permissions na conversa, e persistência definitiva usa sandbox_mode + approval_policy no config.toml; perfis customizados podem ser chamados com --profile.

---

05 Uso Avançado: rules para refinar comandos e permission profiles para desenhar barreiras (Beta)

A configuração tradicional de sandbox e aprovação define políticas macros. Se você precisa de regras como 「permitir este comando específico sempre e bloquear aquele outro de forma definitiva」, existem recursos mais granulares. Você pode pular esta seção em sua primeira leitura e retornar quando necessário.

rules: regras para comandos específicos (Experimental)

⚠️ Recurso experimental sob mudanças. rules é uma funcionalidade experimental.

O mecanismo do Codex para restringir comandos individuais é chamado de rules (regras), e seus estados de decisão são allow / prompt / forbidden, diferentes de termos usados em outros locais — siga este formato.

Ele resolve o seguinte cenário: o sandbox delimita áreas de escrita, mas você pode precisar de regras como 「liberar o comando gh pr view sem pedir confirmação mesmo que saia do sandbox」 ou 「bloquear o comando grep para incentivar o uso do rg」. Em vez de abrir o sandbox, uma regra resolve de forma precisa.

As regras são criadas na pasta ~/.codex/rules/ em arquivos com extensão .rules, usando sintaxe semelhante a Python (Starlark). Exemplo de regra:

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "Permite visualizar PRs, mas exige minha aprovação",
)

O parâmetro decision aceita três opções com regras de prioridade claras — a definição mais rígida prevalece (forbidden > prompt > allow):

Decisão	Efeito
allow	Executa fora do sandbox diretamente, sem perguntar
prompt	Exige confirmação antes de rodar
forbidden	Bloqueia a execução imediatamente, sem perguntar

Há um recurso de segurança importante: comandos encadeados como git add . && rm -rf / são desmembrados e avaliados individualmente — mesmo que o git add seja liberado como allow, a parte rm -rf / será avaliada e bloqueada, impedindo que ações maliciosas passem ocultas. Para testar suas regras, use o utilitário codex execpolicy check com a instrução desejada.

permission profiles: barreiras customizadas de pastas e domínios (Beta)

⚠️ Funcionalidade Beta que não pode ser misturada com a configuração antiga de sandbox. Se você incluir a opção sandbox_mode no arquivo ou passar --sandbox na CLI, o Codex usará o modo sandbox antigo ignorando os permission profiles. Use um método ou outro, não ambos.

Se você precisar de controles finos como 「esta pasta específica permite escrita, este arquivo .env está bloqueado e a rede aceita apenas estas conexões」, use os permission profiles (perfis de permissão). Eles reúnem regras de escrita em arquivos e regras de domínio de rede em uma estrutura, ativada por default_permissions.

O Codex traz três perfis nativos prontos para uso (iniciados com dois pontos :):

Perfil Nativo	Comportamento
:read-only	Ações locais restritas a apenas leitura
:workspace	Permite escrita na pasta raiz do projeto e na pasta /tmp do sistema
:danger-full-access	Remove barreiras locais de sandbox; use apenas em ambientes controlados

Exemplo de perfil customizado que permite escrita no projeto mas protege arquivos .env:

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

A permissão de escrita aceita read / write / deny, com o padrão deny prevalecendo (deny > write > read). Isso permite definir 「projeto liberado para escrita com arquivos .env protegidos contra alteração」 de forma simples. Regras de rede seguem a mesma lógica — conexões externas são bloqueadas por padrão, liberando apenas domínios explícitos em allow, e a regra deny anula qualquer liberação.

Nossa recomendação: inicie com o modelo tradicional do passo 04. Quando surgir a necessidade real de proteger arquivos específicos ou limitar domínios de rede, migre para perfis customizados, lembrando de remover sandbox_mode de suas configurações anteriores.

💡 Resumo em uma frase: O recurso rules restringe comandos por prefixos (allow/prompt/forbidden), e permission profiles (Beta) define limites por caminhos e domínios (com deny prevalecendo); ambos são avançados, utilize as opções padrão do dia a dia antes de adotá-los.

---

06 Políticas padrão de inicialização e limites do modo perigoso

Compreendida a mecânica, resta definir qual modo adotar. O Codex seleciona um modo padrão inteligente ao iniciar baseado na presença do controle de versão Git na pasta.

Como o Codex escolhe o modo padrão

O fluxo padrão analisa a pasta onde o comando foi chamado:

Diretório de inicialização do Codex	Configuração sugerida
Possui controle Git ativo	Modo Auto (workspace-write + on-request)
Sem repositório Git configurado	read-only (Apenas leitura)

Este comportamento é estratégico: com o Git ativo, alterações indesejadas podem ser analisadas com git diff e revertidas com facilidade, permitindo a escrita na área de trabalho; sem controle de versão, alterações seriam definitivas e sem histórico, por isso ele inicia em apenas leitura para sua segurança. Minha falha descrita no início ocorreu justamente por rodar em uma pasta sem Git com permissões totais ativas, removendo as defesas do sistema.

Em alguns cenários, o Codex iniciará como read-only por segurança até você conceder confiança ao diretório (via aviso na inicialização ou comando /permissions). Se ele iniciar restrito, conceda a confiança de diretório para liberar a escrita.

Outro comportamento padrão importante: a pesquisa web (web search) usa cache (cached) por padrão, sem fazer requisições em tempo real. Ela consome um índice estático oficial para reduzir o risco de ataques por injeção de instruções contidas em páginas vivas. Ao habilitar acesso total (--yolo), a pesquisa web muda para o modo em tempo real (live). Para forçar buscas vivas use --search, e para desativar use web_search = "disabled", conforme detalharemos na seção 16 · Segurança e limites de risco.

--yolo: o risco do acesso total

Esta opção representa a ausência completa de restrições. Ela possui duas formas de ativação:

• Via configuração: sandbox_mode = "danger-full-access" e approval_policy = "never"
• Via CLI: --dangerously-bypass-approvals-and-sandbox (abreviado como --yolo - you only live once)

A opção --yolo indica explicitamente o risco envolvido. Ela desativa o sandbox e as aprovações, permitindo ao Codex agir de forma autônoma em toda a sua máquina. Avalie onde utilizá-la:

Cenário de execução	Recomendação para uso do --yolo / Acesso total
Contêiner isolado / Máquina virtual / dev container	✅ Permitido (uma quebra afetará apenas o ambiente temporário)
Execução de CI em ambiente isolado	✅ Permitido (desde que o contêiner de build seja descartável)
Máquina local de desenvolvimento principal	❌ Não recomendado (mantenha as aprovações ativas por segurança)
Servidor com dados críticos ou código de produção	❌ Bloqueado (risco de perda ou vazamento de dados)

O uso de acesso total vem marcado com (not recommended) (não recomendado). Se você desenvolve em containers ou se a máquina de trabalho não roda sandboxes nativos de Linux, adicione o isolamento via Docker ou dev container e execute o --yolo dentro dele — usando o container como barreira física de segurança. O Codex fornece um exemplo de devcontainer com regras de firewall prontas para este fim.

Lembre-se do alerta da documentação: mesmo em dev containers isolados com acesso total ativo, riscos persistem — scripts maliciosos em dependências podem capturar credenciais de acesso ou tokens do próprio Codex. Por isso, use essa configuração apenas em repositórios confiáveis e monitore as ações do agente.

Nossa recomendação é clara: limite o uso de acesso total a ambientes descartáveis e mantenha as aprovações ativas em sua máquina pessoal. A comodidade de não confirmar ações não justifica expor seu ambiente de trabalho.

💡 Resumo em uma frase: O Codex decide o modo inicial conforme o uso de Git (Git ativo → Auto, Sem Git → apenas leitura); a busca web padrão usa cache por segurança, e o modo --yolo deve ser restrito a contêineres de desenvolvimento isolados, mantendo as travas ativas na máquina de trabalho.

---

07 Laboratório: Experimentando os modos de permissão na prática

Para compreender o funcionamento, crie um laboratório simples para ver a diferença entre confirmações exigidas e ações liberadas pelo Codex. Você só precisará de uma pasta vazia.

Passo 1: Criar uma pasta vazia e iniciar o Codex.

No Mac / Linux (no Windows, execute no PowerShell sem a opção -p):

mkdir -p ~/perm-demo && cd ~/perm-demo
codex

Nota: como a pasta não possui Git ativo, o Codex iniciará como apenas leitura (read-only) conforme explicado no passo 06.

Passo 2: Verificar o status ativo.

Execute na conversa:

/status

Resultado esperado: Serão exibidos o modo sandbox ativo, a política de aprovação e os caminhos da área de trabalho.

Passo 3: Tentar criar um arquivo em modo apenas leitura.

Com o modo read-only ativo (se necessário, mude com /permissions para Read Only), solicite a criação de um arquivo:

Crie o arquivo hello.txt com a linha "hello codex".

Resultado esperado: O Codex não criará o arquivo diretamente; ele solicitará sua autorização, pois a ação de escrita viola as permissões do sandbox read-only:

Preciso criar o arquivo hello.txt, mas a ação excede a permissão de apenas leitura. Você autoriza a execução?

Essa interrupção demonstra o funcionamento do sandbox e da aprovação: o sandbox bloqueia a ação direta e a aprovação aciona a pergunta para validação do usuário.

Passo 4: Alterar o modo de permissão e repetir.

Chame as permissões:

/permissions

Selecione a opção Auto / Workspace Write no menu e repita o pedido de criação do arquivo hello.txt. Resultado esperado: a alteração será realizada diretamente sem perguntas, pois a escrita na área de trabalho é permitida por esse modo.

Arquivo hello.txt criado com sucesso.

Passo 5 (Opcional): Testar restrição de rede.

Com o modo de escrita na área de trabalho ainda ativo, solicite uma ação externa:

Use o comando curl para buscar a página https://example.com e exiba o resultado.

Resultado esperado: como o modo workspace-write bloqueia conexões de rede por padrão (visto na seção 02), o Codex solicitará autorização para conectar ou relatará falha de conexão, reforçando a separação entre escrita de arquivos e acesso externo.

Com este exercício, você validou a barreira de apenas leitura, a liberação de escrita no projeto e o bloqueio de rede padrão. O controle do Codex baseia-se nessas regras.

💡 Resumo em uma frase: Use uma pasta vazia para testar o /status, ver o bloqueio de escrita em apenas leitura, a liberação de arquivos no modo Auto e a restrição de rede padrão. Experimentar esses estados ajuda a fixar as configurações.

---

08 Resumo

Esta seção explicou a estrutura de controle de permissões do Codex, permitindo calibrar o nível de autonomia do agente no dia a dia.

Tabela de resumo das regras:

Objetivo	Mecanismo	Ponto Chave
Definir área de atuação	Sandbox --sandbox	Opções read-only / workspace-write / danger-full-access
Definir confirmações	Aprovação --ask-for-approval	Opções untrusted / on-request / never independentes do sandbox
Alterações pontuais	CLI / /permissions	Permite trocar a política durante a conversa
Definir padrões permanentes	config.toml	Mapeamento com sandbox_mode and approval_policy no perfil padrão
Regras de segurança finas	rules / permission profiles	Controle avançado de comandos e diretórios. Perfis não se misturam com sandbox antigo
Autonomia total	Opção --yolo	Uso restrito a contêineres e VMs isolados; evite na máquina pessoal

A partir de agora, você entende: o papel de cada nível de sandbox e política de aprovação, como alternar modos na CLI ou no config.toml, as políticas padrão aplicadas conforme o uso de Git e as restrições internas como o bloqueio de rede padrão e a proteção da pasta .git. O gerenciamento dessas permissões permite trabalhar com segurança mantendo a produtividade do agente.

---

A próxima seção 16 · Segurança e limites de risco — agora que você conhece as configurações de permissões, abordaremos o aspecto estratégico da segurança: como avaliar a segurança de códigos externos gerados por IA? Como funcionam ataques de injeção de instruções e como proteger seus dados? Qual a postura recomendada para o uso da busca web e ferramentas de revisão automática? Entendido como configurar as amarras, analisaremos onde e quando apertá-las.

---

Leituras Recomendadas

• Cloud Codex Cloud: Executando tarefas pesadas na nuvem
• Subagentes (Subagents): Criando instâncias de trabalho sob demanda
• Melhores Práticas: Recomendações de uso eficientes para o dia a dia