En el DevDay del 29 de septiembre, OpenAI afirmó que los desarrolladores «pueden ejecutar Codex donde lo necesiten: en un ordenador, de forma remota desde el móvil o en la nube desde cualquier dispositivo». La frase del resumen del DevDay que más le importa a un equipo viene justo después: los entornos de desarrollo reutilizables «ayudan a que las tareas comiencen rápido y ofrecen a tu equipo una configuración compartida con ajustes y permisos aprobados». Codex en la nube está disponible en los planes Plus, Pro, Business, Healthcare, Education y Enterprise.
Para un desarrollador en solitario, esto resuelve la cuestión. Pero para un equipo que ya ejecuta Claude Code en una estación de trabajo, Codex en un servidor de integración y Gemini en el portátil de alguien, esto añade un destino más. Ahora el trabajo puede arrancar en la nube de OpenAI, en tu propia infraestructura o desde el móvil en el tren, y cada entorno mantiene su propio registro de lo ejecutado. Determinar qué agente está asignado a qué, qué ha finalizado y qué espera revisión suma un sitio más que comprobar. Por tanto, la pregunta relevante no es «¿en la nube o en local?», sino qué tareas corresponden a cada lugar y dónde debe centralizarse el registro de ese trabajo.
En resumen
Codex en la nube es la mejor opción para tareas de Codex que deben iniciarse al instante, continuar activas mientras el portátil está suspendido o lanzarse desde el teléfono, así como para equipos que buscan una configuración homologada en lugar de que cada miembro prepare su propia máquina. Tus propios Computers ganan cuando una tarea requiere Claude Code u otro Runtime ajeno a Codex, hardware superior a la máquina virtual predeterminada de tu plan, o capacidades que la documentación de OpenAI aún señala como no admitidas: repositorios de GitLab, uso del navegador o servicios privados accesibles mediante SSH o protocolos de base de datos. Ninguna de las dos opciones decide quién asigna el trabajo ni quién lo aprueba: esa responsabilidad permanece en el equipo, dentro de una Task.
Qué te ofrece un entorno en la nube de Codex
Según la documentación de OpenAI, un entorno en la nube «es la configuración reutilizable que emplean las tareas: repositorios, dependencias, herramientas y ajustes de acceso». Seleccionas los repositorios de GitHub y Codex los analiza, instala dependencias y herramientas, valida el flujo de trabajo y solicita cualquier dato que no pueda deducir. Tras revisar el informe de configuración, lo publicas. A partir de ese momento, cada nueva tarea se inicia desde ese sistema de archivos publicado en su propio espacio de trabajo aislado, y las tareas «pueden seguir funcionando mientras tu ordenador está suspendido».
El modelo de acceso está mucho más cuidado que un script de configuración con un token pegado. Las variables de entorno se transmiten directamente a los programas. Los secretos de red nunca llegan a los procesos: los programas reciben un marcador de posición (placeholder) y un proxy sustituye la credencial real únicamente en los destinos HTTPS autorizados. El acceso a internet es un ajuste que se activa y luego se delimita, ya sea mediante perfiles predefinidos para gestores de paquetes o con una lista personalizada de dominios. Los servicios privados son accesibles mediante una VPN (actualmente con soporte para Tailscale), y los espacios de trabajo Enterprise pueden solicitar conexiones OIDC para gestionar credenciales efímeras en la nube.
Iniciar el trabajo ofrece la misma flexibilidad. La visión general de Codex Cloud incluye la web, la aplicación de escritorio, dispositivos móviles y la CLI de Codex; además, los espacios de trabajo Enterprise con delegación en la nube pueden lanzar tareas mencionando a @ChatGPT en Slack o Microsoft Teams. Los entornos Enterprise se pueden compartir con todo el espacio de trabajo para que cualquier compañero arranque directamente con la configuración aprobada en lugar de tener que reconstruirla. En el trabajo con Codex, esto erradica una fuente habitual de discrepancias de configuración (setup drift).
El propio catálogo de OpenAI plantea la ubicación como una decisión específica para cada carga de trabajo y no como una solución única. Cada Dot dispone de su propia máquina en la nube, y la Agents API admite tanto entornos alojados por OpenAI como autoalojados, tal como explicamos en quién ejecuta los agentes. Ahora, Codex también se ejecuta en cualquiera de las dos ubicaciones.
Qué te ofrece un Sharkly Computer
Un Computer es un dispositivo, servidor o contenedor conectado donde un Agent puede ejecutar tareas. En palabras de la documentación de Sharkly Computers, este «proporciona el sistema operativo, los archivos, las credenciales, el acceso a la red y las herramientas que necesita un Agent». Un servicio local ligero lo registra, detecta los Runtimes instalados, recibe las ejecuciones en cola y transmite el progreso en tiempo real. Este servicio inicia la conexión hacia el exterior, por lo que una configuración habitual no requiere abrir puertos de entrada.
Hay tres propiedades fundamentales para esta comparativa. Primero, un mismo Computer puede exponer varios Runtimes: Sharkly admite Claude Code, Codex, Gemini, OpenCode, OpenClaw y Hermes; un ACP Runtime personalizado cubre cualquier herramienta que el servicio local no detecte de forma nativa, y un solo Computer puede dar servicio a múltiples Agents. Segundo, el aislamiento se gestiona por Task: en el modo Temporary cada Task cuenta con un directorio aislado y las ejecuciones sobre repositorios pueden recurrir a un worktree limpio, que es la forma en que los agentes en paralelo evitan conflictos de fusión; en el modo Specified, la ejecución reutiliza un directorio local configurado con sus dependencias, cachés y servicios locales ya operativos, procesando una tarea a la vez. Tercero, las credenciales te pertenecen: un Agent gestiona variables de entorno visibles y secretas, cada ejecución recibe únicamente el entorno y las credenciales autorizadas, y un Computer con visibilidad Personal se mantiene accesible únicamente para su propietario.
La contrapartida sincera es que el mantenimiento del host corre por tu cuenta. Si un Computer se desconecta, las nuevas ejecuciones esperan a que restablezca la conexión. La aplicación de escritorio puede impedir la suspensión del equipo y, en macOS, seguir ejecutándose con la tapa cerrada si el sistema lo tolera; sin embargo, las ejecuciones prolongadas y desatendidas corresponden a un servidor bajo tu control, tal como expusimos en ejecutar agentes de programación en remoto. La facturación no cambia: los Computers y los Runtimes no ocupan asientos en los planes de Sharkly, Sharkly no comercializa tokens y un Codex Agent utiliza el plan de ChatGPT o la clave de API con la que inicie sesión su CLI de Codex.
Codex en la nube o tu propio Computer: tabla de decisión
Cada una de las entradas sobre Codex en la nube que figuran a continuación proviene de la documentación de entornos en la nube de OpenAI a fecha del 30 de septiembre. Las entradas sobre Computer proceden de la documentación de Sharkly.
| El trabajo requiere | Mejor opción | Motivo |
|---|---|---|
| Una corrección iniciada desde el móvil con el portátil cerrado | Codex en la nube | Las tareas se inician desde el móvil y siguen procesándose mientras el equipo está suspendido |
| Una configuración aprobada idéntica para todo el equipo | Codex en la nube (compartido en un espacio de trabajo Enterprise) | Un único entorno publicado; cada tarea mantiene su propio espacio de trabajo aislado |
| Ningún mantenimiento de servidores o hosts | Codex en la nube | Codex prepara, prueba y ejecuta el entorno |
| Claude Code, Gemini, OpenCode u otro Runtime ajeno a OpenAI | Tu propio Computer | Un Computer puede alojar varios Runtimes de forma simultánea |
| Uso del sistema operativo o del navegador durante la tarea | Tu propio Computer | La documentación señala que el uso de ordenador y navegador aún no está admitido en entornos en la nube |
| Un repositorio en GitLab o GitHub Enterprise Server | Tu propio Computer | También figura como una limitación actual del servicio en la nube |
| SSH, protocolos nativos de bases de datos o DNS privado | Un Computer dentro de esa red | La VPN en la nube opera con HTTP y HTTPS sobre IPv4, sin soporte para DNS privado, SSH ni protocolos nativos de bases de datos |
| Hardware específico o capacidades superiores a la máquina virtual por defecto | Tu propio Computer o una solicitud en Enterprise | Los valores por defecto son 2 vCPU, 8 GiB de memoria y 8 GiB de disco en Plus; 4 vCPU, 16 GiB y 32 GiB en Pro, Business y Enterprise. Prestaciones superiores o personalizadas se tramitan con el equipo de cuentas de OpenAI |
| Un repositorio muy grande con un estado local costoso | Un Computer local en modo Specified | Reutiliza el directorio local existente en lugar de preparar una copia completa |
| Skills alojadas únicamente en tu portátil | Tu propio Computer | Las skills locales personales no se sincronizan con los entornos en la nube; las skills del repositorio sí |
Interprétalo como una decisión de dos vertientes: recurre a Codex en la nube cuando la tarea sea propia de Codex, sus dependencias sean públicas o accesibles mediante HTTPS permitido y quien la inicie pueda estar fuera de su puesto de trabajo. Utiliza tus propios Computers cuando la tarea demande un Runtime, un hardware o un entorno de red elegidos por un motivo técnico concreto.
Hemos omitido una fila de forma deliberada: «datos que no deben abandonar nuestra red». Ejecutar en tu propio Computer preserva el repositorio, las cachés y los secretos en hardware que tú controlas. Sin embargo, no evita que los prompts lleguen al proveedor del modelo, ya que cualquier dato que el Runtime envíe a este sigue saliendo al exterior. OpenAI marca el mismo límite en su oferta: la documentación de la Agents API aclara que «elegir un sandbox autoalojado no habilita el cumplimiento de ZDR (Zero Data Retention) en la Agents API». La ubicación determina dónde residen el código y las credenciales; la retención es un acuerdo contractual independiente con tu proveedor de modelos.
Entornos mixtos: aquí es donde el panel demuestra su valor
La mayoría de los equipos adoptarán ambos modelos. Las correcciones rápidas de Codex se iniciarán desde el móvil hacia un entorno en la nube, mientras que una migración que requiere la base de datos de staging se ejecutará como un Agent en un Computer integrado en la red. Es una separación lógica, pero genera dos registros de trabajo independientes.
Codex en la nube aísla las tareas por diseño: el acceso a una configuración compartida, según la documentación, «no concede acceso a la tarea de otro usuario». Es el criterio predeterminado idóneo para la privacidad. Sin embargo, también implica que se comparte la configuración pero no el progreso del trabajo, por lo que responder a «¿en qué están trabajando ahora mismo los agentes del equipo?», coordinando tareas en la nube y Computers, exige una solución externa. Conviene formalizar primero esta regla de enrutamiento:
Where does this Task run?
1. Needs a non-Codex Runtime -> Agent on a Computer
2. Needs SSH, a database protocol, or private DNS -> Computer inside that network
3. Needs GitLab, GitHub Enterprise Server, or browser use -> Computer
4. Codex work, allowlisted HTTPS, started away from a desk -> Codex cloud
5. Someone must accept the result -> a Task with an Assignee and a reviewer, wherever it ran
La quinta regla es la que permite gestionar esta coexistencia sin fricciones. En Sharkly, la Task constituye el registro central: el avance, el historial de ejecución, los bloqueos y el resultado final confluyen en ella, y cualquier ejecución pendiente de validación humana llega a la bandeja de entrada (Inbox) del responsable. Un Codex Agent y un Claude Code Agent sobre el mismo Computer reportan al mismo panel, cada uno interactuando con el modelo asignado a su Runtime. Para el trabajo procesado en Codex en la nube, el enlace conductor es la pull request: basta con incluir el identificador de la Task en el nombre de la rama o en el título de la PR para que la integración de GitHub de Sharkly vincule la PR con la Task, manteniendo la aprobación centralizada en un único lugar. Nuestro artículo sobre ejecuciones de agentes que superan tu jornada laboral detalla la gestión de revisiones en procesos desatendidos de larga duración.
Los agentes investigan, ejecutan, prueban y reportan. Las personas definen el rumbo, delegan permisos y aprueban los resultados. Ese principio no varía en función del lugar donde se ejecute el proceso.
Qué implica esto para tu configuración
Codex en la nube es una gran respuesta a «¿dónde debería ejecutarse Codex?». Sin embargo, no fue concebido para responder a «¿en qué está trabajando cada uno de nuestros agentes en los distintos Runtimes y quién validó el resultado?». Mantén un Computer para aquellas tareas que exijan tus propios Runtimes, hardware o red, confía a Codex en la nube el trabajo que empieza en el móvil o avanza con el portátil cerrado, y preserva un registro unificado para ambos.
Si tu objetivo es seguir aprovechando múltiples agentes de desarrollo sin atarte a un único ecosistema, ese es justamente el reto para el que fue diseñado Sharkly.
