OpenAI Codex a finales de 2026: goal mode, dots y cómo blindarlo

Uso Codex junto a Claude Code en mi propio trabajo, y este año ha cambiado más que cualquier otra herramienta de mi mesa. Forma parte de los planes de pago de ChatGPT, persigue un objetivo durante horas, desde septiembre existen los dots, agentes siempre activos con su propio ordenador en la nube, y a finales de octubre llegó un modelo más barato. Es mucha autonomía para dársela a un equipo de golpe. La mayor parte del riesgo no viene del modelo, sino de valores por defecto que nadie ha revisado: un sandbox más amplio de lo necesario, aprobaciones desactivadas en un portátil con acceso a producción. Esto es lo que merece la pena hoy, y estos son los ajustes exactos que configuro antes de que empiece un equipo.

Dominik Heinrich

7 de noviembre de 202610 min de lectura

1. Dónde funciona Codex y cuánto cuesta

Codex ya no es un producto aparte que se compra. La página de precios de OpenAI lo incluye en los planes de ChatGPT: Plus por 20 dólares al mes para «unas pocas sesiones de programación centradas cada semana», Pro desde 100 dólares con niveles de 100, 200 y 500, y Business por 20 dólares por usuario y mes con facturación anual (25 mensual), con un espacio de trabajo propio, controles de administración, SSO SAML y sin entrenamiento con datos de empresa por defecto. Enterprise y Edu se cotizan bajo petición. Funciona en la app de escritorio de ChatGPT, en la Codex CLI, en la extensión del IDE, en iOS y como tareas en la nube que trabajan sobre una copia de tu repositorio, y ChatGPT Work y Codex comparten uso y créditos. Para CI hay una vía aparte: Codex con una clave de API, facturado a precios de API y sin las funciones en la nube como la revisión de código en GitHub. Para un piloto de equipo suelo empezar con Business, porque los controles de administración de los pasos siguientes solo existen ahí.

2. Los modelos de debajo: Sol, Terra y el retirado GPT-5.5

OpenAI publicó GPT-6.1 Terra el 26 de octubre y lo puso a disposición de Plus, Pro, Enterprise y Edu en ChatGPT Work y Codex. En su anuncio, OpenAI indica que los precios estándar de API de Terra son un 50 % más bajos que los de GPT-5.6 Terra y GPT-6.1 Sol, con 1 dólar por millón de tokens de entrada y 5 dólares por millón de tokens de salida. En ejecuciones largas de agentes eso importa más que unos puntos de benchmark, porque el coste por tarea decide cuántas veces puedes dejar iterar a un agente. Al mismo tiempo, GPT-5.5 se retiró de Codex con inicio de sesión de ChatGPT el 14 de octubre; las sesiones con clave de API no se vieron afectadas. Mi regla en proyectos: el modelo más barato para trabajo abundante y bien testeado, como actualizar dependencias y corregir tests, y el más potente para refactorizaciones que cruzan muchos módulos. Fija el modelo en config.toml para la CI, así un cambio de valor por defecto nunca te sorprende a mitad de sprint.

Introducing dots, always-on agents built to handle everything, OpenAI (YouTube). Se carga desde YouTube solo cuando haces clic.

3. Goal mode: un objetivo persistente

El goal mode empezó en primavera como un comando experimental en la CLI y está disponible de forma general en la app, la extensión del IDE y la CLI desde mayo. La referencia de comandos lo describe con sencillez: /goal seguido del objetivo lo fija, /goal a secas lo muestra, y /goal edit, pause, resume y clear lo gestionan mientras la tarea avanza. Los objetivos pueden tener hasta 4.000 caracteres; para instrucciones más largas, la documentación sugiere poner los detalles en un archivo y apuntar el objetivo a él. Se aplica la misma regla que con cualquier bucle de agente: escribe una meta que los comandos puedan demostrar, no un deseo. «Termina la migración y mantén los tests en verde» es el propio ejemplo de la documentación, y yo lo afino con el comando exacto de tests, los archivos que no deben cambiar y una cláusula de parada. Un objetivo que no se puede verificar no termina, solo se encarece.

