Cómo crear un proyecto completo con GPT Codex Desktop desde cero (con la suscripción de $20)

Mucho se habla de GPT Codex y de la posibilidad de usarlo bajo una suscripción barata. En este artículo vamos a usarlo para crear un proyecto desde cero y, de paso, te voy a mostrar cómo la versión de escritorio de Codex te permite lanzar varias sesiones a la vez, avanzar en múltiples características del proyecto en paralelo y por qué quizás valga la pena usarlo en tu suscripción.

Todo lo que verás aquí está hecho con la suscripción de ChatGPT de $20. No voy a llevar el proyecto al 100%, pero sí te voy a mostrar cómo se añaden skills, MCPs y cómo se avanza en un proyecto de forma bastante cómoda con esta interfaz. Si quieres aprender a usar Codex Desktop de forma práctica, este es tu paso a paso.

Por qué la versión de escritorio cambia las reglas

Cuando entras a Codex, lo primero que ves es una sección para crear chats donde puedes preguntar cualquier cosa, al mismo estilo de ChatGPT. Por ejemplo, le puedes pedir "dame ideas de proyectos web como side projects" y obtienes una respuesta normal.

Pero el verdadero fuerte de este tipo de aplicaciones aparece cuando creas un proyecto y quieres lanzar múltiples agentes trabajando al mismo tiempo. Esa es la diferencia real frente a usar ChatGPT a secas.

Para este ejemplo vamos a crear un Developer Tool Directory: un sitio web donde se listen herramientas de IA, con un panel de control para mantenerlo actualizado.

Paso 1: Conectar tu carpeta de proyecto

Para empezar, solo necesitas arrastrar la carpeta de tu proyecto dentro del sidebar de Codex. Con eso ya estás trabajando desde ese directorio.

A partir de ahí, si creas un nuevo chat (con el ícono correspondiente), verás que la carpeta queda marcada para trabajar dentro de ella. Es decir, todo lo que el agente haga, lo hará en ese directorio.

Paso 2: Pedir la UI, el planning y el stack

Dentro del proyecto, le pedimos algo concreto:

"Voy a crear un sitio web que es un índice de herramientas para desarrolladores. Dame la UI y también dame el planning junto con el stack."

Típicamente Codex te va a sugerir el stack más popular: Next.js, componentes tipo shadcn, un ORM como Prisma y PostgreSQL. Pero obviamente puedes cambiarlo. Para este ejemplo vamos por algo simple:

• Frontend: Astro, puramente estático
• API: Go
• Base de datos: PostgreSQL

Con eso cambia el stack y ya tenemos una planificación inicial.

Paso 3: Trabajar en paralelo (el superpoder de Codex Desktop)

Como ya estamos ubicados en la carpeta, podemos referenciar archivos con @. Por ejemplo, @planning para que lea la planificación, y luego decirle: "empieza con la creación de la UI del frontend".

Y aquí viene lo interesante: además de eso, podemos abrir otro chat y pedirle que cree un deployment.md donde guarde cómo se desplegarán estos proyectos basándose en el planning.

Para no perderte entre tantas sesiones, conviene renombrar los chats. Clic derecho → "Cambiar nombre del chat". Así puedes tener:

• Un chat llamado despliegue
• Otro llamado frontend
• Otro llamado backend

Con esto ya estás trabajando en tres partes al mismo tiempo, dentro del mismo proyecto.

El deployment.md que genera Codex suele sugerir buenas opciones: Cloudflare Pages para el frontend y Railway para la API. Y lo bueno es que ambos proveedores tienen herramientas (skills) para desplegarse de forma automatizada.

Paso 4: Manejar las aprobaciones

Cuando Codex necesita una aprobación, coloca un aviso que debes confirmar. Le das clic y decides si lo permites o no.

Si no quieres estar diciendo sí o no en cada modificación, en la parte inferior puedes seleccionar acceso completo. Con esto el agente puede probar sus propios cambios y solo te preguntará cosas importantes como planificaciones; cualquier modificación de código la hace directamente.

Paso 5: Ejecutar y revisar lo construido

Cuando frontend y backend terminan de construirse, Codex lista los pasos al final y lo ideal es siempre comitear para ir guardando tus cambios.

Para probar lo hecho:

• En el frontend, le dices "ejecuta el frontend" y te indica en qué puerto está respondiendo. Puedes abrirlo desde la misma herramienta. En este caso generó un directorio con su banner, casos de uso, pros y contras... un buen punto de partida que luego habrá que mejorar.
• En el backend (corriendo, por ejemplo, en localhost:8080), al ser una API REST no hay nada visual, pero podemos pedirle documentación: "implementa la documentación con Swagger y haz testing del backend".

Paso 6: El navegador integrado de Codex (browser use)

Mientras Codex trabaja en el backend, podemos testear el frontend. La forma más directa:

"Intenta entrar en las páginas que están en el navbar y, si no existen, impleméntalas."

