Aprobaciones y seguridad del agente

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. En tu computadora, Codex usa un sandbox cuyo aislamiento impone el sistema operativo. El sandbox limita los recursos a los que puede acceder Codex, por lo general al espacio de trabajo actual. Una política de aprobación determina cuándo Codex debe detenerse y pedirte permiso antes de actuar.

Para conocer en términos generales cómo funciona el aislamiento en la app de escritorio de ChatGPT, la CLI de Codex 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 untrusted retirada

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

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

También puedes ejecutar codex --sandbox read-only --ask-for-approval on-request.

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

Para conservar la regla más estricta de aprobación de comandos, omite el ajuste explícito de approval_policy y agrega una entrada para el proyecto en 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. Si estableces on-request de forma explícita, ese valor prevalece sobre la política derivada del proyecto. Para permitir la política derivada, el ajuste administrado allowed_approval_policies debe incluir untrusted.

Sandbox y aprobaciones

El acceso a la computadora local con Work Cloud tiene políticas de ejecución distintas para el entorno local y la nube:

• Ejecución en la nube: los contenedores de Work en la nube usan las políticas existentes de Work Cloud.
• Ejecución local: los requisitos de ejecución local rigen en la computadora conectada. Los requisitos de MDM y los requisitos heredados para dispositivos administrados tienen prioridad sobre los de Agent Security, que a su vez prevalecen sobre el archivo de requisitos del sistema del dispositivo.

Para el modo Work con acceso local y para los dots, las políticas compatibles de Global se aplican al orquestador compartido en la nube cuando la política administrada está habilitada. Los contenedores de Work en la nube y las computadoras en la nube de los dots tienen sus propios requisitos y configuraciones de ejecución. Prueba por separado los controles locales y los de la nube. Mantén en Global los controles del orquestador, incluidas las aprobaciones y la búsqueda web. Si están disponibles, usa los controles específicos para las políticas de aprobación permitidas y los modos de búsqueda web permitidos. Usa TOML para los demás campos compatibles. Antes de aplicar un ejemplo de Codex al acceso a la computadora local con Work Cloud, consulta la lista de campos y su ámbito de ejecución en la referencia de configuración.

Cambiar entre la app de escritorio, la web y la app móvil no te da acceso a otra computadora. Antes de habilitar la sincronización o ampliar el acceso, revisa la configuración base de Agent Security y prueba una acción permitida y otra bloqueada en cada entorno de ejecución. Consulta Configuración administrada.

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

• Modo de sandbox: determina qué puede hacer Codex a nivel técnico cuando ejecuta comandos generados por el modelo. Por ejemplo, establece dónde puede escribir y si puede acceder a la red.
• Política de aprobación: determina cuándo Codex debe pedirte permiso antes de realizar una acción, como salir del sandbox, usar la red o ejecutar comandos que no pertenecen a un conjunto de confianza.

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

• Codex Cloud (versión anterior): se ejecuta en contenedores aislados que administra OpenAI, lo que impide el acceso al sistema host y a datos ajenos a la tarea. La ejecución consta de dos fases. La fase de preparació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 solo están disponibles durante la preparación y se eliminan antes de que comience la fase del agente.
• Versión actual de Codex Cloud: consulta Variables de entorno y secretos de red para conocer cómo se manejan las credenciales durante la preparación y la ejecución de tareas.
• CLI de Codex y extensión para IDE: los mecanismos del sistema operativo hacen cumplir las políticas del sandbox. 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 el ajuste preestablecido Auto (por ejemplo, --sandbox workspace-write --ask-for-approval on-request), Codex puede leer archivos, hacer cambios y ejecutar comandos automáticamente en el directorio de trabajo.

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, cambia al modo read-only con el comando /permissions.

