Codex Cloud en la nube: delega el trabajo a la nube y espera el resultado tomando un café
📚 Navegación de la serie: El artículo anterior 09 · Extensiones de IDE (VS Code, etc.) metió a Codex en la barra lateral de tu editor: dondequiera que estés escribiendo código, allí estará listo para ayudar. Este artículo cambia a una forma de jugar completamente diferente: puedes apagar tu computadora, y el trabajo seguirá ejecutándose en la nube. El siguiente artículo 11 · Manual del proyecto AGENTS.md volverá a explicar cómo entrenar a esta "máquina en la nube" para que sea obediente.
Amigos, hoy hablaremos de la cara más especial de las cuatro caras de Codex: la versión en la nube (Codex cloud).
Las tres interfaces anteriores (App de escritorio, CLI, extensión de IDE) tienen algo en común: el trabajo se realiza en tu propia computadora, leyendo tus archivos locales y ejecutando tus comandos locales, y cuando apagas tu computadora, se detiene. La versión en la nube hace lo contrario: haces un pedido en el navegador, el trabajo se ejecuta en las propias máquinas en la nube de OpenAI y se desvincula por completo de tu computadora.
Permítanme contarles un escenario real mío. Una tarde de mayo de este año, la CI de mi servicio Python de varios miles de líneas falló repentinamente con tres casos de prueba fallidos que no tenían relación entre sí, todos de ese tipo de trabajo trivial que "no es difícil de arreglar pero hay que revisarlos uno por uno". En el pasado, habría tenido que quedarme frente a la terminal haciendo cambios uno a uno. Ese día, envié tres tareas a la vez directamente en chatgpt.com/codex: una tarea por cada caso fallido, con tres máquinas en la nube ejecutándose al mismo tiempo. Cerré mi laptop y me fui a una reunión, y al volver, los tres diff modificados estaban allí ordenados esperándome para hacer clic en "crear PR", sin que el ventilador de mi computadora hiciera ruido en todo el proceso.
Al terminar este artículo, obtendrás:
- Conocer la versión en la nube de verdad: sin instalar entornos, ejecutándose en contenedores aislados en la nube de OpenAI y conectado a tu repositorio de GitHub.
- Entender el flujo completo de 5 pasos de una tarea en la nube desde la creación del contenedor hasta la entrega del diff, sabiendo qué hace cada paso.
- Aprender a configurar el entorno en la nube (environment): scripts de configuración, variables de entorno, Secrets, fijación de versiones y caché, explicado detalladamente uno por uno.
- Aclarar el gran asunto de la lista blanca de red: por qué el Agent está desconectado por defecto, cuándo se debe abrir y cuáles son los riesgos de abrirlo.
- Una tabla comparativa de "nube vs local" para saber qué tareas se deben delegar a la nube y cuáles deben quedarse en local.
01 Qué es exactamente la versión en la nube: hacer pedidos en el navegador, trabajar en la nube
Primero la conclusión: la versión en la nube es simplemente llevar Codex a la nube de OpenAI: no necesitas configurar ningún entorno, abres la página web en tu navegador, te conectas a GitHub, le asignas tareas y este lee el código, lo modifica y ejecuta pruebas en una máquina aislada en la nube, y al terminar te entrega directamente el diff o crea un PR.
Se ejecuta en chatgpt.com/codex, y al entrar, la primera vez que lo uses debes hacer una cosa: conectar tu cuenta de GitHub. Una vez conectado, Codex podrá leer el código de tus repositorios y crear Pull Requests (solicitudes de extracción, abreviadas como PR, que es el método de entrega de "ya lo he modificado, revísalo y combínalo") a partir de sus cambios. 
Haz clic en el enlace del medio para conectar a GitHub 
Después de asociarlo, puedes seleccionar directamente el repositorio para realizar modificaciones de código. Por supuesto, si ya no deseas asociarlo, solo ve a la configuración para desvincularlo. 
Analogía: No necesitas conducir tú mismo, llamas a un coche de transporte con conductor incluido. La versión local es como tu propio coche: te es familiar, pero cada vez que sales tienes que poner gasolina, comprobar la presión de los neumáticos y calentar el motor (configurar el entorno, instalar dependencias) tú mismo. La versión en la nube es como pedir un transporte: el coche es de la plataforma, el conductor es de la plataforma y el combustible también es de la plataforma, tú solo ingresas el destino en la App (descripción de la tarea), subes (envías) y bajas al llegar a la parada (miras el diff). Si a mitad de camino el coche se avería o choca, es problema de la plataforma, y no dañará ni un pelo de tu propio coche.
Este concepto de "el coche es de otro" se traduce técnicamente en el contenedor (container, un entorno de ejecución ligero y aislado mutuamente) que Codex inicia en la nube: crea uno nuevo para cada tarea, descarga tu repositorio en él y trabaja a puerta cerrada, con cero contacto con tu máquina local.
Es adecuado para este tipo de escenarios reales:
- Ejecutar múltiples tareas en paralelo: cada tarea en un contenedor y rama independientes, sin interferir entre sí. El ejemplo inicial de "tres casos fallidos reparados simultáneamente en tres máquinas" es típico; esta es la mejor parte de la versión en la nube.
- Repositorios no clonados localmente: quieres echar un vistazo rápido o hacer un pequeño cambio, pero no has hecho
git clonede él en tu máquina local. La nube descarga uno nuevo para ti cada vez, ahorrándote todo el proceso de clonar y configurar el entorno. - Tareas lentas y largas ejecutándose en segundo plano: ejecutar suites completas de pruebas, refactorizaciones masivas o migraciones de bases de datos completas que tardan decenas de minutos; las delegas a la nube para que se ejecuten y tú puedes hacer lo tuyo, regresando más tarde a recoger el resultado.
- Cambio a una computadora sin entorno configurado: en la máquina de otra persona o en una computadora nueva recién recibida donde no hay nada instalado, aún puedes trabajar de la misma manera.
Dejemos claros dos requisitos previos para que no trabajes en vano:
- Debe conectarse a GitHub. La versión en la nube depende de los repositorios de GitHub para trabajar; si no se conecta a GitHub y no hay repositorio, no puede empezar.
- Debe ser un plan de pago. Según la documentación oficial, los planes Plus, Pro, Business, Edu y Enterprise incluyen el uso de Codex; es posible que en algunos espacios de trabajo de Enterprise el administrador deba habilitarlo primero para poder usarlo. El límite de cuota específico para cada nivel cambia rápidamente y se rige por la página de facturación oficial.
💡 Resumen en una frase: Versión en la nube = contenedor aislado en la nube de OpenAI + conexión a GitHub + sin configurar entornos, ideal para ejecutar tareas en paralelo, modificar repositorios no clonados localmente y dejar tareas largas en segundo plano; siempre que se conecte a GitHub y el plan sea suficiente.
02 Cómo se ejecuta una tarea en la nube: desde la creación del contenedor hasta la entrega del diff
En el momento en que haces clic en "Enviar tarea", ¿qué sucede exactamente en la nube? La documentación oficial lo divide claramente en 5 pasos. Al comprender estos 5 pasos, sabrás qué parte estás ajustando al configurar el entorno o la red más adelante.
Analogía: Enviar el código a una línea de ensamblaje automatizada. Colocas la "materia prima" del repositorio en la cinta transportadora y esta pasa por varias estaciones en orden: carga de material, preprocesamiento según tu fórmula, conexión de agua y electricidad, el brazo robótico trabajando y finalmente la presentación del producto terminado para tu inspección. Cada estación realiza una sola tarea en un orden fijo, y lo que puedes ajustar es "cómo trabaja" cada estación.
Según la documentación oficial, esta línea de ensamblaje funciona así:
- Creación del contenedor y descarga del código: Codex crea un contenedor nuevo y descarga tu repositorio en la rama especificada o en un commit determinado.
- Ejecutar el script de configuración (setup script): instalar dependencias y herramientas, por ejemplo,
npm installopip install. Si se continúa la ejecución utilizando un contenedor en caché, también se ejecutará un script de mantenimiento (maintenance script) opcional adicional. - Aplicar la configuración de acceso a la red: la fase del script de configuración puede conectarse a internet (de lo contrario no podría instalar dependencias), pero al llegar a la fase de trabajo del Agent, el acceso a la red está desactivado por defecto, y si deseas permitirlo debes configurarlo por separado (este es el tema principal de la sección 04).
- El Agent entra en el ciclo de trabajo: escribe comandos uno a uno en la terminal, modifica el código, ejecuta comprobaciones y busca formas de verificar si realizó los cambios correctamente. Si tu repositorio tiene un archivo
AGENTS.md, se guiará por los comandos de lint y prueba definidos en él (por esoAGENTS.mdes tan importante, el próximo artículo trata exclusivamente sobre esto). - Entrega del trabajo: al terminar, te muestra la respuesta junto con el diff de todos los cambios. Puedes crear un PR con un solo clic o continuar preguntando "modifica esto también".
Lo que esta imagen quiere expresar es: la tarea en la nube es una línea de ensamblaje con un orden fijo: "instalar dependencias" y "trabajar" son dos fases separadas, y los permisos de red también se otorgan por fases (se permiten al instalar dependencias y se retiran por defecto al trabajar). Al recordar esta "división por fases", todas las configuraciones siguientes serán fáciles de entender.
Aquí hay una trampa en la que los principiantes suelen caer con facilidad, y la destaco por separado. Cuando el Agent en la nube trabaja, no se detendrá línea por línea por defecto a esperar a que hagas clic en aceptar: lee la tarea, realiza las modificaciones de corrido y te entrega el diff directamente al terminar. Esto es diferente de ese ritmo de aprobación de "preguntar solo al salir del límite" que tienes al usar la CLI en local. Por lo tanto, al enviar tareas a la nube, la descripción debe ser específica: aclara qué archivo modificar, qué efecto deseas y el comportamiento esperado.
Yo caí en esta trampa a finales del año pasado: para ahorrar tiempo solté la frase "optimiza este módulo de logs", y al volver vi que tomó la iniciativa de refactorizar una sección enorme, que estaba muy lejos del pequeño cambio que yo quería. Ver ese diff me dio dolor de cabeza y al final hubiera sido mejor modificarlo yo mismo. Desde entonces, mis tareas en la nube tienen siempre un nivel de detalle que permite la aceptación con una sola frase, como "reemplaza todos los print en logger.py por logging.info, no toques ningún otro archivo".
💡 Resumen en una frase: La tarea en la nube es una línea de ensamblaje de 5 pasos: crear contenedor → ejecutar script de configuración (con red) → aplicar configuración de red (Agent sin red por defecto) → Agent trabaja → entregar diff; no te preguntará a mitad del camino por defecto, por lo que la descripción de la tarea debe redactarse con un nivel de detalle que permita "aceptarla en una sola frase".
03 Configurar el entorno: instalar las herramientas que necesitas en la máquina en la nube
La máquina en la nube al encenderse es un "vehículo estándar", pero es muy probable que tu proyecto tenga sus particularidades: requiere una versión específica de Node, necesita instalar un linter particular o debe compilarse antes de ejecutar las pruebas. Todo esto se le indica mediante la configuración del entorno (environment).
Analogía: Hacer una "lista de compras antes de mudarse" para una habitación de alquiler. La casa (contenedor) es un espacio básico que ofrece la plataforma, pero antes de mudarte debes indicar claramente: instalar primero el internet (dependencias), ajustar el calentador de agua a esta temperatura (versión del entorno de ejecución) y pegar la contraseña de Wi-Fi en la pared (variables de entorno). Llenas esta lista y cada vez que "te mudes", se configurará automáticamente siguiendo estas indicaciones, ahorrándote tener que explicarlo de nuevo cada vez. La configuración del entorno se completa en la página de Environments en la configuración de Codex.
Imagen por defecto: universal
El Agent en la nube se ejecuta por defecto en una imagen de contenedor llamada universal, donde los lenguajes, paquetes y herramientas comunes ya vienen preinstalados (Python, Node.js, etc., listos para usar). Si deseas ver qué tiene instalado exactamente, la comunidad oficial tiene un repositorio de referencia de código abierto openai/codex-universal, e incluso proporciona el Dockerfile, por lo que puedes descargarlo a tu máquina local para probarlo.
Si la versión por defecto no se adapta a las necesidades de tu proyecto, puedes elegir "Set package versions" en la configuración del entorno para fijar las versiones del entorno de ejecución como Python o Node.js, evitando problemas como "la nube usa Node 20 y mi local usa Node 18, por lo que los resultados no coinciden".
Script de configuración: automático o manual
El script de configuración (setup script) es el bloque de comandos que se ejecuta automáticamente después de crear el contenedor y antes de que el Agent comience a trabajar, encargado específicamente de instalar dependencias y herramientas. Tiene dos formas de ejecutarse:
- Configuración automática: utiliza gestores de paquetes comunes (la lista oficial incluye
npm,yarn,pnpm,pip,pipenv,poetry), Codex puede identificarlos automáticamente e instalar las dependencias por ti, sin que tengas que escribir nada. - Configuración manual: si el proyecto es complejo y la automática no es suficiente, escribes tu propia secuencia. Por ejemplo:
# 装个类型检查器
pip install pyright
# 装依赖
poetry install --with test
pnpm installAquí hay una trampa en la que la documentación oficial insiste repetidamente y en la que los principiantes suelen caer, y la destaco en negrita para ti:
El script de configuración y el Agent se ejecutan en dos sesiones de Bash diferentes, por lo que las variables de entorno definidas mediante export no se transferirán a la fase del Agent. Si haces export FOO=bar en el script de configuración, cuando el Agent comience a trabajar FOO estará vacío. Si quieres que las variables sobrevivan hasta la fase del Agent, escríbelas en ~/.bashrc o configúralas directamente como "variables de entorno" en la configuración del entorno (como explicaremos a continuación). Yo ya caí en esta trampa por ti: en ese momento estaba configurando un flujo de CI para un monorepo y me preguntaba por qué el Agent no leía la variable exportada, hasta que revisé la documentación y me di cuenta de que eran dos sesiones distintas.
Variables de entorno vs Secrets: se parecen, pero funcionan de manera diferente
Ambos se utilizan para introducir configuraciones en el contenedor, pero su alcance de visibilidad es extremadamente diferente, y si los confundes, no se podrán leer o podrías filtrar información confidencial:
| Tipo | Duración | Quién puede verlo | Para qué se usa |
|---|---|---|---|
| Variables de entorno (Environment Variables) | Durante toda la tarea (tanto en el script de configuración como en el Agent) | Script de configuración + Agent | Configuraciones comunes como NODE_ENV |
| Secrets | Solo hasta la fase del script de configuración, se eliminan antes de que el Agent comience a ejecutarse | Solo el script de configuración | Información sensible como API keys y contraseñas |
¿Por qué los Secrets se diseñaron así? La documentación oficial lo explica claramente: los Secrets añaden una capa adicional de cifrado, se descifran solo durante la ejecución de la tarea y se eliminan antes de que comience la fase del Agent; este es un diseño de seguridad intencional. En pocas palabras: tu clave solo aparece durante ese breve momento de "instalar dependencias", y cuando el Agent realmente empieza a modificar código y posiblemente entra en contacto con contenido no confiable, la clave ya ha sido retirada y no se puede filtrar. Por lo tanto, para cualquier dato sensible, colócalo obedientemente en los Secrets y no intentes ahorrar camino metiéndolo en las variables de entorno.
Caché del contenedor: por qué la segunda ejecución es más rápida
Crear un contenedor desde cero e instalar todas las dependencias cada vez es demasiado lento. Por ello, Codex almacena en caché el estado del contenedor por un máximo de 12 horas, permitiendo que tus nuevas tareas posteriores y preguntas de seguimiento se ejecuten más rápido.
Cómo se utiliza la caché (resumen de las palabras oficiales):
- Primera vez (creación de caché): clona el repositorio, cambia a la rama por defecto, ejecuta el script de configuración y luego guarda este estado.
- Ejecución subsiguiente (uso de caché): cambia a la rama especificada para esta tarea y ejecuta ese script de mantenimiento opcional; este se encarga de tareas como "el script de configuración se ejecutó en un commit antiguo, por lo que las dependencias deben actualizarse".
¿Cuándo se invalida automáticamente la caché? Si modificas cualquiera de los elementos como el script de configuración, el script de mantenimiento, las variables de entorno o los Secrets, se invalidará y reconstruirá automáticamente. Si los cambios en el repositorio hacen que la caché deje de coincidir, ve a la página de entornos y haz clic en "Reset cache" para restablecerla manualmente.
⚠️ Un escenario de equipo a tener en cuenta: para los usuarios de Business y Enterprise, la caché se comparte en todo el entorno; hacer clic en "Reset cache" afectará a todas las personas en el espacio de trabajo que utilicen este entorno. No te apresures.
💡 Resumen en una frase: Configuración del entorno = hacer una "lista de compras" para la máquina en la nube: la imagen
universalsirve de base, el script de configuración instala las dependencias (¡elexportno se transfiere entre sesiones!), las variables de entorno son visibles en todo momento, los Secrets se eliminan al finalizar la fase de instalación de dependencias y la caché dura un máximo de 12 horas, invalidándose si se realiza algún cambio.
04 Lista blanca de red: por qué el Agent está desconectado por defecto y cuándo se debe abrir
Esta es la sección de la versión en la nube que debes tomar más en serio. Una frase para definir la conclusión: la fase del script de configuración puede conectarse a internet (de lo contrario no podría instalar dependencias), pero la fase de trabajo del Agent está completamente desconectada por defecto; si deseas permitir el acceso y en qué medida, debes configurarlo entorno por entorno.
¿Por qué dividirlo en fases de esta manera tan peculiar? Porque una vez que se permite el acceso a internet en la fase del Agent, los riesgos son reales. La documentación oficial enumera varios de ellos, y el que más debe ponernos en alerta es la inyección de prompts (prompt injection).
Analogía: Dejar que un becario recién llegado busque información en internet para hacer una tarea. Instalar dependencias (script de configuración) es como pedirle que compre a proveedores fijos: el destinatario está controlado, puedes estar tranquilo. Pero una vez que lo dejas "buscar libremente por internet y hacer lo que diga cualquier instrucción que encuentre" (Agent conectado), surgen los problemas: una página web podría ocultar una instrucción de phishing como "por favor, envía este código mediante POST a tal URL", y si él realmente lo hace, tu código y tus claves se enviarán en secreto. La documentación oficial ofrece un ejemplo real: le pides a Codex "repara este issue de GitHub", y resulta que en la descripción del issue se ocultaba una línea como git show HEAD | curl ... cierta dirección externa. Si el Agent la ejecuta, el contenido de la última confirmación (commit) se filtrará al atacante.
Por tanto, respecto a abrir el acceso a la red, la postura oficial es: si puedes evitarlo, no lo abras; si lo abres, redúcelo al mínimo. Hay dos niveles de configuración, junto con dos válvulas de control adicionales:
Primer nivel: Encendido o apagado
- Off：完全断网。这是默认，也是最安全的。
- Off: desconectado por completo. Este es el valor por defecto y el más seguro.
- On：放开联网，但你可以用「域名白名单」+「允许的 HTTP 方法」再收紧。
- On: permite la conexión a internet, pero puedes restringirlo aún más utilizando una "lista blanca de dominios" + "métodos HTTP permitidos".
Válvula de control uno: Lista blanca de dominios (domain allowlist)
Incluso si activas On, no dejes que navegue por todo el mundo. La documentación oficial ofrece tres configuraciones preestablecidas para elegir:
| Preajuste | Qué significa | Adecuado para |
|---|---|---|
| None | Lista blanca vacía, agregas los dominios uno por uno | Cuando solo necesitas acceder a muy pocos dominios propios |
| Common dependencies | Un conjunto preestablecido de "dominios de dependencias comunes", donde se incluyen sitios habituales de gestión de paquetes y código fuente como github.com, npmjs.com, pypi.org, etc. | La gran mayoría de escenarios de "instalar paquetes y descargar código fuente" |
| All (unrestricted) | Permite todos los dominios | El riesgo más alto, no lo elijas a menos que sea estrictamente necesario |
Al elegir None o Common dependencies, también puedes añadir tus propios dominios adicionales sobre la base preestablecida (por ejemplo, api.mycompany.com). Los dominios específicos incluidos en Common dependencies se rigen por la lista actual de la documentación oficial; esta se actualiza junto con el ecosistema, así que no copiaré una larga lista aquí para evitar desactualizar la información.
Válvula de control dos: Restringir métodos HTTP
Un nivel de control aún más estricto: la recomendación oficial es limitar las solicitudes solo a GET, HEAD y OPTIONS, que son métodos de "solo lectura". De esta manera, las solicitudes de "escritura/envío externo" como POST, PUT, PATCH y DELETE serán bloqueadas por completo, inutilizando el truco de phishing de "enviar el código mediante POST" mencionado anteriormente. Permitirle solo leer y no escribir es una barrera defensiva con una excelente relación costo-beneficio.
Organicemos este sistema de red en una tabla para aclararlo:
| Fase / Configuración | Estado de red | Descripción |
|---|---|---|
| Fase del script de configuración | ✅ Conectado | Requerido para instalar dependencias, activado por defecto |
| Fase del Agent (por defecto) | ❌ Desconectado | El más seguro, desactivado (Off) por defecto |
| Fase del Agent On + Common dependencies | ⚠️ Dominio limitado | Suficiente y bastante estable, punto de partida recomendado |
| Fase del Agent On + Restricción GET/HEAD/OPTIONS | ⚠️ Solo lectura | Añade una barrera adicional para evitar el envío de datos al exterior |
| Fase del Agent On + All | 🚨 Completamente abierto | El riesgo más alto, no lo uses a menos que sea estrictamente necesario |
Mi hábito personal: dejarlo desconectado por defecto (Off); en la gran mayoría de las tareas, tener las dependencias completas en la fase del script de configuración es suficiente para que el Agent trabaje, sin necesidad alguna de que el Agent vuelva a conectarse a internet. Solo cuando realmente necesito extraer datos en tiempo real o llamar a una API externa durante el trabajo, lo configuro en On, y siempre empiezo con Common dependencies + métodos de solo lectura, añadiendo individualmente el dominio que necesite y nunca seleccionando All de entrada. En este último año, de aproximadamente cincuenta o sesenta tareas en la nube que he enviado, no más de cinco requirieron abrir el acceso a la red para el Agent.
⚠️ Hay otra capa de información de contexto mencionada oficialmente: todo el tráfico de salida pasa por un proxy HTTP/HTTPS (por seguridad y para evitar abusos). Esto es algo a nivel de la plataforma y no tienes que encargarte de ello, pero saber que "la red en la nube no está expuesta directamente, sino que pasa por un proxy" te dará tranquilidad.
💡 Resumen en una frase: Instalar dependencias permite la conexión, el Agent trabaja desconectado por defecto; el principal riesgo al abrir el acceso a la red es la inyección de prompts (instrucciones de phishing ocultas en páginas web o issues para robar tu código o claves); si debes abrirlo, empieza con "Common dependencies + limitar a GET/HEAD/OPTIONS", y si no es necesario, no lo abras.
05 Nube vs local: qué tareas se deben delegar a la nube
La nube y el entorno local no se reemplazan mutuamente, sino que se reparten el trabajo. Tras las pruebas prácticas, el criterio de decisión se reduce a una sola frase:
¿Esta tarea requiere tocar cosas de mi computadora? Si es así, usa la versión local (CLI / App de escritorio / extensión de IDE); si no es así, delegarla a la nube es más sencillo.
¿Por qué? Porque esa máquina en la nube solo contiene lo que hay en tu repositorio de GitHub: todo aquello que solo tengas instalado o configurado en tu máquina local (cierta herramienta local, tu configuración global en ~/.codex/, un servidor MCP conectado localmente), la nube no lo verá en absoluto. Para que la nube pueda usarlo, debes confirmar la configuración en el repositorio (por ejemplo, escribir las reglas en el archivo AGENTS.md del repositorio o añadir los requisitos del entorno en la configuración de Environments).
Aquí tienes una tabla comparativa para ver las diferencias de un vistazo:
| Dimensión | Versión en la nube (Codex cloud) | Local (CLI / App de escritorio / extensión de IDE) |
|---|---|---|
| Dónde se ejecuta el código | Contenedor en la nube de OpenAI | Tu propia máquina |
| Desde dónde se asignan tareas | Navegador en chatgpt.com/codex | Tu terminal / UI de escritorio / editor |
| ¿Puede usar tus cosas locales? | ❌ Solo lo que está en el repositorio | ✅ Archivos, herramientas y configuraciones locales completos |
| ¿Requiere GitHub? | ✅ Obligatorio conectar | ❌ No es necesario |
| ¿Sigue ejecutándose si apagas la computadora? | ✅ Sí, se ejecuta igual | ❌ Se detiene al cerrar la terminal |
| Ejecutar tareas en paralelo | ✅ Capacidad nativa, cada una en un contenedor | Requiere abrir múltiples worktrees tú mismo |
| Cómo entrega los cambios | diff + crear PR con un clic | Modifica directamente tus archivos locales |
| ¿Pregunta a mitad de camino? | ❌ No, trabaja de corrido y entrega el diff | ✅ Sí, pregunta según la estrategia de aprobación al salir del límite |
Hay dos filas que debo destacar especialmente.
La primera es la fila "¿Sigue ejecutándose si apagas la computadora?": esta es la función estrella exclusiva de la versión en la nube. El ejemplo del inicio de "cerrar la laptop para ir a una reunión y volver a recoger tres diff" depende de esto. En la versión local, al cerrar la terminal o la tapa de la laptop, la tarea se detiene de inmediato.
La segunda es la fila "¿Pregunta a mitad de camino?": como se enfatizó anteriormente, la nube no te preguntará a mitad del camino por defecto, por lo que la descripción de la tarea debe ser específica; la versión local cuenta con un entorno seguro (sandbox) y una aprobación que te detendrá para preguntarte si sale del límite, siendo un proceso más guiado.
Por cierto, cabe mencionar otras formas de asignar tareas: además de hacerlo en la página web, también es posible delegar tareas a la nube desde la extensión del IDE (iniciar la tarea en el editor, revisar el progreso más tarde e incorporar el diff localmente) y mencionar a @codex desde GitHub (mencionarlo en un issue o PR para iniciar directamente la tarea y proponer cambios). Ambos son "entradas distintas, pero con el mismo motor en la nube por debajo"; no daremos detalles sobre esto en este artículo, pero ten en cuenta que existen estas opciones.
💡 Resumen en una frase: Usa la versión local para lo que requiera tocar tu máquina, y la nube para lo que no requiera tocar tu máquina, cuando quieras paralelismo o si quieres que siga ejecutándose con la computadora apagada; la nube solo reconoce las configuraciones de tu repositorio de GitHub, las configuraciones globales locales no son visibles para ella (si quieres que las conozca, confírmalas en el repositorio).
Llegados a este punto, los pasos explicados por separado en las secciones anteriores pueden conectarse en una línea de ensamblaje completa. La siguiente imagen los conecta de principio a fin:
Lo que esta imagen quiere expresar es: el ciclo de vida completo de una tarea en la nube es "conectar repositorio → configurar entorno en la nube (dependencias / entorno de ejecución / lista blanca de red) → asignar tarea (paralelizable) → ejecutar en contenedor en la nube → revisar diff → crear PR"; configurar el entorno es un paso preparatorio de una sola vez, y una vez enviada la tarea, todo se ejecuta en la nube de OpenAI, sin importar que apagues tu computadora para entregarte el diff en tus manos.
06 Manos a la obra: envía tu primera tarea en la nube
Hablar sin practicar no genera experiencia. El siguiente flujo mínimo te guiará para completar una vez el proceso de "asignar tarea en el navegador → revisar diff → crear PR". Solo necesitas un repositorio de GitHub donde tengas permisos de escritura (puedes usar un repositorio propio de práctica, no pruebes con el de producción).
Nota: La versión en la nube se opera puramente a través de la web; el texto de los botones y el diseño de la página pueden ser ajustados en cualquier momento por OpenAI. Lo que se describe a continuación es la estructura del flujo y "lo que deberías ver", y los botones específicos se rigen por el texto actual de la página, no te aprendas las palabras de memoria.
Primer paso: Abrir la versión en la nube y conectar a GitHub
Accede desde el navegador a:
https://chatgpt.com/codexLa primera vez que entres se te guiará para conectar tu cuenta de GitHub y autorizar los repositorios que vas a utilizar.
Resultado esperado: una vez conectado, deberías poder seleccionar tu repositorio de práctica en la página. Si no puedes seleccionarlo, es probable que no lo hayas marcado durante la autorización de GitHub; regresa a la configuración de autorización en GitHub para añadirlo.
Segundo paso: (Opcional) echa un vistazo a la configuración del entorno
Ve a la página de configuración de Environments para revisar el entorno de tu repositorio.
Resultado esperado: la primera vez serán básicamente los valores por defecto: la imagen universal, configuración automática y la red del Agent en Off. Es mejor que los principiantes mantengan la configuración por defecto y no modifiquen el script de configuración ni la red por el momento; lo importante es completar el flujo.
Tercer paso: Asignar una pequeña tarea "fácil de aceptar en una frase"
Una vez seleccionado el repositorio, escribe una instrucción en el cuadro de tareas con un nivel de detalle que permita su aceptación. Por ejemplo:
在仓库根目录新建一个 HELLO.md ，里面写一行：Hello from Codex cloud. 别动其他任何文件。Enviar.
Resultado esperado: verás que la tarea pasa al estado "en ejecución", y la nube está creando el contenedor, descargando tu repositorio, ejecutando el script de configuración y luego el Agent se pone a trabajar; es decir, la línea de ensamblaje de la sección 02, y ahora puedes verla ejecutarse en vivo.
Cuarto paso: Revisar el diff
Espera a que termine.
Resultado esperado: la página mostrará el diff de los cambios, que debería ser simplemente la adición de un archivo HELLO.md con la línea solicitada. Un diff limpio que solo modifica el archivo correspondiente = la tarea fue un éxito. Si realizó modificaciones en otros archivos, revisa si tu instrucción no incluía "no toques ningún otro archivo".
Quinto paso: Crear un PR (o realizar preguntas de seguimiento)
Si el diff es correcto, haz clic en crear PR y abrirá un Pull Request en tu repositorio de GitHub. Si deseas realizar más cambios, puedes preguntar directamente en la conversación "añade una línea xxx" para que continúe trabajando.
Resultado esperado: aparecerá en GitHub una rama de PR con este cambio, a la espera de tu revisión y combinación. Ver el PR en GitHub = flujo de trabajo completo completado, ¡felicitaciones!
⚠️ Nota para los usuarios en China continental: el conjunto de dominios
chatgpt.com, junto con la redirección de autorización de GitHub, suele requerir herramientas para sortear restricciones de red. Si la página no abre, la autorización de GitHub se queda cargando o la tarea permanece en "conectando", comprueba primero la red; es el mismo requisito de red que al instalar la CLI anteriormente.
💡 Resumen en una frase: Asignar tarea en el navegador → revisar diff → crear PR; sigue estos cinco pasos para completar una tarea en la nube por primera vez y conocerás toda la línea de ensamblaje en la nube: redacta la tarea con un nivel de detalle que permita su "aceptación en una frase", comprueba el diff para confirmar que solo se modificó lo deseado y, si todo está bien, crea el PR.
07 Acceso desde China continental y un detalle de red contraintuitivo
Todas las funciones de este artículo no pueden evitar una barrera real: todas se conectan a la familia de dominios chatgpt.com; la página web se ejecuta en chatgpt.com/codex y la conexión a GitHub también pasa por los servicios de OpenAI.
Por lo tanto, la conclusión es directa: antes de usar la versión en la nube en China continental, prepara las herramientas de red necesarias, de lo contrario la página no abrirá, GitHub no se conectará y la tarea se quedará atascada en "conectando". Esto coincide con los requisitos de red para instalar la CLI en local.
Sin embargo, hay un detalle contraintuitivo y fácil de malinterpretar que debe aclararse:
El Agent dentro del contenedor en la nube se conecta a internet desde la infraestructura en la nube de OpenAI, no desde tu red. Por lo tanto, el proceso de esa máquina en la nube para descargar paquetes npm o clonar repositorios de GitHub se realiza a través de sus propios canales (además de pasar por la lista blanca y ese proxy HTTP), y no tiene relación alguna con si tienes herramientas de red locales o con la velocidad de tu internet.
Diferenciar estos dos puntos te ahorrará dar muchos rodeos en la resolución de problemas:
- Donde necesitas herramientas de red: es únicamente para la sección "cómo se conecta tu navegador a
chatgpt.com". - Conexión interna del contenedor en la nube: depende de OpenAI y de la lista blanca que hayas configurado; el entorno de red de tu máquina local no puede controlarlo ni ayudar.
Por ejemplo, si la instalación de dependencias en la nube es lenta o no puede descargar de algún dominio, no dudes de tu conexión local primero; eso se debe a que el contenedor en la nube se está ejecutando en su propia red bajo la lista blanca que estableciste, y lo que debes verificar es "si este dominio está en la lista blanca" y no la velocidad de tu red local.
💡 Resumen en una frase: La página web y la autorización de GitHub requieren herramientas de red; pero la conexión interna del contenedor en la nube utiliza la propia red de OpenAI + tu lista blanca configurada, siendo dos sistemas de red totalmente independientes de tu red local, por lo que si hay problemas instalando dependencias, comprueba la lista blanca antes de culpar a tu conexión local.
08 Resumen
En este artículo hemos liberado por completo a Codex de la limitación de "tener que estar pegado a tu propia computadora": hacer pedidos en el navegador, trabajar en la nube y seguir ejecutándose con la computadora apagada. Repasemos los puntos clave una vez más:
- Qué es: contenedor aislado en la nube de OpenAI + conexión a GitHub + sin configurar entornos, ideal para paralelismo, modificar repositorios no clonados localmente y dejar tareas largas en segundo plano.
- Cómo se ejecuta: crear contenedor → ejecutar script de configuración (con red) → aplicar configuración de red (Agent sin red por defecto) → Agent trabaja (lee
AGENTS.md) → entregar diff/PR, una línea de ensamblaje de 5 pasos. - Cómo configurar el entorno: la imagen
universalsirve de base, el script de configuración instala las dependencias (recuerda queexportno se transfiere entre sesiones), las variables de entorno son visibles en todo momento, los Secrets se eliminan al finalizar la fase de instalación de dependencias, la caché dura un máximo de 12 horas e invalidación al cambiar configuraciones. - Lista blanca de red: el principal riesgo al abrir el acceso a la red es la inyección de prompts, si debes abrirlo empieza con "Common dependencies + limitar a GET/HEAD/OPTIONS" y si no es necesario no lo abras.
Finalmente, cerramos con una tabla de "a dónde enviar qué tarea":
| Lo que quieres hacer | Cuál usar | Dónde se ejecuta el código |
|---|---|---|
| No configurar entornos, modificar un repositorio no clonado localmente | Versión en la nube | Nube de OpenAI |
| Ejecutar varias tareas independientes al mismo tiempo | Versión en la nube (cada una en un contenedor) | Nube de OpenAI |
| Dejar una tarea lenta y larga ejecutándose con la computadora apagada | Versión en la nube | Nube de OpenAI |
| Tocar archivos, herramientas o configuraciones locales | Local (CLI / App de escritorio / IDE) | Tu máquina |
| Delegar la tarea a la nube fácilmente mientras escribes código | Delegar desde la extensión del IDE | Nube de OpenAI |
Ahora deberías poder: explicar a otros la diferencia fundamental entre la versión en la nube y la versión local (dónde se ejecuta el código), comprender la línea de ensamblaje de 5 pasos de una tarea en la nube, configurar el script de configuración / variables de entorno / Secrets / caché, y tener claro cuándo abrir la red para el Agent y qué riesgos conlleva. Esta capacidad de "seguir trabajando incluso con la computadora apagada" es una pieza clave para incorporar realmente a Codex en tu flujo de trabajo diario.
El siguiente artículo 〈11 · Manual del proyecto AGENTS.md〉: probablemente hayas notado que en este artículo el Agent en la nube lee el archivo AGENTS.md del repositorio para trabajar, y que si deseas que la nube use la configuración local también debes escribirla en el repositorio... ¿Cómo debe redactarse exactamente este AGENTS.md para que Codex siga tus reglas ya sea en local o en la nube? El próximo artículo se centrará en explicar esto detalladamente. ¿Por qué no piensas primero en esto?: Si un nuevo compañero se hiciera cargo de tu proyecto, ¿cuáles son las tres primeras cosas que más desearías dejar por escrito para contarle?