Aquí notarás un parpadeo en la pantalla: no es una simulación. Codex Desktop ya viene con un MCP de browser use que navega página por página, hace clics, toma screenshots y comprueba cosas como el responsive en móvil. Por eso te puede decir, por ejemplo, "las páginas existen, pero dos enlaces del navbar no están resolviendo por nombre".

Lo más importante de esto: Codex en su versión desktop ya trae un navegador propio para probar la interfaz sin necesidad de instalar nada de terceros.

Paso 7: Añadir MCPs desde el marketplace (ejemplo con Figma)

Supongamos que ya tienes un diseño de dashboard en Figma y quieres traerlo al proyecto. En Codex hay una sección llamada Plugins / Complementos donde puedes buscar el MCP de Figma y añadirlo con un clic.

El flujo es:

1. Vas a la sección de complementos, buscas "Figma" y le das al "+".
2. Le das en instalar; se abre una ventana, aceptas/permites y luego "abrir en Codex".
3. Verás mensajes como "Figma ya está listo" y "Figma ahora está conectado". Si lo buscas de nuevo, aparece con un check.

Para usarlo, en el chat del frontend escribes /mcp y verás la lista de MCPs instalados. Luego basta con algo como:

"Usando Figma MCP, implementa este dashboard en el frontend: [URL del diseño]"

Como Figma aún no está autenticado, te pedirá hacerlo desde la interfaz. Una vez listo, Codex monta el dashboard como una pantalla propia en /dashboard, distinta al directorio principal.

Paso 8: La terminal integrada y los comandos de Git

Mientras un MCP implementa el dashboard, puedes abrir otro chat y preguntar si existe un repositorio de Git. Pero quizás prefieras ejecutar tus propios comandos.

Para eso, Codex tiene un ícono de terminal. Al darle clic se abre una terminal de tu sistema (en Windows, por defecto, PowerShell).

Tip de configuración: puedes cambiar la shell por defecto. Ve a Configuración → pestaña General → busca "shell de terminal integrado". Por defecto está PowerShell, pero puedes cambiarlo a Git Bash, Command Prompt u otras herramientas instaladas en tu sistema.

Desde ahí ejecutas lo de siempre: git status, git init, pwd para saber dónde estás parado, etc. Es un complemento simple pero muy útil.

Paso 9: Instalar skills (Playwright CLI como ejemplo)

¿Qué es un skill? Básicamente es un markdown extra que le cargas a la IA y que esta toma como contexto para hacer algo mejor. Es como descargar el "prompt" de alguien más para que el agente trabaje de una manera distinta.

Por ejemplo, si no eres fuerte en UX/UI, puedes usar un skill como frontend-design que trae pautas para crear un mejor diseño. O, para testing, puedes usar un skill que ejecute pruebas en navegador de forma más eficiente.

Codex ya trae su propia herramienta de browser, pero quizás quieras ahorrar tokens. Para esos casos existe el skill de Playwright CLI (de Microsoft), que usa la consola y no consume tantos tokens como el MCP nativo de Codex.

La instalación:

1. Copia el comando del skill.
2. En el chat del frontend, abre la terminal (puedes presionar Ctrl + L para limpiarla).
3. Pega el comando y dale enter.
4. Te aparece una bienvenida; eliges dónde instalarlo (a nivel de proyecto), confirmas y listo.

Estos skills crean una carpeta .agents en el proyecto, y como Codex ya lee esa carpeta, queda preparado para usarlos.

Para llamar un skill, escribe el símbolo de dólar ($). Por ejemplo $playwright → aparece "Playwright CLI" → enter, y ya puedes pedirle lo que sea:

"Testea el login page y el register, y usa el modo headed."

El modo headed abre un navegador visible para que veas lo que está haciendo (por defecto Playwright CLI corre oculto y le pasa los resultados a la IA).

Paso 10: Añadir un MCP externo manualmente (ejemplo con TestSprite)

Si el MCP que necesitas no está en el marketplace, lo añades a mano desde Configuración → Servidores MCP. Ahí puedes ver los que ya tienes (Playwright, Supabase, Chrome DevTools, etc.) y agregar uno nuevo.

Como ejemplo usé TestSprite, un MCP que no solo testea el navegador, sino que crea los tests end-to-end en el frontend y añade grabaciones cuando un test falla. Ofrece cuenta gratuita, sin tarjeta.

El proceso para configurarlo:

1. En TestSprite, "Get started free" y creas cuenta (correo o Google).
2. "Create test" → testing local con MCP → continuar.
3. Te dan instrucciones para Cursor y Claude Code, pero en "otros IDEs" te dan un JSON. Esa sintaxis se traslada a la interfaz gráfica de Codex:
   • Nombre: Test Sprite
   • Comando: npx
   • Argumentos: el que indica la doc (@...)
   • Variable de entorno: la API key y su valor (la generas en "crea una llave").
4. Guardas y ya tienes el nuevo MCP.

Forma más rápida: en lugar de hacerlo manual, copia el comando de configuración, abre un nuevo chat y dile a Codex: "añade este MCP, esta es la clave: [API key]". Codex actualiza la configuración por ti y te pide reiniciar. En la versión de escritorio, recomiendo cerrar desde el tray (clic derecho → Exit) y volver a abrir.