Codex también puede solicitar aprobación para las llamadas a herramientas de apps (conectores) que declaran efectos secundarios, incluso si la acción no es un comando de shell ni modifica un archivo. Las llamadas destructivas a herramientas de apps o de MCP siempre requieren aprobación cuando la herramienta declara una anotación de operación destructiva, salvo que también 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 potencialmente inseguro del modelo. La pausa puede producirse después de la actividad que la desencadenó. El monitoreo no sustituye 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. Reanuda la tarea solo después de comprobar que puede continuar de forma segura. Si el aviso indica que la tarea terminó o no ofrece la opción de reanudarla, no podrás reanudarla 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 las acciones individuales que ya requieren aprobación antes de que se ejecuten. Una acción aprobada por la revisión automática puede formar parte de una tarea que el monitoreo pause más adelante.

Acceso a la red Elevated Risk

Para conocer los ajustes de red de la versión actual de Codex Cloud, consulta Conectarse a servicios. Para habilitar el acceso completo a internet o una lista de dominios permitidos en la versión anterior de Codex Cloud, consulta Acceso del agente a internet.

En la app de escritorio de ChatGPT, la CLI de Codex y 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 la configuración:

[sandbox_workspace_write]
network_access = true

Aislamiento de red

En las vías de ejecución administradas de Codex Cloud que admiten esta función, los requisitos de Agent Security restringen el acceso de los comandos a la red. Los ajustes de internet del entorno de Codex Cloud se aplican por separado. Permitir un dominio en Agent Security no anula una restricción de los ajustes de internet del entorno en la nube. Por sí solos, estos controles de red para comandos no deshabilitan la búsqueda web alojada, las apps ni MCP. ChatGPT Work Cloud tiene permisos independientes para sus funciones y no hereda estos requisitos de Agent Security.

La lista administrada de destinos permitidos para comandos se aplica a los comandos que usan el proxy administrado. Si la política permite elevar los permisos para salir por completo del sandbox y se aprueba la solicitud, esa ejecución puede eludir el proxy de comandos. Conceder acceso limitado a la red es distinto de elevar por completo los permisos del sandbox. Configura los requisitos obligatorios de aprobación y de sandbox según los límites que quieras imponer y prueba comandos tanto con permisos normales como elevados. Consulta Configuración administrada.

El acceso a la red se controla mediante reglas de destino que se aplican a los scripts, programas y subprocesos que inician los comandos. Si los comandos ya tienen acceso a la red, 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 la CLI, usa la forma booleana abreviada si solo necesitas activar o desactivar la función. Usa la forma de tabla si también necesitas definir 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 la forma en que se controla el acceso a la red cuando está habilitado. Por sí sola, no concede acceso. Usa sandbox_workspace_write.network_access en la configuración de workspace-write para decidir si los comandos tienen acceso a la red:

• Red desactivada y network_proxy activado: la red sigue desactivada y la función no tiene efecto.
• Red activada y network_proxy desactivado: la red sigue activada, con acceso directo de salida sin restricciones.
• Red activada y network_proxy activado: la red sigue activada y la política de red configurada limita el tráfico saliente.

La función de proxy también se aplica a los perfiles de permisos. En un perfil, network.enabled = true concede 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 que define el administrador son independientes del ajuste que usa el usuario para activar la función. Estos requisitos permiten configurar e iniciar la conexión de red del sandbox sin features.network_proxy, pero no activan el acceso a la red si el sandbox activo lo mantiene desactivado. Consulta Configuración administrada para conocer la estructura del archivo requirements.toml que usa el administrador.

Política de red

Las reglas de dominio parten de una lista de destinos permitidos:

• Un nombre de host exacto solo coincide con ese mismo host.
• *.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 sus subdominios.
• Una regla global que permite * coincide con cualquier host público que no esté bloqueado. Considera * como un permiso de acceso amplio a la red y usa reglas de alcance limitado siempre que puedas.
• deny siempre prevalece sobre allow y el comodín global * solo es válido en reglas que permiten el acceso.

Destinos locales y privados

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

• Excepciones específicas: si un comando necesita acceder a un solo destino local, agrega una regla que permita la dirección IP local exacta en forma literal o localhost.
• Acceso más amplio: establece allow_local_binding = true solo si quieres ampliar deliberadamente el acceso 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 direcciones IP locales o privadas siguen bloqueados aunque coincidan con la lista de destinos permitidos.

Protección contra la revinculación de DNS

Antes de permitir un nombre de host, Codex intenta verificar la resolución DNS y la clasificación de las direcciones IP:

