Aprobaciones del agente y seguridad

Codex ayuda a proteger tu código y tus datos, y reduce el riesgo de uso indebido.

De forma predeterminada, el agente se ejecuta con el acceso a la red desactivado. De manera local, Codex usa un sandbox cuyas restricciones aplica el sistema operativo para limitar aquello a lo que puede acceder (normalmente, al espacio de trabajo actual), además de una política de aprobación que determina cuándo debe detenerse y consultarte antes de actuar.

Para obtener una explicación general de cómo funciona el entorno aislado en la aplicación de escritorio de ChatGPT, Codex CLI y la extensión para IDE, consulta Entorno aislado. Para obtener una descripción más amplia de la seguridad empresarial, consulta el documento técnico sobre la seguridad de Codex.

Migrar desde la política de aprobación retirada untrusted

Codex y ChatGPT Work ya no admiten approval_policy = "untrusted". Esta configuración retirada puede impedir que cualquiera de los dos clientes se inicie. Elimínala de la configuración de usuario o proyecto, los archivos de perfil, los scripts de inicio y los valores predeterminados administrados. Para un uso interactivo de solo lectura:

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

O ejecuta codex --sandbox read-only --ask-for-approval on-request.

Con on-request, los comandos permitidos por el sandbox pueden ejecutarse sin aprobación, leer archivos accesibles y usar el acceso a la red si está habilitado.

Para conservar la regla más estricta de aprobación de comandos, omite la configuración explícita de approval_policy y agrega una entrada de proyecto a tu archivo de configuración de usuario ~/.codex/config.toml:

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

Así, los comandos requieren aprobación, a menos que una regla de la política de ejecución los permita. Esto también deshabilita la configuración local del proyecto. Establecer explícitamente on-request anula la política derivada del proyecto; la configuración administrada allowed_approval_policies debe incluir untrusted para permitir esa política.

Sandbox y aprobaciones

Los controles de seguridad de Codex se basan en dos capas que funcionan juntas:

• Modo de sandbox: lo que Codex puede hacer técnicamente (por ejemplo, dónde puede escribir y si puede acceder a la red) al ejecutar comandos generados por el modelo.
• Política de aprobación: cuándo Codex debe consultarte antes de ejecutar una acción (por ejemplo, salir del sandbox, usar la red o ejecutar comandos fuera de un conjunto de confianza).

Codex usa distintos modos de sandbox según dónde lo ejecutes:

• Codex Cloud: se ejecuta en contenedores aislados administrados por OpenAI, lo que impide el acceso a tu sistema host o a datos ajenos a la tarea. Usa un modelo de ejecución de dos fases: la configuración se ejecuta antes de la fase del agente y puede acceder a la red para instalar las dependencias especificadas; luego, la fase del agente se ejecuta sin conexión de forma predeterminada, a menos que habilites el acceso a Internet para ese entorno. Los secretos configurados para los entornos en la nube están disponibles solo durante la configuración y se eliminan antes de que comience la fase del agente.
• Codex CLI / extensión para IDE: las políticas del sandbox se aplican mediante mecanismos del sistema operativo. De forma predeterminada, el acceso a la red está desactivado y los permisos de escritura se limitan al espacio de trabajo activo. Puedes configurar el sandbox, la política de aprobación y los ajustes de red según tu tolerancia al riesgo.

Con la configuración preestablecida Auto (por ejemplo, --sandbox workspace-write --ask-for-approval on-request), Codex puede leer archivos, hacer cambios y ejecutar comandos en el directorio de trabajo automáticamente.

Codex solicita aprobación para editar archivos fuera del espacio de trabajo o ejecutar comandos que requieren acceso a la red. Si quieres conversar o planificar sin hacer cambios, pasa al modo read-only con el comando /permissions.

Codex también puede solicitar aprobación para llamadas a herramientas de apps (conectores) que declaren efectos secundarios, incluso cuando la acción no sea un comando de shell ni un cambio en un archivo. Las llamadas destructivas a herramientas de apps/MCP siempre requieren aprobación cuando la herramienta declara una anotación de acción destructiva (a menos que declare una anotación de lectura, que tiene prioridad).

Monitoreo de seguridad y tareas en pausa

GPT-6 Astra incluye monitoreo de seguridad en Codex y ChatGPT Work. El monitoreo se ejecuta de forma asíncrona y puede pausar una tarea si detecta un comportamiento del modelo potencialmente inseguro. La pausa puede ocurrir después de la actividad que la desencadenó; el monitoreo no reemplaza el entorno aislado, los permisos ni la revisión del resultado.

Si una tarea se pausa, lee el aviso y revisa los hallazgos cuando estén disponibles. Reanúdala solo después de comprobar que puede continuar de forma segura. Si el aviso indica que la tarea terminó o no ofrece una opción para reanudarla, no puedes hacerlo desde esa interfaz.

El monitoreo de seguridad evalúa el comportamiento del modelo durante una tarea. La revisión automática de aprobaciones evalúa, antes de su ejecución, las acciones individuales que ya requieren aprobación. Una acción aprobada por la revisión automática de aprobaciones puede formar parte de una tarea que el monitoreo pause más adelante.

Acceso a la red Elevated Risk

Para Codex Cloud, consulta Acceso a Internet del agente para habilitar el acceso completo a Internet o una lista de dominios permitidos.

En la aplicación de escritorio de ChatGPT, Codex CLI o la extensión para IDE, el modo de sandbox predeterminado workspace-write mantiene el acceso a la red desactivado, a menos que lo habilites en tu configuración:

[sandbox_workspace_write]
network_access = true

Aislamiento de red

El acceso a la red se controla mediante reglas de destino que se aplican a scripts, programas y subprocesos iniciados por los comandos. Cuando el acceso a la red de los comandos ya esté habilitado, activa la función network_proxy para limitar ese tráfico según la política de red que configures. Agregar reglas de dominio no habilita el proxy por sí solo.

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

Para una sesión puntual de CLI, usa la forma booleana abreviada si solo necesitas activar o desactivar la función, y el formato de tabla si también vas a establecer opciones de la 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'

La función cambia cómo se controla el acceso a la red cuando está habilitado; no otorga acceso a la red por sí sola. Usa sandbox_workspace_write.network_access con la configuración workspace-write para decidir si los comandos tienen acceso a la red:

• Red desactivada + network_proxy activado: la red permanece desactivada y la función no hace nada.
• Red activada + network_proxy desactivado: la red permanece activada con acceso directo de salida sin restricciones.
• Red activada + network_proxy activado: la red permanece activada y el tráfico saliente se restringe según la política de red configurada.

La función de proxy también se aplica a los perfiles de permisos. La opción network.enabled = true de un perfil otorga acceso a la red a los comandos, mientras que features.network_proxy = true activa la aplicación de las reglas de dominio de ese 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"

Si omites la función de proxy en este ejemplo, los comandos tienen acceso directo a la red y la regla que permite api.openai.com no restringe sus destinos.

Los requisitos de experimental_network administrados son independientes del control del usuario para activar la función. Pueden configurar e iniciar la conectividad de red en el sandbox sin features.network_proxy, pero no activan el acceso a la red cuando el sandbox activo lo mantiene desactivado. Consulta Configuración administrada para conocer la estructura de requirements.toml que usan los administradores.

Política de red

Las reglas de dominio se basan en una lista de permitidos:

• Los hosts exactos solo coinciden consigo mismos.
• *.example.com coincide con subdominios como api.example.com, pero no con example.com.
• **.example.com coincide tanto con el dominio raíz como con los subdominios.
• Una regla global de permiso * coincide con cualquier host público que no esté denegado. Considera * como un acceso amplio a la red y usa reglas de alcance limitado siempre que puedas.
• deny siempre tiene prioridad sobre allow, y el comodín global * solo es válido en reglas de permiso.

Destinos locales y privados

De forma predeterminada, allow_local_binding = false bloquea los destinos de loopback, de enlace local y privados:

• Excepciones específicas: agrega una regla que permita una dirección IP local literal exacta o localhost cuando un comando necesite un destino local.
• Acceso más amplio: establece allow_local_binding = true solo cuando quieras permitir deliberadamente un acceso más amplio a destinos locales o privados.
• Comodines: las reglas con comodines no cuentan como excepciones locales explícitas.
• Direcciones resueltas: los nombres de host que se resuelven en IP locales o privadas permanecen bloqueados, incluso si coinciden con la lista de permitidos.

Protecciones contra DNS rebinding

Antes de permitir un nombre de host, Codex hace lo posible por verificar el DNS y la clasificación de las direcciones IP:

• Las consultas que fallan o superan el tiempo de espera se bloquean.
• Los nombres de host que se resuelven en direcciones no públicas se bloquean.
• La comprobación reduce el riesgo de DNS rebinding, pero no lo elimina. Para evitarlo por completo, sería necesario fijar las direcciones IP resueltas hasta la capa de transporte.

Si el DNS malicioso forma parte de las amenazas contempladas, aplica también controles de tráfico saliente en una capa inferior.

Configuraciones peligrosas

Dos opciones de configuración amplían deliberadamente el límite de confianza:

• dangerously_allow_non_loopback_proxy = true puede exponer los puntos de escucha del proxy fuera de loopback.
• dangerously_allow_all_unix_sockets = true omite la lista de sockets Unix permitidos.

Úsalas solo en entornos estrictamente controlados. Cuando se habilita el proxy de sockets Unix, los puntos de escucha se mantienen limitados a loopback, incluso si se solicitó vincularlos a otras direcciones, para que la red del sandbox no se convierta en un puente remoto hacia los daemons locales.

network_proxy está desactivado de forma predeterminada. Cuando lo habilitas:

Tráfico fuera del proxy de red de comandos

El proxy de red filtra los scripts, programas y procesos secundarios que se ejecutan dentro del sandbox local de comandos. No filtra la búsqueda web, las llamadas a herramientas de apps o conectores, las conexiones a servidores MCP, la actividad del navegador o de Uso de la computadora, las tareas de Codex Cloud ni las solicitudes del cliente al modelo y de autenticación. Estas superficies usan conexiones a servicios, configuraciones de funciones, políticas del espacio de trabajo o controles del entorno independientes.

Las herramientas del navegador comprueban por separado las reglas administradas de denegación de red y las listas exclusivas de destinos permitidos antes de acceder a un origen. Las políticas de origen del navegador pueden restringir aún más el acceso a sitios, las cargas, las descargas y las herramientas de desarrollo. Consulta Controles administrados del navegador.

Para los usuarios administrados, combina la política de red de comandos con controles como allowed_web_search_modes, los mcp_servers aprobados y los requisitos de funciones para apps, complementos, navegadores o Uso de la computadora. Consulta Configuración administrada.

También puedes controlar la herramienta de búsqueda web sin otorgar acceso completo a la red a los comandos que se ejecuten. De forma predeterminada, Codex usa una caché de búsqueda web para acceder a los resultados. La caché es un índice de resultados web que mantiene OpenAI, por lo que el modo de caché devuelve resultados previamente indexados en lugar de obtener páginas en vivo. Esto reduce la exposición a la inyección de prompts procedente de contenido arbitrario en vivo, pero debes seguir tratando los resultados web como no confiables. Si usas --yolo u otra configuración de sandbox con acceso completo, la búsqueda web usa resultados en vivo de forma predeterminada. Usa --search o establece web_search = "live" para permitir la navegación en vivo, o establece el valor en "disabled" para desactivar la herramienta:

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

Establece web_search = "indexed" cuando el acceso a la web externa deba estar limitado por el índice de búsqueda. Ten cuidado al habilitar el acceso a la red o la búsqueda web en Codex. La inyección de prompts puede hacer que el agente obtenga y siga instrucciones no confiables.

Valores predeterminados y recomendaciones

• Al iniciarse, Codex detecta si la carpeta está bajo control de versiones y recomienda:
  • Carpetas bajo control de versiones: Auto (escritura en el espacio de trabajo + aprobaciones cuando se soliciten)
  • Carpetas sin control de versiones: read-only
• Según tu configuración, Codex también puede iniciarse en read-only hasta que marques explícitamente el directorio de trabajo como confiable (por ejemplo, mediante un mensaje de configuración inicial o /permissions).
• El espacio de trabajo incluye el directorio actual y directorios temporales como /tmp. Usa el comando /status para ver qué directorios forman parte del espacio de trabajo.
• Para aceptar los valores predeterminados, ejecuta codex.
• Puedes establecerlos explícitamente:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Rutas protegidas en directorios raíz con permiso de escritura

En la política predeterminada de sandbox workspace-write, los directorios raíz con permiso de escritura siguen incluyendo rutas protegidas:

• <writable_root>/.git está protegido como de solo lectura, tanto si es un directorio como si es un archivo.
• Si <writable_root>/.git es un archivo de referencia (gitdir: ...), la ruta del directorio Git a la que apunta también está protegida como de solo lectura.
• <writable_root>/.agents está protegido como de solo lectura cuando existe como directorio.
• <writable_root>/.codex está protegido como de solo lectura cuando existe como directorio.
• La protección es recursiva, por lo que todo el contenido de esas rutas es de solo lectura.

Ejecutar sin solicitudes de aprobación

Puedes desactivar las solicitudes de aprobación con --ask-for-approval never o -a never (forma abreviada).

Esta opción funciona con todos los modos de --sandbox, por lo que sigues controlando el nivel de autonomía de Codex. Codex hace lo posible dentro de las restricciones que establezcas.

Si necesitas que Codex lea archivos, haga cambios y ejecute comandos con acceso a la red sin solicitudes de aprobación, usa --sandbox danger-full-access (o el indicador --dangerously-bypass-approvals-and-sandbox). Ten cuidado antes de hacerlo.

Como opción intermedia, approval_policy = { granular = { ... } } te permite mantener interactivas ciertas categorías de solicitudes de aprobación y rechazar otras automáticamente. La política granular abarca las aprobaciones del sandbox, las solicitudes de reglas execpolicy, las solicitudes de MCP, las solicitudes de request_permissions y las aprobaciones de scripts de habilidades.

Revisiones automáticas de aprobación

De forma predeterminada, las solicitudes de aprobación se te envían a ti:

approvals_reviewer = "user"

Las revisiones automáticas de aprobación se aplican cuando las aprobaciones son interactivas, como con approval_policy = "on-request" o una política de aprobación granular. Establece approvals_reviewer = "auto_review" para enviar las solicitudes de aprobación que cumplan los requisitos a un agente revisor antes de que Codex ejecute lo solicitado:

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

Para conocer el ciclo de vida completo del revisor, las condiciones de activación, la precedencia de la configuración y el comportamiento ante fallas, consulta Revisión automática.

El revisor evalúa únicamente las acciones que ya requieren aprobación, como las elevaciones de permisos fuera del sandbox, las solicitudes de red bloqueadas, las solicitudes de request_permissions o las llamadas a herramientas de apps y MCP con efectos secundarios. Las acciones que se mantienen dentro del sandbox continúan sin un paso adicional de revisión.

La política del revisor comprueba si hay exfiltración de datos, sondeo de credenciales, debilitamiento persistente de la seguridad y acciones destructivas. Las acciones de riesgo bajo y medio pueden continuar cuando la política lo permite. La política deniega las acciones de riesgo crítico. Las acciones de alto riesgo requieren suficiente autorización del usuario y que no coincidan con ninguna regla de denegación. Las fallas al construir el prompt, durante la sesión de revisión o al analizar la respuesta bloquean la acción. Los tiempos de espera agotados se muestran por separado, pero la acción tampoco se ejecuta.

La política predeterminada del revisor está en el repositorio de código abierto de Codex. Las empresas pueden reemplazar su sección específica del tenant con guardian_policy_config en los requisitos administrados. También se admite texto local en [auto_review].policy, pero los requisitos administrados tienen prioridad. Para obtener detalles de configuración, consulta Configuración administrada.

En la aplicación de escritorio de ChatGPT, estas revisiones aparecen como elementos de revisión automática con un estado como En revisión, Aprobada, Denegada, Cancelada o Tiempo de espera agotado. También pueden incluir un nivel de riesgo y una evaluación de la autorización del usuario para la solicitud revisada.

La revisión automática realiza llamadas adicionales al modelo, por lo que puede aumentar el uso de Codex. Los administradores pueden restringirla con allowed_approvals_reviewers.

Combinaciones comunes de sandbox y aprobación

Para ejecuciones sin interacción, usa codex exec --sandbox workspace-write; Codex conserva las invocaciones antiguas de codex exec --full-auto como una opción de compatibilidad obsoleta y muestra una advertencia.

Configuración en config.toml

Para conocer el flujo de configuración más amplio, consulta Configuración básica, Configuración avanzada y la Referencia de configuración.

# 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
# } }

También puedes guardar configuraciones predefinidas como archivos de perfil y luego seleccionarlas con 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"

Probar el sandbox localmente

Para ver qué sucede cuando un comando se ejecuta dentro del sandbox de Codex, usa estos comandos de 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]...

El comando sandbox también está disponible como codex debug, y las herramientas auxiliares de cada plataforma tienen alias (por ejemplo, codex sandbox seatbelt y codex sandbox landlock).

Sandbox a nivel del sistema operativo

Codex aplica las restricciones del sandbox de distintas maneras según tu sistema operativo:

• macOS usa políticas de Seatbelt y ejecuta comandos mediante sandbox-exec con un perfil (-p) que corresponde al modo --sandbox que seleccionaste. Cuando el acceso de lectura restringido habilita los valores predeterminados de la plataforma, Codex agrega una política de plataforma macOS cuidadosamente seleccionada (en lugar de permitir el acceso general a /System) para mantener la compatibilidad con herramientas comunes.
• Linux usa bwrap junto con seccomp de forma predeterminada.
• Windows usa la implementación del sandbox de Linux cuando se ejecuta en el Subsistema de Windows para Linux 2 (WSL2). WSL1 fue compatible hasta Codex 0.114; a partir de 0.115, el sandbox de Linux pasó a usar bwrap, por lo que WSL1 ya no es compatible. Cuando se ejecuta de forma nativa en Windows, Codex usa una implementación del sandbox de Windows.

Si usas la extensión de Codex para IDE en Windows, esta admite WSL2 directamente. Agrega lo siguiente a la configuración de VS Code para mantener al agente dentro de WSL2 siempre que esté disponible:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Esto garantiza que la extensión para IDE herede el comportamiento del sandbox de Linux para los comandos, las aprobaciones y el acceso al sistema de archivos, incluso cuando el sistema operativo del host sea Windows. Obtén más información en la guía de WSL.

Cuando ejecutes Codex de forma nativa en Windows, configura el modo de sandbox nativo en config.toml:

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

Consulta la guía de configuración de Windows para obtener más detalles.

Cuando ejecutas Linux en un entorno de contenedores como Docker, el sandbox puede no funcionar si la configuración del host o del contenedor bloquea las operaciones de espacios de nombres, de bwrap con setuid o de seccomp que Codex necesita.

En ese caso, configura tu contenedor de Docker para que proporcione el aislamiento que necesitas y luego ejecuta codex con --sandbox danger-full-access (o con el indicador --dangerously-bypass-approvals-and-sandbox) dentro del contenedor.

Ejecutar Codex en Dev Containers

Si tu host no puede ejecutar el sandbox de Linux directamente, o si tu organización ya usa el desarrollo en contenedores como estándar, ejecuta Codex con Dev Containers y deja que Docker proporcione el límite externo de aislamiento. Esto funciona con Visual Studio Code Dev Containers y herramientas compatibles.

Usa el ejemplo de devcontainer seguro de Codex como implementación de referencia. El ejemplo instala Codex, herramientas de desarrollo comunes, bubblewrap y controles de tráfico saliente basados en un firewall.

La implementación de referencia incluye:

• una imagen base de Ubuntu 24.04 con Codex y herramientas de desarrollo comunes instaladas;
• un perfil de firewall basado en una lista de permitidos para el acceso saliente;
• configuración de VS Code y recomendaciones de extensiones para volver a abrir el espacio de trabajo en un contenedor;
• montajes persistentes para el historial de comandos y la configuración de Codex;
• bubblewrap, para que Codex pueda seguir usando su sandbox de Linux cuando el contenedor otorgue las capacidades necesarias.

Para probarlo:

1. Instala Visual Studio Code y la extensión Dev Containers.
2. Copia la configuración de ejemplo de .devcontainer de Codex en tu repositorio o empieza directamente desde el repositorio de Codex.
3. En VS Code, ejecuta Dev Containers: Open Folder in Container... y selecciona .devcontainer/devcontainer.secure.json.
4. Una vez que se inicie el contenedor, abre una terminal y ejecuta codex.

También puedes iniciar el contenedor desde la CLI:

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

El ejemplo tiene tres componentes principales:

• .devcontainer/devcontainer.secure.json controla la configuración del contenedor, las capacidades, los montajes, las variables de entorno y las extensiones de VS Code.
• .devcontainer/Dockerfile.secure define la imagen basada en Ubuntu y las herramientas instaladas.
• .devcontainer/init-firewall.sh aplica la política de tráfico de red saliente.

El firewall de referencia está pensado como punto de partida. Si dependes de una lista de dominios permitidos para el aislamiento, implementa protecciones contra la revinculación de DNS y para la actualización de DNS que se adapten a tu entorno, como actualizaciones que tengan en cuenta el TTL o un firewall que tenga en cuenta el DNS.

Dentro del contenedor, elige uno de estos modos:

• Mantén habilitado el sandbox de Linux de Codex si el perfil de Dev Container otorga las capacidades necesarias para que bwrap cree el sandbox interno.
• Si el contenedor es el límite de seguridad que quieres usar, ejecuta Codex con --sandbox danger-full-access dentro del contenedor para que Codex no intente crear una segunda capa de sandbox.

Control de versiones

Codex funciona mejor con un flujo de trabajo que use control de versiones:

• Trabaja en una rama de funcionalidad y asegúrate de que git status no muestre cambios pendientes antes de delegar. Así será más fácil aislar y revertir los parches de Codex.
• Prioriza los flujos de trabajo basados en parches (por ejemplo, git diff/git apply) en lugar de editar directamente los archivos bajo control de versiones. Haz commits con frecuencia para poder revertir los cambios en pequeños pasos.
• Trata las sugerencias de Codex como cualquier otro PR: realiza verificaciones específicas, revisa las diferencias y documenta las decisiones en los mensajes de commit para facilitar las auditorías.

Monitoreo y telemetría

Codex admite el monitoreo opcional mediante OpenTelemetry (OTel) para ayudar a los equipos a auditar el uso, investigar problemas y cumplir los requisitos de cumplimiento sin debilitar la configuración de seguridad local predeterminada. La telemetría está desactivada de forma predeterminada; habilítala explícitamente en tu configuración.

Descripción general

• Codex desactiva la exportación de OTel de forma predeterminada para que las ejecuciones locales sean autónomas.
• Cuando se habilita, Codex emite eventos de registro estructurados que abarcan chats, solicitudes a la API, actividad de flujos SSE/WebSocket, prompts del usuario (con el contenido oculto de forma predeterminada), decisiones de aprobación de herramientas y resultados de herramientas.
• Codex etiqueta los eventos exportados con service.name (origen), la versión de la CLI y una etiqueta de entorno para separar el tráfico de desarrollo, preproducción y producción.

Habilitar OTel (opcional)

Agrega un bloque [otel] a tu configuración de Codex (normalmente en ~/.codex/config.toml), elige un exportador y decide si quieres registrar el texto de los prompts.

[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" mantiene activa la instrumentación, pero no envía datos a ningún destino.
• Para enviar eventos a tu propio recolector, elige una de estas opciones:

[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" }
}}

Codex agrupa los eventos en lotes y los envía al cerrarse. Codex exporta únicamente la telemetría que produce su módulo OTel.

Categorías de eventos

Algunos tipos de eventos representativos son:

• codex.conversation_starts (modelo, ajustes de razonamiento, política de sandbox/aprobación)
• codex.api_request (intento, estado/éxito, duración y detalles del error)
• codex.sse_event (tipo de evento del flujo, éxito/fallo, duración y conteos de tokens en response.completed)
• codex.websocket_request y codex.websocket_event (duración de la solicitud y tipo/éxito/error por mensaje)
• codex.user_prompt (longitud; el contenido se oculta a menos que se habilite explícitamente su registro)
• codex.tool_decision (aprobado/denegado, origen: configuración o usuario)
• codex.tool_result (duración, éxito, fragmento de la salida)

Las métricas de OTel asociadas (pares de contador e histograma de duración) incluyen codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event y codex.tool.call (con sus correspondientes instrumentos .duration_ms).

Para consultar el catálogo completo de eventos y la referencia de configuración, ve la documentación de configuración de Codex en GitHub.

Recomendaciones de seguridad y privacidad

• Mantén log_user_prompt = false a menos que la política permita explícitamente almacenar el contenido de los prompts. Los prompts pueden incluir código fuente y datos sensibles.
• Envía la telemetría únicamente a recolectores que controles; aplica límites de retención y controles de acceso acordes con tus requisitos de cumplimiento.
• Trata los argumentos y las salidas de las herramientas como información sensible. Siempre que sea posible, opta por ocultar los datos sensibles en el recolector o en el SIEM.
• Revisa los ajustes de retención de datos locales (por ejemplo, history.persistence / history.max_bytes) si no quieres que Codex guarde transcripciones de las sesiones en CODEX_HOME. Consulta Configuración avanzada y Referencia de configuración.
• Si ejecutas la CLI con el acceso a la red desactivado, la exportación de OTel no puede llegar a tu recolector. Para exportar, permite el acceso a la red en el modo workspace-write para el punto de acceso de OTel, o exporta desde Codex Cloud con el dominio del recolector en tu lista de dominios permitidos.
• Revisa los eventos periódicamente para detectar cambios en las aprobaciones o el sandbox y ejecuciones inesperadas de herramientas.

OTel es opcional y está diseñado para complementar, no reemplazar, las protecciones de sandbox y aprobación descritas anteriormente.

Configuración administrada

Los administradores de empresas pueden configurar los ajustes de seguridad de Codex para su espacio de trabajo en Configuración administrada. Consulta esa página para conocer los detalles de configuración y las políticas.