Después de reiniciar, escribes /mcp y ahí está TestSprite. Para usarlo:

"Ayúdame a testear el frontend usando TestSprite."

Te lanza una URL donde escoges parámetros: frontend o backend, alcance del testeo (todo el código base), cuenta de prueba (opcional) y el puerto del proyecto (4321, el de Astro). Importante: te pide un PRD (resumen del proyecto: requerimientos técnicos, stack, idea general). Puedes generarlo fácil pidiéndole en otro chat: "crea un PRD del proyecto y guárdalo en un markdown".

A partir del PRD, TestSprite crea y ejecuta los tests, te da un reporte en Markdown con los que pasaron y los que no, e incluso puedes pedirle "revisa los tests que fallaron y vuelve a implementarlos".

Consejo clave: mientras un agente trabaja en el testing, no lo interrumpas editando código del mismo módulo, porque el test se puede romper. Aprovecha el paralelismo: si está testeando el frontend, trabaja en el backend, y viceversa.

Paso 11: Desplegar el backend en Railway con skills

Como el despliegue del backend no interfiere con el testing del frontend, vamos por ahí. En el planning ya nos había sugerido Railway.

1. Busca "Railway skills", llega a la documentación e instala el skill (con npx skills o el comando que indican).
2. En la terminal de Codex, pega el comando e instala el skill a nivel de proyecto.
3. Llama el skill con $railway → "use railway" → "despliega el backend en Railway".

Codex comprobará si tienes el Railway CLI instalado; si no, lo instala (o lo instalas tú buscando "Railway CLI" y copiando el comando para Mac/Linux/Windows con WSL, o con Scoop en Windows nativo). Luego railway login, autorizas en el navegador y listo.

Al desplegar, Railway crea un proyecto nuevo (en este caso, "Developer Tools Directory"), levanta PostgreSQL, despliega la API y sube el código.

Detalle a tener en cuenta: Railway despliega bien, pero en settings no conecta automáticamente con el repositorio. Es un inconveniente menor que resuelves con un clic. Vale la pena saberlo si crees que todo es 100% automático.

Bonus: si te registras por primera vez usando un enlace de referido, Railway suele dar $20 de prueba gratis para tener más margen al probar la plataforma.

Paso 12: Desplegar el frontend en Cloudflare Pages

Mientras el backend migra los SQL, el frontend puede desplegarse en paralelo.

1. Busca "Cloudflare skills" en la documentación para agentes. Es un repo abierto (muchos de estos proyectos funcionan así).
2. Instala con el comando npx. Te pedirá seleccionar skills: elige Cloudflare y Wrangler (para desplegar en Cloudflare Workers/Pages). No instales todos; solo los que necesitas.
3. Instala a nivel de proyecto.

Si el skill no aparece al llamarlo con $cloudflare, reinicia Codex. Luego:

"Despliega este frontend en Cloudflare Pages."

Si no estás logueado en Cloudflare en esa computadora, te lanza la ventana de login → review → autorizar. Confirmas con "me he autenticado, continúa" y, tras unos segundos, obtienes la dirección con el proyecto desplegado.

Para verificar, abre la URL del backend con /docs (ahí está la documentación desplegada) y revisa en la base de datos que las tablas se crearon. El despliegue es rápido porque son plataformas autogestionadas, pensadas para trabajar con agentes.

Paso 13: Conectar frontend y backend

Con ambos desplegados, el siguiente paso natural es conectarlos. Por ejemplo, el dashboard necesita autenticación y comunicación con la API.

No entro en todos los detalles aquí (la idea es enseñar cómo usar Codex), pero a partir de este punto puedes decirle algo como:

"Lee la carpeta del backend (o el despliegue en Railway) y actualiza."

O bien:

"$railway [dirección del backend], actualízalo e implementa la comunicación con la API."

Y el proyecto sigue avanzando.

Conclusión: por qué Codex Desktop es tan cómodo

De forma resumida, con Codex Desktop puedes:

• Ejecutar múltiples MCPs (Figma, TestSprite, browser use nativo).
• Instalar skills desde la terminal (Playwright CLI, frontend-design, Railway, Cloudflare).
• Trabajar en múltiples sesiones en paralelo dentro del mismo proyecto.
• Usar una terminal integrada y configurable.
• Aprovechar plataformas autogestionadas para desplegar rápido.

Y si a eso le sumas que Codex se actualizó con una pestaña de Conexiones que te permite usarlo desde el móvil, tienes un entorno bastante cómodo para desarrollar, sobre todo si vas a construir múltiples aplicaciones.

Esta es una de las suscripciones más baratas que hay de momento ($20), y con ella ya puedes desarrollar prácticamente cualquier tipo de aplicación. Si crees que falta algo o quieres ver cómo construir otro tipo de proyecto, déjalo en los comentarios y lo consideraré para un siguiente video.

¿Quieres profundizar en este flujo de trabajo? En fazt.dev puedes reservar asesorías personalizadas sobre cualquier tema. No olvides dejar un comentario con tus dudas o sugerencias para el siguiente video.