text

/goal Migrate src/payments from the v1 client to the v2 client.
Done when: "npm test -- payments" exits 0, "npm run typecheck" exits 0,
no file under src/legacy or test/fixtures is changed, and no test is skipped.
Work on a branch and summarise the diff when done.
If blocked for more than 3 attempts on the same error, stop and explain.

4. Dots: agentes siempre activos que delegan en Codex

OpenAI presentó los dots el 29 de septiembre en el DevDay. Un dot es un agente siempre activo con su propio ordenador y navegador en la nube, que sigue trabajando con tu portátil apagado, se conecta a más de 4.000 apps mediante plugins y está disponible en ChatGPT, Slack y Teams, incluso por llamada de voz. Lo que importa a los equipos de ingeniería está en la documentación de dots de OpenAI: un dot puede crear tareas de Work o de Codex, continuar tareas locales de Codex existentes y usar un entorno en la nube de Codex que hayas creado para trabajar con el repositorio. El ejemplo de la propia OpenAI es un dot que vigila el feedback de clientes, acota pequeñas correcciones, las construye y prueba y te trae pull requests completos con vídeos del cambio. Tu ordenador queda separado salvo que lo conectes, las Custom Rules permiten autorizar acciones concretas, exigir aprobación o bloquearlas, y un paso de auto-review comprueba las acciones de riesgo frente a tus instrucciones. La disponibilidad es desigual: Pro 100, 200 y 500 no están disponibles en el EEE, el Reino Unido y Suiza, mientras que Business Premium sí está en las regiones compatibles de ChatGPT, y el 3 de noviembre OpenAI añadió GPT-6.1 Terra a los modelos que mueven los dots.

Consejo práctico

Las conversaciones con tu dot no cuentan para los límites de uso de ChatGPT, pero las tareas que inicia en Codex o Work sí. Vigila el uso las primeras semanas, sobre todo si un dot abre por su cuenta muchos pull requests pequeños.

5. Sandbox y aprobaciones: elegir el ajuste según el riesgo

La documentación del sandbox describe dos controles separados. El sandbox es el límite técnico de cada comando que lanza Codex, incluidos git, gestores de paquetes y ejecutores de tests: read-only permite inspeccionar archivos pero no editar ni ejecutar comandos sin aprobación, workspace-write permite editar dentro del espacio de trabajo y ejecutar ahí comandos habituales, y danger-full-access elimina los límites de sistema de archivos y de red. La política de aprobación decide cuándo Codex se detiene y pregunta antes de cruzar ese límite: on-request pregunta cuando necesita salir del sandbox, never no pregunta. «untrusted» ya no es una política de aprobación compatible y «on-failure» está obsoleta, así que revisa las configuraciones antiguas. Mi recomendación según el riesgo: explorar un repositorio desconocido, read-only con on-request. Trabajo normal de funcionalidades en una rama, workspace-write con on-request y sin acceso a red, que la documentación llama el preset de automatización local de menor riesgo. Ejecuciones sin supervisión en un contenedor desechable sin secretos, workspace-write con never; la documentación insiste en que «never» solo quita las preguntas, no concede ejecución sin restricciones. danger-full-access con never solo tiene sitio en una VM desechable, nunca en un portátil que llega a producción.

toml

# ~/.codex/config.toml (or .codex/config.toml in a trusted project)
# Everyday feature work: edits inside the workspace, asks before anything beyond it.
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"   # or "auto_review" to let the reviewer agent handle eligible prompts

[sandbox_workspace_write]
network_access = false        # turn on only for tasks that really need the internet

Consejo práctico

Cuando una aprobación ofrezca «una vez» o «para esta sesión», elige el alcance más estrecho que permita seguir, y usa worktrees separados en lugar de ampliar el acceso entre repositorios.

Interactivo

¿Qué ajustes de Codex encajan con tu tarea?

Elige la situación. Obtienes el modo sandbox, la política de aprobación y la configuración para copiar, con los nombres de la documentación de Codex (noviembre de 2026).

workspace-write

sandbox_mode

on-request

approval_policy