• Se bloquean las consultas que fallan o superan el tiempo de espera.
• Se bloquean los nombres de host que se resuelven en direcciones no públicas.
• La verificación reduce el riesgo de revinculación de DNS, pero no lo elimina. Para impedir por completo la revinculación, sería necesario mantener fijas las direcciones IP resueltas hasta la capa de transporte.

Si tu modelo de amenazas incluye servidores DNS hostiles, aplica también controles de tráfico saliente en una capa inferior.

Ajustes peligrosos

Dos ajustes amplían deliberadamente el límite de confianza:

• dangerously_allow_non_loopback_proxy = true puede hacer que los servicios de escucha del proxy sean accesibles fuera de la interfaz de loopback.
• dangerously_allow_all_unix_sockets = true omite la lista de sockets Unix permitidos.

Úsalos solo en entornos estrictamente controlados. Cuando se habilita el proxy para sockets Unix, los servicios siguen escuchando solo en la interfaz de loopback, incluso si se solicitó usar otra interfaz. Así, la conexión de red del sandbox no se convierte en un puente de acceso remoto a los demonios locales.

network_proxy está desactivado de forma predeterminada. Al habilitarlo, se aplican los siguientes ajustes:

Tráfico que no pasa por el proxy de red de comandos

El proxy de red filtra el tráfico de los scripts, programas y procesos secundarios que se ejecutan dentro del sandbox local de comandos. No filtra las búsquedas 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 en la nube ni las solicitudes del cliente al modelo o al servicio de autenticación. Estas funciones usan conexiones de servicio, ajustes, políticas del espacio de trabajo o controles del entorno independientes.

Antes de acceder a un origen, las herramientas del navegador verifican por separado las reglas administradas de denegación de acceso a la red y las listas exclusivas de destinos permitidos. Las políticas de origen del navegador pueden imponer restricciones adicionales al acceso a sitios, las cargas, las descargas y las herramientas para desarrolladores. Consulta Controles administrados del navegador.

Para 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 conceder acceso completo a la red a los comandos que se inician. 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. En el modo de caché, Codex devuelve resultados ya indexados en lugar de consultar páginas en tiempo real. Esto reduce la exposición a la inyección de prompts desde contenido arbitrario consultado en tiempo real. Trata los resultados web como datos que no son de confianza. Si usas --yolo u otro ajuste de sandbox con acceso completo, la búsqueda web devuelve resultados en tiempo real de forma predeterminada. Usa --search o establece web_search = "live" para permitir la navegación en tiempo real, o usa el valor "disabled" para desactivar la herramienta:

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

Establece web_search = "indexed" si el índice de búsqueda debe controlar el acceso a la web externa. 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 que no son de confianza.

Valores predeterminados y recomendaciones

• Al iniciarse, Codex detecta si la carpeta está bajo control de versiones y recomienda lo siguiente:
  • Carpetas bajo control de versiones: Auto (escritura en el espacio de trabajo y aprobaciones a solicitud).
  • Carpetas sin control de versiones: read-only.
• Según tu configuración, Codex también puede iniciarse en modo read-only hasta que marques explícitamente el directorio de trabajo como de confianza, por ejemplo, durante la configuración inicial o mediante /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 establecer estos ajustes de forma explícita:
  • 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

Con la política predeterminada del sandbox workspace-write, los directorios raíz con permiso de escritura también contienen rutas protegidas:

• <writable_root>/.git está protegido como recurso de solo lectura, ya sea un directorio o un archivo.
• Si <writable_root>/.git es un archivo que apunta a otra ubicación (gitdir: ...), la ruta del directorio de Git al que apunta también queda protegida como de solo lectura.
• <writable_root>/.agents está protegido como recurso de solo lectura cuando existe como directorio.
• <writable_root>/.codex está protegido como recurso de solo lectura cuando existe como directorio.
• <writable_root>/.aws está protegido como recurso 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 Codex sin solicitudes de aprobación

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

Esta opción funciona con todos los modos de --sandbox, así que sigues controlando el nivel de autonomía de Codex. Codex intenta completar la tarea dentro de los límites que estableces.

