Cuando trabajas con un flujo editorial automatizado, llega un punto en el que los archivos sueltos dejan de servir. Pierdes historial, duplicas señales y no puedes justificar decisiones después. Por eso necesitas conectar Codex con Supabase y diseñar un plan de persistencia antes de tocar una sola tabla.

¿Cómo instalar el plugin de Supabase en Codex?

La conexión empieza desde el panel de plugins de Codex. Ahí buscas Supabase, lo instalas y dejas que el flujo te lleve al login.

El proceso es directo:

1. Entra a plugins dentro de Codex y busca Supabase.
2. Da clic en install y luego en conectar.
3. Inicia sesión con tu cuenta (yo lo hice con GitHub) y autoriza el acceso.

Cuando termines, Codex te confirma que Supabase está conectada. Vuelves al chat y le pides que verifique la conexión. Si todo salió bien, te responde que el conector MCP de Supabase está autenticado y respondiendo [02:00].

¿Qué es MCP en Codex? Es el protocolo que Codex usa para hablar con servicios externos como Supabase. Cuando está autenticado, Codex puede listar tablas, ejecutar SQL y validar tu proyecto sin que tú salgas del chat.

¿Por qué usar el plan mode antes de crear tablas?

Una base de datos real no perdona improvisaciones. Si le pides a Codex que cree cosas sin un plan, terminas con tablas mal nombradas, datos duplicados o secretos guardados donde no deben.

El plan mode resuelve eso. En este modo, Codex no tiene permisos para escribir en el repositorio. Solo puede explorar, proponer y hacerte preguntas. Lo activas de dos formas: con shift + tab o escribiendo el comando /plan [02:30].

Una vez dentro, le pasas un prompt que cubra todo lo que necesitas: conexión por plugin, proyecto de desarrollo, tablas mínimas, variables de entorno, server side para la API, una nueva skill para guardar señales y la modificación de la skill de búsqueda para que persista resultados automáticamente. También le pides que marque riesgos y pasos que requieren aprobación.

¿Qué preguntas hace Codex en plan mode?

Antes de entregarte el plan, Codex te consulta decisiones clave para no asumir nada. En mi caso me preguntó dos cosas concretas.

La primera fue qué estrategia usar para el proyecto Supabase de desarrollo. Las opciones eran: crear uno dedicado, usar uno existente o un solo plan compartido. Fui con la recomendada, crear un proyecto nuevo, para no mezclar datos ni costos con aplicaciones existentes.

La segunda pregunta fue sobre el stack tecnológico para el API server: Next.js, Node con Express o un script simple. También elegí la recomendada, Next.js.

¿Qué incluye un buen plan de persistencia con Supabase?

El plan que Codex devolvió tenía piezas concretas, no genéricas. Eso es lo que diferencia un plan útil de una lista de buenas intenciones.

Los componentes que entregó fueron:

• Crear un proyecto nuevo en Supabase usando el MCP para crearlo, verificarlo, listar tablas y revisar advisors.
• Definir los endpoints del API en Next.js.
• Crear tres tablas con los campos mínimos: runs, signals y sources.
• Configurar un archivo seguro de ambiente con todas las API keys.
• Crear una nueva skill para guardar señales y modificar la skill de búsqueda existente.
• Añadir una etapa de validación al final.

¿Qué es una skill en Codex? Es una capacidad reutilizable que Codex ejecuta dentro de tu aplicación, como buscar fuentes o guardar señales. Modificar una skill existente significa cambiar su comportamiento sin reescribirla desde cero.

¿Cómo decidir entre mantener o limpiar el contexto al ejecutar el plan?

Después de aprobar el plan, Codex te da tres opciones para implementarlo y cada una tiene consecuencias distintas sobre el resultado.

Las tres opciones son:

1. Empezar inmediatamente usando todo el contexto previo, incluyendo el plan y la conversación anterior.
2. Limpiar el contexto (en mi caso iba en 31% usado) y arrancar una sesión nueva solo con el plan.
3. Continuar dentro del plan mode sin ejecutar todavía.

La primera opción sirve cuando la conversación previa aporta información útil para la ejecución. La segunda es la mejor cuando antes del plan hubo discusiones que no aportan a la implementación; ahí conviene arrancar limpio. Yo elegí la segunda: Codex cerró la sesión, abrió una nueva y mandó el plan como prompt inicial [05:30].

¿Cómo verificar que Supabase quedó bien configurado?

Después de varios minutos, Codex termina la implementación. La verificación se hace directamente en Supabase, no en el chat.

Entras al proyecto recién creado y vas a la pestaña de edición de tablas. Ahí debes ver las tres tablas: runs, signals y sources. Codex ya migró información usando el MCP SQL de Supabase, pero deja una nota importante: la variable de ambiente local con el API key todavía no existe. Sin esa variable, tu aplicación local no puede comunicarse con Supabase aunque las tablas ya estén listas.

Ese es el reto que queda abierto: agregar la Supabase API key a la variable de entorno y probar los diferentes endpoints. Si te trabas, puedes pedírselo directamente a Codex o revisar la clase específica de Supabase en los recursos. ¿Tú con cuál opción de contexto te irías al ejecutar un plan así? Cuéntame en los comentarios.