Para usar Codex Cloud con GitHub, conecta el repositorio, prepara y publica un entorno, encarga un cambio acotado y revisa el diff, las pruebas y la pull request antes de integrar nada. El acceso depende del plan y los permisos del espacio de trabajo; el código propuesto sigue necesitando revisión.
Comprueba el acceso y el repositorio
OpenAI incluye Codex Cloud en sus planes Plus, Pro, Business y Enterprise/Education. El acceso mediante API key no está disponible, y también se aplican los permisos del espacio de trabajo. Consulta la tabla de disponibilidad de OpenAI antes de preparar el proyecto.
Elige un repositorio de GitHub que conozcas y cuyo flujo de pruebas puedas ejecutar. Así tendrás una referencia para valorar los cambios y detectar si falta alguna dependencia o servicio externo.
Prepara y publica el entorno
En el flujo de OpenAI, eliges los repositorios de GitHub, dejas que Codex prepare y pruebe el entorno, revisas la configuración y el informe de preparación, y publicas el entorno antes de iniciar una tarea. La documentación de entornos en la nube de OpenAI describe este proceso y cómo se conservan los estados de las tareas.
- Crea un entorno y selecciona el repositorio. Conecta GitHub si se te solicita y elige el proyecto que quieres usar.
- Revisa la preparación. Comprueba las dependencias, las herramientas y los comandos de prueba que Codex propone. Resuelve cualquier requisito de acceso o configuración que falte.
- Prueba y publica el entorno. La publicación guarda un punto de partida reutilizable para tareas nuevas; no despliega la aplicación.
- Inicia una tarea nueva desde ese entorno. Cada tarea nueva recibe un espacio de trabajo aislado basado en el entorno publicado. Si modificas la configuración reutilizable, vuelve a probarla y publicarla. Las tareas que ya existen conservan sus propios archivos y cambios.
Si buscas contexto sobre la reutilización de entornos, puedes leer la explicación de NeoTeo sobre los entornos reutilizables de Codex Cloud.
Encarga un cambio que puedas comprobar
En su recorrido, proflead parte de un ejemplo en JavaScript, pide primero una explicación del repositorio y después plantea una corrección concreta de límites de búsqueda. Para que el cambio sea revisable, conviene indicar el comportamiento esperado, los casos que podrían fallar, las pruebas que hay que ejecutar y qué partes del proyecto deben quedar intactas. El artículo de proflead describe ese flujo y sus recomendaciones de revisión.
Empieza con una tarea pequeña y verificable. Por ejemplo, si el cambio afecta a los límites de un array, concreta si el índice final debe incluirse y pide pruebas para los casos límite. Es una forma de acotar el encargo, no una garantía de que el código resultante sea correcto.
Revisa la pull request antes de integrarla
Inspecciona los archivos modificados y el diff completo. Ejecuta las pruebas del proyecto y comprueba tanto sus entradas como sus resultados. En GitHub, revisa la rama de origen y la de destino, la descripción de la pull request y los resultados de CI. Una indicación de que no hay conflictos con la rama base se refiere a la integración; la revisión del comportamiento del código sigue dependiendo del diff y las pruebas.
Si quieres revisar los cambios en tu equipo, comprueba primero si tienes trabajo local sin confirmar. El recorrido de proflead utiliza estos comandos para actualizar la información del repositorio y seguir la rama de la tarea:
git status
git remote -v
git fetch origin
git switch --track origin/your-task-branch
Sustituye your-task-branch por el nombre de la rama de la pull request y vuelve a ejecutar las pruebas en tu copia local.
Recursos, estado y límites de la nube
OpenAI especifica dos configuraciones predeterminadas de máquina virtual para las tareas. La diferencia de recursos puede ser relevante al valorar si el entorno encaja con las necesidades del proyecto.
| Grupo de planes | vCPU | Memoria | Disco |
| Plus y Edu Plus | 2 | 8 GiB | 8 GiB |
| Pro, Business, Enterprise, Edu y Edu Pro | 4 | 16 GiB | 32 GiB |
OpenAI indica que el estado guardado de una máquina virtual puede recuperarse durante un máximo de siete días desde que se inicia el último turno de la tarea o se reanuda. Ese estado no sustituye al control de versiones: conserva el trabajo de la tarea, mientras que Git permite gestionar los cambios del proyecto.
Los chats en la nube y los mensajes locales comparten el uso del plan. OpenAI advierte de que las tareas en la nube pueden consumir más y que el consumo varía según el modelo y la tarea.
Configura credenciales y acceso a la red
Una variable de entorno se entrega directamente a los programas del entorno. Un secreto de red, en cambio, se presenta como un marcador y un proxy sustituye ese marcador por la credencial real cuando la petición va a un destino HTTPS permitido por el puerto 443.
| Método | Qué recibe el programa | Destino y condición |
| Variable de entorno | El valor de la variable | Se pasa directamente al programa. |
| Secreto de red | Un marcador; el proxy sustituye la credencial | Destino HTTPS permitido por el puerto 443. |
Permitir un nombre de host no proporciona por sí solo credenciales ni permisos en el servicio. Configura por separado el destino de red y la autenticación que requiera el proyecto.
Una tarea en la nube tampoco hereda automáticamente la conexión VPN del portátil. OpenAI documenta una opción VPN configurada por separado con Tailscale; requiere coordinar las reglas de acceso de la VPN y los ajustes de red del entorno.
Los entornos en la nube no admiten actualmente el uso del ordenador o del navegador, GitLab ni GitHub Enterprise Server autohospedado. Si el proyecto depende de esas herramientas, comprueba ese límite antes de organizar el flujo de trabajo alrededor de Codex Cloud.