Si necesitas que Codex lea archivos, haga cambios y ejecute comandos con acceso a la red sin pedir aprobación, usa --sandbox danger-full-access (o la opción --dangerously-bypass-approvals-and-sandbox). Evalúa los riesgos antes de hacerlo.

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

Revisión automática de solicitudes de aprobación

De forma predeterminada, tú recibes las solicitudes de aprobación:

approvals_reviewer = "user"

La función Revisión automática se aplica cuando las aprobaciones son interactivas, como ocurre con approval_policy = "on-request" o con una política de aprobación granular. Establece approvals_reviewer = "auto_review" para que un agente revisor evalúe las solicitudes de aprobación que cumplan los requisitos antes de que Codex ejecute la acción.

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

Para conocer el ciclo de vida completo del revisor, las condiciones que activan la revisión, la prioridad de los ajustes y el comportamiento ante fallos, consulta Revisión automática.

El revisor solo evalúa acciones que ya requieren aprobación, como la elevación de permisos del sandbox, las solicitudes de red que requieren aprobación, las solicitudes de request_permissions o las llamadas a herramientas de apps y de MCP que requieren aprobación. Una regla de comandos también puede exigir una revisión dentro del sandbox.

La política del revisor comprueba si hay exfiltración de datos, intentos de descubrir credenciales, cambios que debiliten la seguridad de forma persistente o acciones destructivas. Las acciones de riesgo bajo y medio pueden continuar si la política las permite. La política rechaza las acciones de riesgo crítico. Las acciones de riesgo alto requieren autorización suficiente del usuario y que no se aplique ninguna regla de denegación. Si falla la construcción del prompt, la sesión de revisión o el análisis sintáctico, se bloquea la acción. Los tiempos de espera agotados se informan por separado, pero tampoco se ejecuta la acción.

Para reemplazar la política de forma local o en toda una organización, consulta Configuración de la revisión automática.

En la app de escritorio de ChatGPT, estas revisiones aparecen como elementos de Revisión automática cuyo estado indica si la solicitud está en revisión, fue aprobada, rechazada o interrumpida, o si se agotó el tiempo de espera. También pueden incluir el nivel de riesgo de la solicitud revisada y una evaluación de la autorización del usuario.

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

Combinaciones habituales de sandbox y aprobación

Para ejecuciones no interactivas, usa codex exec --sandbox workspace-write.

Configuración en config.toml

Para conocer el proceso general de configuración, 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 ajustes preestablecidos como archivos de perfil y seleccionarlos 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 de forma local

Para ver qué sucede al ejecutar un comando dentro del sandbox de Codex, usa estos comandos de la CLI de Codex:

# 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 los comandos auxiliares de cada plataforma tienen alias, como 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 elegiste. Cuando las restricciones de lectura activan los valores predeterminados de la plataforma, Codex agrega una política específica para macOS en lugar de permitir el acceso general a /System. Así mantiene la compatibilidad con las herramientas de uso habitual.
• Linux usa bwrap junto con seccomp de forma predeterminada.
• Windows admite MXC, con elevated y unelevated como alternativas heredadas. En el Subsistema de Windows para Linux 2 (WSL2), Codex usa la implementación del sandbox de Linux. Codex admitió WSL1 hasta la versión 0.114 inclusive. A partir de la versión 0.115, el sandbox de Linux pasó a usar bwrap, por lo que ya no se admite WSL1.

Si usas la extensión de Codex para IDE en Windows, puedes usar WSL2 directamente. Agrega lo siguiente a la configuración de VS Code para que el agente se ejecute dentro de WSL2 siempre que esté disponible:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Así, la extensión para IDE hereda el comportamiento del sandbox de Linux para los comandos, las aprobaciones y el acceso al sistema de archivos, incluso si el sistema operativo del host es Windows. Consulta la guía de WSL para obtener más información.

Cuando ejecutes Codex en Windows, da prioridad a MXC si el dispositivo y la política lo admiten. Para ello, establece lo siguiente en config.toml:

[features]
prefer_mxc = true

Mantén una implementación heredada permitida en windows.sandbox como alternativa. Consulta la guía de configuración de Windows para conocer la configuración y los límites de compatibilidad.