El preset de automatización de menor riesgo de la documentación: edita en el workspace y pregunta antes de lo demás.

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

[sandbox_workspace_write]
network_access = false

Todas las calculadoras y checklists

6. Salvaguardas de administración: requirements.toml

Los archivos config.toml personales son preferencias; los usuarios pueden cambiarlos. En Business y Enterprise, la documentación de configuración gestionada da a los administradores una segunda capa. En Agent security editas las guardrails de la política, o el requirements.toml equivalente, que restringe los ajustes sensibles: política de aprobación, revisor de aprobaciones, modo de sandbox, perfiles de permisos, búsqueda web, hooks gestionados y qué servidores MCP y marketplaces de plugins pueden activar los usuarios. Los requisitos limitan las opciones; los valores por defecto, aparte, fijan el punto de partida. El ejemplo de la propia documentación bloquea «--ask-for-approval never» y «--sandbox danger-full-access», incluido el atajo --yolo, permitiendo solo los valores más seguros. Dos detalles de la documentación que conviene saber: desde Codex 0.138, OpenAI prefiere los perfiles de permisos con allowed_permission_profiles frente al antiguo allowed_sandbox_modes, y allowed_web_search_modes = ['cached'] impide la búsqueda web en vivo incluso en sesiones con acceso total. Un requisito sin definir significa sin límite, así que apunta cada clave en la que confías.

toml

# requirements.toml (Agent security > Edit as TOML), enforced for the workspace
# Users can still choose between these values, but nothing wider.
allowed_approval_policies = ["on-request"]                 # no "never" on managed devices
allowed_sandbox_modes     = ["read-only", "workspace-write"] # blocks danger-full-access and --yolo
allowed_web_search_modes  = ["cached"]                     # no live web search from agents

7. AGENTS.md, reglas y la puerta de revisión

En AGENTS.md viven las convenciones: cómo ejecutar los tests, qué carpetas son generadas, las reglas de arquitectura que un revisor tendría que repetir. Es útil, pero es una guía, no un límite de seguridad, y cualquier cosa del repositorio puede cambiarlo, así que revisa sus cambios como código y deja el archivo en manos del equipo de plataforma. Para las excepciones reales, Codex tiene reglas que permiten, piden confirmación o prohíben prefijos de comandos concretos fuera del sandbox, algo que la documentación del sandbox prefiere a ampliar el acceso en general. Los archivos .codex/config.toml de proyecto solo se cargan cuando confías en el proyecto, así que un repositorio clonado no puede relajar tus ajustes en silencio. La última capa es aburrida e imprescindible: Codex trabaja en una rama, la CI ejecuta las mismas comprobaciones que para una persona y una persona aprueba el merge. La revisión de código de Codex en GitHub es un buen segundo lector, pero no sustituye la aprobación humana que exige tu protección de ramas.

8. Cómo lo despliego en un equipo

Semana uno: espacio de trabajo Business, SSO, requirements.toml solo con on-request y sin acceso total, y un AGENTS.md breve por repositorio con los comandos de tests y lint. Semana dos: cinco voluntarios usan Codex en local en workspace-write con tickets reales, y recogemos cada aprobación que les molestó; la mayoría se convierten en reglas o en writable roots en lugar de sandboxes más amplios. Semanas tres y cuatro: goal mode para trabajo bien testeado, como actualizar dependencias y reparar tests, más tareas en la nube para issues pequeños, con la misma CI y la misma revisión que los cambios humanos. Los dots llegan al final, y solo con un responsable con nombre y Custom Rules, porque un dot que abre pull requests por su cuenta necesita a alguien que los lea. Medimos el tiempo de entrega, el esfuerzo de revisión y el coste por cambio fusionado. El patrón es el de cualquier agente: primero las salvaguardas, después la velocidad.

Conclusión
Codex rinde al máximo con un objetivo verificable, un sandbox estrecho y dots que le pasan trabajo, pero fija primero las salvaguardas de forma central y da la velocidad después.

Proyectos reales relacionados

Pruébalo tú mismo

Ajustes de seguridad de Codex

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos