Aprovações do agente e segurança

O Codex ajuda a proteger seu código e seus dados e reduz o risco de uso indevido.

Por padrão, o agente é executado com o acesso à rede desativado. Localmente, o Codex usa um sandbox imposto pelo sistema operacional que limita o que ele pode acessar (geralmente, o workspace atual), além de uma política de aprovação que determina quando ele deve parar e solicitar sua aprovação antes de agir.

Para uma explicação geral de como o ambiente isolado funciona no aplicativo do ChatGPT para desktop, na Codex CLI e na extensão para IDE, consulte Ambiente isolado. Para uma visão mais abrangente da segurança empresarial, consulte o documento técnico de segurança do Codex.

Migre da política de aprovação descontinuada untrusted

O Codex e o ChatGPT Work não oferecem mais suporte a approval_policy = "untrusted". Essa configuração descontinuada pode impedir a inicialização de qualquer um dos clientes. Remova-a das configurações de usuário ou projeto, dos arquivos de perfil, dos scripts de inicialização e dos padrões gerenciados. Para uso interativo e somente leitura:

sandbox_mode = "read-only"
approval_policy = "on-request"

Ou execute codex --sandbox read-only --ask-for-approval on-request.

Com on-request, os comandos permitidos pelo sandbox podem ser executados sem aprovação, ler arquivos acessíveis e usar o acesso à rede, se estiver ativado.

Para manter a regra mais rigorosa de aprovação de comandos, não defina explicitamente approval_policy e adicione uma entrada de projeto ao arquivo de configuração do usuário ~/.codex/config.toml:

[projects."/path/to/project"]
trust_level = "untrusted"

Os comandos passam a exigir aprovação, a menos que uma regra da política de execução os permita. Isso também desativa a configuração local do projeto. Definir on-request explicitamente substitui a política derivada do projeto; a configuração gerenciada allowed_approval_policies deve incluir untrusted para permitir essa política.

Sandbox e aprovações

Os controles de segurança do Codex se baseiam em duas camadas que funcionam em conjunto:

• Modo de sandbox: O que o Codex pode fazer tecnicamente (por exemplo, onde pode gravar e se pode acessar a rede) ao executar comandos gerados pelo modelo.
• Política de aprovação: Quando o Codex deve pedir sua aprovação antes de executar uma ação (por exemplo, sair do sandbox, usar a rede ou executar comandos fora de um conjunto confiável).

O Codex usa diferentes modos de sandbox dependendo de onde você o executa:

• Codex Cloud: É executado em contêineres isolados gerenciados pela OpenAI, impedindo o acesso ao sistema host ou a dados não relacionados. Usa um modelo de execução em duas fases: a configuração ocorre antes da fase do agente e pode acessar a rede para instalar as dependências especificadas; em seguida, a fase do agente é executada sem acesso à internet por padrão, a menos que você ative esse acesso para o ambiente. Os segredos configurados para ambientes de nuvem ficam disponíveis apenas durante a configuração e são removidos antes do início da fase do agente.
• Codex CLI / extensão para IDE: Mecanismos do sistema operacional impõem as políticas de sandbox. Por padrão, o acesso à rede fica desativado e as permissões de gravação se limitam ao workspace ativo. Você pode ajustar o sandbox, a política de aprovação e as configurações de rede conforme sua tolerância a riscos.

Na predefinição Auto (por exemplo, --sandbox workspace-write --ask-for-approval on-request), o Codex pode ler arquivos, fazer edições e executar comandos no diretório de trabalho automaticamente.

O Codex pede aprovação para editar arquivos fora do workspace ou executar comandos que exigem acesso à rede. Se quiser conversar ou planejar sem fazer alterações, mude para o modo read-only com o comando /permissions.

O Codex também pode solicitar aprovação para chamadas de ferramentas de aplicativos (conectores) que declarem efeitos colaterais, mesmo quando a ação não é um comando de shell nem uma alteração em arquivo. Chamadas destrutivas de ferramentas de aplicativos/MCP sempre exigem aprovação quando a ferramenta declara uma anotação de ação destrutiva (a menos que ela declare uma anotação de leitura, que tem prioridade).

Monitoramento de segurança e tarefas pausadas

O GPT-6 Astra inclui monitoramento de segurança no Codex e no ChatGPT Work. O monitoramento é executado de forma assíncrona e pode pausar uma tarefa se detectar um comportamento potencialmente inseguro do modelo. A pausa pode ocorrer após a atividade que a desencadeou; o monitoramento não substitui o ambiente isolado, as permissões nem a revisão do resultado.

Se uma tarefa for pausada, leia o aviso e revise os resultados da análise quando estiverem disponíveis. Retome somente depois de verificar que a tarefa pode continuar com segurança. Se o aviso informar que a tarefa foi encerrada ou não oferecer a opção de retomá-la, você não poderá retomá-la por essa interface.

O monitoramento de segurança avalia o comportamento do modelo durante uma tarefa. A revisão automática de aprovações avalia ações individuais que já exigem aprovação, antes que sejam executadas. Uma ação aprovada pela revisão automática de aprovações ainda pode fazer parte de uma tarefa que o monitoramento pause posteriormente.

Acesso à rede Elevated Risk

Para o Codex Cloud, consulte Acesso do agente à internet para ativar o acesso completo à internet ou uma lista de domínios permitidos.

No aplicativo do ChatGPT para desktop, na Codex CLI ou na extensão para IDE, o modo de sandbox padrão workspace-write mantém o acesso à rede desativado, a menos que você o ative na configuração:

[sandbox_workspace_write]
network_access = true

Isolamento de rede

O acesso à rede é controlado por regras de destino que se aplicam a scripts, programas e subprocessos iniciados por comandos. Quando o acesso dos comandos à rede já estiver ativado, ative o recurso network_proxy para restringir esse tráfego conforme a política de rede configurada. Adicionar regras de domínio não ativa o proxy por si só.

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Para uma sessão pontual da CLI, use a forma booleana abreviada quando precisar apenas ativar ou desativar o recurso, e o formato de tabela quando também definir opções de política:

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

O recurso altera a forma como o acesso à rede é controlado quando está ativado; ele não concede acesso à rede por si só. Use sandbox_workspace_write.network_access com a configuração workspace-write para definir se os comandos têm acesso à rede:

• Rede desativada + network_proxy ativado: a rede permanece desativada e o recurso não tem efeito.
• Rede ativada + network_proxy desativado: a rede permanece ativada com acesso direto de saída sem restrições.
• Rede ativada + network_proxy ativado: a rede permanece ativada e o tráfego de saída é restringido pela política de rede configurada.

O recurso de proxy também se aplica aos perfis de permissões. A configuração network.enabled = true de um perfil concede aos comandos acesso à rede, enquanto features.network_proxy = true ativa a aplicação das regras de domínio desse perfil:

default_permissions = "project-edit"

[features]
network_proxy = true

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

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

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

Se você omitir o recurso de proxy neste exemplo, os comandos terão acesso direto à rede e a regra de permissão para api.openai.com não restringirá seus destinos.

Os requisitos de experimental_network gerenciados pelo administrador são independentes da opção de ativação do recurso pelo usuário. Eles podem configurar e iniciar a rede em sandbox sem features.network_proxy, mas não ativam o acesso à rede quando o sandbox ativo o mantém desativado. Consulte Configuração gerenciada para ver a estrutura de requirements.toml usada pelo administrador.

Política de rede

As regras de domínio se baseiam em uma lista de permissões:

• Hosts exatos correspondem apenas a si mesmos.
• *.example.com corresponde a subdomínios como api.example.com, mas não a example.com.
• **.example.com corresponde tanto ao domínio raiz quanto aos subdomínios.
• Uma regra global de permissão * corresponde a qualquer host público que não esteja bloqueado. Trate * como acesso amplo à rede e prefira regras com escopo delimitado sempre que possível.
• deny sempre prevalece sobre allow, e o curinga global * só é válido para regras de permissão.

Destinos locais e privados

Por padrão, allow_local_binding = false bloqueia destinos de loopback, de link local e privados:

• Exceções específicas: adicione uma regra de permissão para um endereço IP local literal exato ou para localhost quando um comando precisar de um destino local específico.
• Acesso mais amplo: defina allow_local_binding = true somente quando quiser, intencionalmente, ampliar o acesso a destinos locais/privados.
• Curingas: regras com curingas não contam como exceções locais explícitas.
• Endereços resolvidos: nomes de host que são resolvidos para IPs locais/privados permanecem bloqueados, mesmo que correspondam à lista de permissões.

Proteções contra reassociação de DNS

Antes de permitir um nome de host, o Codex realiza, dentro do possível, uma verificação de DNS e de classificação de IP:

• Consultas que falham ou excedem o tempo limite são bloqueadas.
• Nomes de host que são resolvidos para endereços não públicos são bloqueados.
• A verificação reduz o risco de DNS rebinding, mas não o elimina. Para impedir completamente esse tipo de ataque, seria necessário manter os IPs resolvidos fixos até a camada de transporte.

Se DNS malicioso fizer parte do cenário de ameaças, aplique também controles de tráfego de saída em uma camada inferior.

Configurações perigosas

Duas configurações ampliam deliberadamente o limite de confiança:

• dangerously_allow_non_loopback_proxy = true pode expor os pontos de escuta do proxy além do loopback.
• dangerously_allow_all_unix_sockets = true ignora a lista de permissões de sockets Unix.

Use essas configurações apenas em ambientes rigorosamente controlados. Quando o proxy de sockets Unix está ativado, os pontos de escuta permanecem restritos ao loopback, mesmo que tenha sido solicitada uma vinculação a outro endereço. Assim, a rede do sandbox não se torna uma ponte de acesso remoto aos daemons locais.

network_proxy fica desativado por padrão. Ao ativá-lo:

Tráfego fora do proxy de rede para comandos

O proxy de rede filtra scripts, programas e processos filhos executados dentro do sandbox local de comandos. Ele não filtra a pesquisa na Web, chamadas de ferramentas de aplicativos ou conectores, conexões com servidores MCP, atividades do navegador ou de Uso do computador, tarefas do Codex Cloud nem solicitações de modelo e autenticação do cliente. Esses recursos usam conexões de serviço, configurações de recursos, políticas de workspace ou controles de ambiente separados.

As ferramentas do navegador verificam separadamente as regras gerenciadas de bloqueio de rede e as listas de permissões exclusivas antes de acessar uma origem. As políticas de origem do navegador podem restringir ainda mais o acesso a sites, uploads, downloads e ferramentas de desenvolvedor. Consulte controles gerenciados do navegador.

Para usuários gerenciados, combine a política de rede para comandos com controles como allowed_web_search_modes, mcp_servers aprovados e requisitos de recursos para aplicativos, plug-ins, navegadores ou Uso do computador. Consulte Configuração gerenciada.

Você também pode controlar a ferramenta de pesquisa na Web sem conceder acesso completo à rede aos comandos iniciados. Por padrão, o Codex usa um cache de pesquisa na Web para acessar os resultados. O cache é um índice de resultados da Web mantido pela OpenAI, de modo que o modo em cache retorna resultados previamente indexados em vez de buscar páginas em tempo real. Isso reduz a exposição à injeção de prompt proveniente de conteúdo arbitrário acessado em tempo real, mas você ainda deve tratar os resultados da Web como não confiáveis. Se você estiver usando --yolo ou outra configuração de sandbox com acesso completo, a pesquisa na Web usará resultados em tempo real por padrão. Use --search ou defina web_search = "live" para permitir a navegação em tempo real, ou defina o valor como "disabled" para desativar a ferramenta:

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

Defina web_search = "indexed" quando o acesso externo à Web precisar ser controlado pelo índice de pesquisa. Tenha cuidado ao ativar o acesso à rede ou a pesquisa na Web no Codex. A injeção de prompt pode fazer com que o agente busque e siga instruções não confiáveis.

Padrões e recomendações

• Ao iniciar, o Codex detecta se a pasta está sob controle de versão e recomenda:
  • Pastas sob controle de versão: Auto (gravação no workspace + aprovações sob solicitação)
  • Pastas sem controle de versão: read-only
• Dependendo da sua configuração, o Codex também pode iniciar em read-only até que você marque explicitamente o diretório de trabalho como confiável (por exemplo, por meio de uma solicitação na configuração inicial ou de /permissions).
• O workspace inclui o diretório atual e diretórios temporários como /tmp. Use o comando /status para ver quais diretórios fazem parte do workspace.
• Para aceitar os padrões, execute codex.
• Você pode definir essas opções explicitamente:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Caminhos protegidos em diretórios raiz com permissão de gravação

Na política de sandbox padrão workspace-write, os diretórios raiz com permissão de gravação ainda incluem caminhos protegidos:

• <writable_root>/.git é protegido como somente leitura, seja um diretório ou um arquivo.
• Se <writable_root>/.git for um arquivo de ponteiro (gitdir: ...), o caminho do diretório Git para o qual ele aponta também será protegido como somente leitura.
• <writable_root>/.agents é protegido como somente leitura quando existe como diretório.
• <writable_root>/.codex é protegido como somente leitura quando existe como diretório.
• A proteção é recursiva, portanto todo o conteúdo desses caminhos é somente leitura.

