Codex en app, VS Code, terminal o nube: dónde hacer cada tarea

Antes de escoger dónde abrir Codex, identifica qué archivos debe cambiar y con qué comprobarás el resultado. Una carpeta en tu ordenador, un proyecto abierto en VS Code y un repositorio conectado a la nube pueden contener versiones distintas del mismo trabajo.

Esta guía te ayuda a elegir el punto de partida. Compara flujos documentados por OpenAI y utiliza un pequeño ejemplo de código comprobado localmente. No es una prueba de velocidad o calidad entre los cuatro clientes.

Qué Codex abrir según tu tarea

Son recomendaciones prácticas. Las tareas se solapan: cambiar de ventana no convierte por sí solo un encargo en más fácil ni garantiza un resultado mejor.

La extensión oficial de Codex permite aportar archivos abiertos o selecciones y revisar los cambios en el editor. La CLI permite inspeccionar, editar y ejecutar comandos desde la terminal. Compartir VS Code con otro asistente no hace que ambos sean el mismo producto: comprueba qué extensión estás usando.

Si buscas «Codex desktop», la documentación actual presenta la app de escritorio de ChatGPT: dentro de ella puedes elegir Codex. Abrir la app y seleccionar una carpeta tampoco equivale a preparar un entorno remoto.

Separa tres decisiones: ventana, entorno y acceso

Puedes iniciar trabajo remoto desde una interfaz instalada en tu ordenador. Por eso, «uso la app» no basta para saber dónde están ejecutándose los comandos.

OpenAI distingue Local, Worktree y Cloud en sus modos de entorno de Codex. Local trabaja sobre la carpeta seleccionada; Worktree separa los cambios mediante Git; Cloud utiliza un espacio remoto preparado. Revisa esta selección antes de enviar el encargo, aunque conozcas bien la interfaz.

Trabajar en local no significa usar un modelo offline

«Local» describe dónde Codex puede leer archivos, modificarlos y ejecutar herramientas. La ejecución de esas herramientas y el procesamiento del modelo son dos partes distintas. Abrir una terminal en tu ordenador no demuestra que las respuestas se generen allí ni que el contenido nunca salga del equipo.

Por ejemplo, el test de Python de esta guía funciona sin una llamada a un modelo. Pedir a Codex que analice el código es otra operación, sujeta al proveedor y al acceso configurados. Si necesitas trabajar sin conexión, comprueba esa condición expresamente; no la deduzcas del nombre Local.

Cuándo conviene un worktree

Un repositorio Git guarda el historial del proyecto. Un worktree crea otra carpeta de trabajo vinculada a ese repositorio, de modo que puedas probar cambios separados de los que estás haciendo en tu carpeta habitual.

Tiene sentido, por ejemplo, si quieres que Codex explore una corrección mientras continúas con otra tarea. Requiere un proyecto con Git y sigue ejecutándose en el ordenador o entorno de desarrollo que contiene ese proyecto: no es una máquina Cloud por llamarse Worktree. La guía oficial de worktrees explica cómo revisar y trasladar esos cambios.

La nueva carpeta también debe estar preparada para ejecutar el proyecto. Puede necesitar dependencias o archivos de configuración que no estén guardados en Git. OpenAI documenta pasos de preparación para entornos locales; no des por hecho que una segunda carpeta hereda todo lo instalado o configurado en la primera.

Qué preparar antes de enviar una tarea a Codex Cloud

En Codex Cloud, el punto de partida es un entorno publicado: una configuración reutilizable que prepara repositorios, dependencias y herramientas para las tareas. «Publicado» aquí describe el estado del entorno dentro del servicio; no significa publicar tu aplicación en internet.

Si ya tienes acceso a uno, selecciónalo. Si debes crearlo, la documentación indica elegir los repositorios, completar su preparación, revisar las pruebas y publicar el entorno. Después puedes iniciar una tarea y revisar los archivos modificados, continuar con ajustes o abrir una propuesta de cambios —un pull request— cuando corresponda.

Cada tarea Cloud tiene sus propios archivos. Cambiarlos no actualiza automáticamente la configuración inicial para futuras tareas. Tampoco se transfieren por defecto las carpetas de tu portátil, sus procesos, sesiones del navegador o acceso VPN. Esta separación está descrita en los modos de entorno.

Una distinción adicional: ChatGPT Work dispone de acceso al ordenador local desde Work Cloud bajo requisitos propios de cuenta, permisos y sincronización, y necesita un equipo conectado para los pasos locales. Esa función no implica que cualquier tarea de Codex Cloud tenga acceso a tu portátil. Consulta la documentación de ChatGPT Work si ese es el flujo que tienes delante.

Un mismo encargo, dos preparaciones