Si ejecutas Linux en un entorno de contenedores como Docker, es posible que el sandbox no funcione si la configuración del host o del contenedor bloquea las operaciones que Codex necesita para usar espacios de nombres, ejecutar bwrap con setuid o usar seccomp.

En ese caso, configura el contenedor de Docker para que proporcione el aislamiento que necesitas. Luego, dentro del contenedor, ejecuta codex con --sandbox danger-full-access (o con la opción --dangerously-bypass-approvals-and-sandbox).

Ejecutar Codex en Dev Containers

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

Dentro del contenedor, elige uno de estos modos:

• Mantén habilitado el sandbox de Linux de Codex si el perfil de Dev Container concede las capacidades que necesita bwrap para crear el sandbox interno.
• Si quieres usar el contenedor como límite de seguridad, 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 incluya control de versiones:

• Trabaja en una rama de desarrollo y comprueba que git status no muestre cambios pendientes antes de delegar. Así es más fácil aislar y revertir los parches de Codex.
• Da preferencia a los flujos de trabajo basados en parches (por ejemplo, git diff/git apply) frente a la edición directa de archivos bajo control de versiones. Haz commits con frecuencia para poder revertir los cambios en pasos pequeños.
• Trata las sugerencias de Codex como cualquier otro PR: ejecuta 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 ofrece monitoreo opcional mediante OpenTelemetry (OTel) para que los equipos puedan auditar el uso, investigar problemas y cumplir los requisitos normativos sin debilitar los ajustes de seguridad locales predeterminados. La telemetría está desactivada de forma predeterminada. Para usarla, habilítala explícitamente en la configuración.

Descripción general

• Codex desactiva la exportación de OTel de forma predeterminada para que las ejecuciones locales se mantengan independientes.
• Cuando la exportación está habilitada, Codex emite eventos de registro estructurados sobre chats, solicitudes de API, actividad de los flujos SSE/WebSocket, prompts de usuarios (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 (el servicio de origen), la versión de la CLI y una etiqueta de entorno que permite distinguir el tráfico de desarrollo, preproducción y producción.

Habilitar OTel (opcional)

Agrega un bloque [otel] a la 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 sin enviar datos a ningún destino.
• Para enviar eventos a tu propio colector, 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 envía los que quedan pendientes al cerrarse. Solo exporta la telemetría que genera su módulo OTel.

Categorías de eventos

Estos son algunos tipos de eventos representativos:

• codex.conversation_starts (modelo, ajustes de razonamiento y política de sandbox y aprobación)
• codex.api_request (intento, estado o indicador de éxito, duración y detalles del error)
• codex.sse_event (tipo de evento del flujo, éxito o fallo y duración, además del recuento de tokens en response.completed)
• codex.websocket_request y codex.websocket_event (duración de la solicitud y, para cada mensaje, tipo, indicador de éxito y error)
• codex.user_prompt (longitud del prompt, con el contenido oculto a menos que se habilite explícitamente su registro)
• codex.tool_decision (aprobación o rechazo y origen de la decisión: la configuración o el usuario)
• codex.tool_result (duración, indicador de éxito y fragmento de la salida)

Las métricas de OTel asociadas, que combinan un contador con un 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 a 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 solo a colectores 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 datos sensibles. Siempre que sea posible, oculta los datos sensibles en el colector o en el SIEM.
• Revisa los ajustes locales de retención de datos (por ejemplo, history.persistence / history.max_bytes) si no quieres que Codex guarde las transcripciones de las sesiones en CODEX_HOME. Consulta Configuración avanzada y la 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 colector. Para exportar los datos, permite el acceso a la red en modo workspace-write para el punto de acceso de OTel o exporta desde Codex Cloud con el dominio del colector en la lista de dominios permitidos.
• Revisa los eventos periódicamente para detectar cambios en las aprobaciones o en el sandbox y ejecuciones inesperadas de herramientas.

OTel es opcional y está diseñado para complementar las protecciones del sandbox y las aprobaciones descritas anteriormente, sin sustituirlas.

Configuración administrada

Los administradores de Enterprise pueden definir 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.