Executar sem solicitações de aprovação

Você pode desativar as solicitações de aprovação com --ask-for-approval never ou -a never (forma abreviada).

Essa opção funciona com todos os modos de --sandbox, portanto você continua controlando o nível de autonomia do Codex. O Codex faz o possível dentro das restrições que você define.

Se você precisar que o Codex leia arquivos, faça edições e execute comandos com acesso à rede sem solicitações de aprovação, use --sandbox danger-full-access (ou a flag --dangerously-bypass-approvals-and-sandbox). Tenha cuidado antes de fazer isso.

Como alternativa intermediária, approval_policy = { granular = { ... } } permite manter a interação em categorias específicas de solicitações de aprovação e rejeitar automaticamente as demais. A política granular abrange aprovações de sandbox, solicitações de regras execpolicy, solicitações MCP, solicitações de request_permissions e aprovações de scripts de habilidades.

Revisões automáticas de aprovação

Por padrão, as solicitações de aprovação são encaminhadas a você:

approvals_reviewer = "user"

As revisões automáticas de aprovação se aplicam quando as aprovações são interativas, como em approval_policy = "on-request" ou em uma política de aprovação granular. Defina approvals_reviewer = "auto_review" para encaminhar as solicitações de aprovação elegíveis a um agente revisor antes que o Codex execute a ação solicitada:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Para saber mais sobre todo o ciclo de vida do revisor, as condições de acionamento, a precedência de configuração e o comportamento em caso de falha, consulte Revisão automática.

O revisor avalia apenas ações que já precisam de aprovação, como solicitações para ultrapassar os limites do sandbox, solicitações de rede bloqueadas, solicitações de request_permissions ou chamadas de ferramentas de aplicativos e MCP com efeitos colaterais. As ações que permanecem dentro do sandbox continuam sem uma etapa adicional de revisão.

A política do revisor verifica se há exfiltração de dados, sondagem de credenciais, enfraquecimento persistente da segurança e ações destrutivas. Ações de risco baixo e médio podem prosseguir quando a política permite. A política nega ações de risco crítico. Ações de alto risco exigem autorização suficiente do usuário e nenhuma regra de negação aplicável. Falhas na construção do prompt, na sessão de revisão e na análise da resposta bloqueiam a execução por segurança. Tempos limite excedidos são informados separadamente, mas a ação também não é executada.

A política padrão do revisor está no repositório de código aberto do Codex. As empresas podem substituir a seção específica do tenant usando guardian_policy_config nos requisitos gerenciados. Também há suporte ao texto local de [auto_review].policy, mas os requisitos gerenciados têm precedência. Para obter detalhes de configuração, consulte Configuração gerenciada.

No aplicativo do ChatGPT para desktop, essas revisões aparecem como itens de revisão automática com um status como Em revisão, Aprovado, Negado, Interrompido ou Tempo limite excedido. Elas também podem incluir um nível de risco e uma avaliação da autorização do usuário para a solicitação revisada.

A revisão automática usa chamadas adicionais ao modelo, portanto pode aumentar o uso do Codex. Os administradores podem restringi-la com allowed_approvals_reviewers.

Combinações comuns de sandbox e aprovação

Para execuções não interativas, use codex exec --sandbox workspace-write; o Codex mantém as chamadas antigas de codex exec --full-auto como uma opção de compatibilidade descontinuada e exibe um aviso.

Configuração em config.toml

Para conhecer o fluxo de configuração mais amplo, consulte Configuração básica, Configuração avançada e a Referência de configuração.

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

Você também pode salvar predefinições como arquivos de perfil e depois selecioná-las com codex --profile profile-name:

# ~/.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"

Teste o sandbox localmente

Para ver o que acontece quando um comando é executado no sandbox do Codex, use estes comandos do Codex CLI:

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

O comando sandbox também está disponível como codex debug, e os utilitários de cada plataforma têm aliases (por exemplo, codex sandbox seatbelt e codex sandbox landlock).

Sandbox no nível do sistema operacional

O Codex aplica as restrições do sandbox de formas diferentes, dependendo do sistema operacional:

• O macOS usa políticas do Seatbelt e executa comandos usando sandbox-exec com um perfil (-p) que corresponde ao modo --sandbox selecionado. Quando o acesso restrito de leitura habilita os padrões da plataforma, o Codex acrescenta uma política com regras selecionadas para o macOS (em vez de permitir acesso amplo a /System) para preservar a compatibilidade com ferramentas comuns.
• O Linux usa bwrap junto com seccomp por padrão.
• O Windows usa a implementação de sandbox do Linux ao executar no Subsistema do Windows para Linux 2 (WSL2). O WSL1 tinha suporte até o Codex 0.114; a partir da versão 0.115, o sandbox do Linux passou a usar bwrap, portanto o WSL1 não é mais compatível. Ao executar nativamente no Windows, o Codex usa uma implementação de Sandbox do Windows.

A extensão do Codex para IDE oferece suporte direto ao WSL2 no Windows. Adicione o seguinte às configurações do VS Code para manter o agente dentro do WSL2 sempre que ele estiver disponível:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Isso garante que a extensão para IDE herde a semântica do sandbox do Linux para comandos, aprovações e acesso ao sistema de arquivos, mesmo quando o sistema operacional do host é o Windows. Saiba mais no guia do WSL.

Ao executar nativamente no Windows, configure o modo de sandbox nativo em config.toml:

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

Consulte o guia de configuração do Windows para obter detalhes.

Ao executar o Linux em um ambiente de contêineres como o Docker, o sandbox pode não funcionar se a configuração do host ou do contêiner bloquear as operações de namespace, de bwrap com setuid ou de seccomp necessárias para o Codex.

Nesse caso, configure seu contêiner Docker para fornecer o isolamento necessário e execute codex com --sandbox danger-full-access (ou a flag --dangerously-bypass-approvals-and-sandbox) dentro do contêiner.

Execute o Codex em Dev Containers

Se o host não puder executar o sandbox do Linux diretamente, ou se sua organização já adotar o desenvolvimento em contêineres como padrão, execute o Codex com Dev Containers e deixe o Docker fornecer a camada externa de isolamento. Isso funciona com o Dev Containers do Visual Studio Code e ferramentas compatíveis.

Use o exemplo de contêiner de desenvolvimento seguro do Codex como implementação de referência. O exemplo instala o Codex, ferramentas comuns de desenvolvimento, bubblewrap e controles de tráfego de saída baseados em firewall.

A implementação de referência inclui:

• uma imagem base do Ubuntu 24.04 com o Codex e ferramentas comuns de desenvolvimento instalados;
• um perfil de firewall baseado em lista de permissões para acesso de saída;
• configurações do VS Code e recomendações de extensões para reabrir o workspace em um contêiner;
• montagens persistentes para o histórico de comandos e a configuração do Codex;
• bubblewrap, para que o Codex ainda possa usar seu sandbox do Linux quando o contêiner conceder as capacidades necessárias.

Para experimentar:

1. Instale o Visual Studio Code e a extensão Dev Containers.
2. Copie a configuração de exemplo .devcontainer do Codex para seu repositório ou comece diretamente pelo repositório do Codex.
3. No VS Code, execute Dev Containers: Open Folder in Container... e selecione .devcontainer/devcontainer.secure.json.
4. Depois que o contêiner iniciar, abra um terminal e execute codex.

Você também pode iniciar o contêiner pela CLI:

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

O exemplo tem três partes principais:

• .devcontainer/devcontainer.secure.json controla as configurações do contêiner, as capacidades, as montagens, as variáveis do ambiente e as extensões do VS Code.
• .devcontainer/Dockerfile.secure define a imagem baseada no Ubuntu e as ferramentas instaladas.
• .devcontainer/init-firewall.sh aplica a política de tráfego de saída da rede.

O firewall de referência foi projetado para servir como ponto de partida. Se você depende de listas de domínios permitidos para garantir o isolamento, implemente proteções contra DNS rebinding e para atualização de DNS adequadas ao seu ambiente, como atualizações que respeitem o TTL ou um firewall que leve o DNS em conta.

Dentro do contêiner, escolha um destes modos:

• Mantenha o sandbox do Linux do Codex habilitado se o perfil do Dev Container conceder as capacidades necessárias para que bwrap crie o sandbox interno.
• Se você pretende usar o contêiner como limite de segurança, execute o Codex com --sandbox danger-full-access dentro dele para que o Codex não tente criar uma segunda camada de sandbox.

Controle de versão

O Codex funciona melhor com um fluxo de trabalho que usa controle de versão:

• Trabalhe em uma branch de funcionalidade e mantenha git status sem alterações pendentes antes de delegar. Isso facilita isolar e reverter os patches do Codex.
• Prefira fluxos de trabalho baseados em patches (por exemplo, git diff/git apply) a editar arquivos rastreados diretamente. Faça commits com frequência para poder reverter alterações em pequenos incrementos.
• Trate as sugestões do Codex como qualquer outro PR: faça verificações direcionadas, revise os diffs e documente as decisões nas mensagens de commit para fins de auditoria.

Monitoramento e telemetria

O Codex oferece monitoramento opcional via OpenTelemetry (OTel) para ajudar as equipes a auditar o uso, investigar problemas e atender aos requisitos de conformidade sem enfraquecer as configurações padrão de segurança local. A telemetria fica desativada por padrão; habilite-a explicitamente na configuração.

Visão geral

• O Codex desativa a exportação do OTel por padrão para manter as execuções locais autossuficientes.
• Quando a exportação está habilitada, o Codex emite eventos de log estruturados que abrangem chats, solicitações de API, atividade de streaming SSE/WebSocket, prompts do usuário (com o conteúdo ocultado por padrão), decisões de aprovação de ferramentas e resultados de ferramentas.
• O Codex identifica os eventos exportados com service.name (origem), a versão da CLI e um rótulo de ambiente para separar o tráfego de desenvolvimento/homologação/produção.

Habilite o OTel (opcional)

Adicione um bloco [otel] à configuração do Codex (geralmente em ~/.codex/config.toml), escolhendo um exportador e se o texto dos prompts deve ser registrado nos logs.

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none" mantém a instrumentação ativa, mas não envia dados a nenhum destino.
• Para enviar eventos ao seu próprio coletor, escolha uma das opções:

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

O Codex agrupa eventos em lotes e envia os eventos pendentes ao encerrar. O Codex exporta apenas a telemetria produzida pelo seu módulo OTel.

Categorias de eventos

Alguns exemplos de tipos de evento:

• codex.conversation_starts (modelo, configurações de raciocínio, política de sandbox/aprovação)
• codex.api_request (tentativa, status/sucesso, duração e detalhes do erro)
• codex.sse_event (tipo de evento do fluxo, sucesso/falha, duração e contagens de tokens em response.completed)
• codex.websocket_request e codex.websocket_event (duração da solicitação e tipo/sucesso/erro de cada mensagem)
• codex.user_prompt (comprimento; conteúdo ocultado, a menos que seu registro seja explicitamente habilitado)
• codex.tool_decision (aprovado/negado, origem: configuração ou usuário)
• codex.tool_result (duração, sucesso, trecho da saída)

As métricas OTel associadas (pares de contador e histograma de duração) incluem codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event e codex.tool.call (com os instrumentos .duration_ms correspondentes).

Para consultar o catálogo completo de eventos e a referência de configuração, veja a documentação de configuração do Codex no GitHub.

Orientações de segurança e privacidade

• Mantenha log_user_prompt = false, a menos que a política permita explicitamente armazenar o conteúdo dos prompts. Os prompts podem incluir código-fonte e dados sensíveis.
• Encaminhe a telemetria apenas para coletores sob seu controle; aplique limites de retenção e controles de acesso alinhados aos seus requisitos de conformidade.
• Trate os argumentos e as saídas das ferramentas como dados sensíveis. Sempre que possível, prefira ocultar esses dados no coletor ou no SIEM.
• Revise as configurações locais de retenção de dados (por exemplo, history.persistence / history.max_bytes) se não quiser que o Codex salve transcrições das sessões em CODEX_HOME. Consulte Configuração avançada e Referência de configuração.
• Se você executar a CLI com o acesso à rede desativado, a exportação OTel não conseguirá alcançar seu coletor. Para exportar, permita o acesso à rede no modo workspace-write para o endpoint OTel ou exporte a partir do Codex Cloud com o domínio do coletor na sua lista de permissões.
• Revise os eventos periodicamente para identificar mudanças nas aprovações ou no sandbox e execuções inesperadas de ferramentas.

O OTel é opcional e foi projetado para complementar, e não substituir, as proteções de sandbox e aprovação descritas acima.

Configuração gerenciada

Administradores de empresas podem ajustar as configurações de segurança do Codex para seu workspace em Configuração gerenciada. Consulte essa página para obter detalhes sobre configuração e políticas.