Imagina que una función de tu proyecto recibe etiquetas como Plan PRO y debe devolver plan pro: minúsculas, sin espacios exteriores y con un solo espacio entre palabras. Debe conservar tildes y signos. Es un encargo pequeño cuyo resultado puedes comprobar antes de aceptar cambios.

Para preparar este ejemplo editorial se crearon tres archivos:

• labels.py: contiene la función que se quiere corregir.
• test_labels.py: comprueba seis resultados esperados.
• README.md: explica requisitos, alcance y cómo ejecutar la comprobación.

Para reproducirlo necesitas Python 3. Descarga el ejemplo de normalización de etiquetas en ZIP y consulta las instrucciones del ejemplo. Descomprímelo y usa la carpeta before para probar la versión inicial o after para comprobar la corrección con el mismo comando de abajo.

Un encargo concreto sería:

Revisa labels.py y corrige la normalización de espacios sin eliminar tildes ni signos. Conserva los casos de test_labels.py, ejecuta sus pruebas y muestra qué cambió. Si falta una herramienta, indícalo antes de presentar la tarea como terminada.

La tabla distingue la comprobación local realizada de la preparación documental propuesta para Cloud. No se ejecutó una segunda prueba remota ni se compararon respuestas de modelos.

Qué se comprobó realmente

El 4 de octubre de 2026 se ejecutó el ejemplo con Python 3.11.4 en Windows. La versión inicial, deliberadamente incompleta, pasó cuatro de las seis pruebas: falló al agrupar espacios interiores y al tratar tabulaciones/saltos de línea. Tras corregir la función, las mismas seis pruebas terminaron sin fallos.

El cambio de la operación principal fue este:

# Antes: deja intactos los espacios interiores.
return label.strip().lower()

# Después: agrupa espacios, tabulaciones y saltos de línea.
return " ".join(label.split()).lower()

El comando de comprobación, ejecutado desde la carpeta del ejemplo con sus archivos presentes, fue:

python -B -m unittest -v test_labels

Esta validación comprueba el código y sus seis casos, no que una interfaz de Codex sea superior a otra. La corrección se preparó con ayuda de Codex durante la elaboración editorial; no se lanzó una sesión adicional de modelo ni una tarea Cloud para medirlo. Tampoco se prueba con ello una transferencia entre la app, VS Code y la terminal.

Lo útil para tu trabajo es conservar esa misma exigencia al delegar: archivos identificados, resultado esperado, prueba ejecutable y cambios que puedas revisar. Si todavía no tienes un proyecto, la guía para crear una miniapp local con IA explica cómo acotar uno y qué necesitas para abrirlo.

El acceso y el coste se comprueban aparte

Para trabajo local con modelos de OpenAI, la app, la CLI y la extensión admiten iniciar sesión con una cuenta de ChatGPT o utilizar una clave API. Codex Cloud requiere iniciar sesión con ChatGPT. El acceso efectivo también depende del plan y, en organizaciones, de los permisos. Una clave API no desbloquea todas las funciones asociadas a un workspace de ChatGPT. Así lo diferencia la documentación oficial de autenticación.

Usar una clave API implica facturación de API; no consume un supuesto saldo incluido por abrir Codex desde tu suscripción. Antes de cambiar de ruta, revisa qué pagas con ChatGPT y qué se factura en la API. Elegir una ventana por comodidad y elegir cómo pagar son decisiones que conviene hacer por separado.

Antes de enviar tu próxima tarea

Comprueba estas cinco cosas en el flujo que hayas elegido:

1. Carpeta y versión: puedes identificar exactamente los archivos que recibirá el agente, incluida la rama o el worktree si usas Git.
2. Lugar de ejecución: sabes si la herramienta actuará sobre tu entorno local o sobre uno remoto preparado.
3. Prueba disponible: tienes un ejemplo de resultado correcto y las herramientas necesarias para comprobarlo.
4. Cuenta y permisos: reconoces el método de acceso, sus condiciones de consumo y qué cambios puede hacer el agente.
5. Revisión final: sabes dónde aparecerán el diff —las líneas modificadas— y el resultado de las pruebas antes de incorporar el cambio.

Con esa preparación, elige la interfaz en la que te resulte más fácil supervisar el trabajo. Si necesitas decidir si el flujo merece seguir usándose o pagando, aplica los criterios de cómo evaluar una herramienta de IA con una tarea concreta.

Si repites las mismas reglas o pasos en cada encargo, revisa cuándo usar instrucciones, skills, agentes o MCP para elegir qué añadir según el problema que necesitas resolver.

Documentación de producto consultada el 4 de octubre de 2026. Los nombres de interfaz, requisitos y disponibilidad pueden cambiar; las fuentes enlazadas permiten comprobarlos para tu cuenta.