Probé los nuevos plugins de Codex de OpenAI — esta es la verdad

La notificación de Slack de un amigo desarrollador me llegó a las 11 PM un miércoles: "Codex acaba de lanzar plugins. Hay como 20+. Tienes que ver el de Build iOS Apps."

Estaba en plena sesión de un proyecto con Claude Code, tres agentes de profundidad en un flujo de trabajo paralelo, y mi primer instinto fue ignorarlo. Otro lanzamiento de funcionalidades. Otra jugada de ecosistema. Lo vería el fin de semana.

Entonces abrí la app de Codex, escribí /plugins, y vi lo que OpenAI había construido realmente. Esto no era un marketplace pegado al costado de una herramienta de programación. Era una arquitectura — skills, conectores de apps de terceros y MCP servers empaquetados en paquetes instalables que cambian fundamentalmente lo que Codex puede hacer de fábrica. Cerré mi sesión de Claude Code. Esto necesitaba toda mi atención.

He pasado los últimos dos días instalando cada plugin que pude conseguir, sometiendo el plugin Build iOS Apps a pruebas de estrés contra un proyecto real, y desarmando los archivos de manifest para entender cómo funciona realmente el sistema bajo el capó. Lo que encontré es un sistema de plugins que es simultáneamente más poderoso y más frustrante de lo que esperaba.

Aquí está todo — la arquitectura que lo hace interesante, la experiencia práctica que revela las brechas, y si esto cambia el panorama competitivo para herramientas de programación con IA en 2026.

Por qué este lanzamiento de plugins importa ahora mismo

OpenAI lanzó los plugins de Codex el 26 de marzo de 2026, con más de 20 integraciones disponibles en la app de Codex, CLI y extensión de VS Code. Ese timing no es accidental. El espacio de herramientas de programación con IA se ha estado fragmentando — Claude Code tiene sus equipos de agentes y su sistema de skills, Cursor tiene sus flujos de composer, y cada IDE importante está incorporando funciones de IA. OpenAI necesitaba una forma de hacer que Codex fuera indispensable.

Los plugins son su respuesta. Y es una respuesta inteligente, porque el verdadero problema con cada asistente de programación con IA no es la IA en sí — es la brecha de integración. Puedes tener el modelo más capaz del planeta, pero si no puede comunicarse con tu herramienta de gestión de proyectos, leer tus archivos de diseño o activar tu sistema de build, sigues copiando y pegando entre ventanas como si fuera 2023.

He estado viviendo exactamente con este dolor durante meses. Mi flujo de trabajo incluye Slack para comunicación de equipo, GitHub para control de versiones, Figma para referencias de diseño y Xcode para builds de iOS. Antes de los plugins de Codex, conectar todo esto requería configuraciones personalizadas de MCP servers o mucha alimentación manual de contexto. La promesa de los plugins es que alguien más ya hizo ese cableado — solo instalas y empiezas.

La pregunta es si esa promesa se sostiene en la práctica. Spoiler: en algunos lugares sí y en otros absolutamente no. Pero la arquitectura subyacente es lo suficientemente sólida como para que las asperezas se sientan corregibles, no fundamentales.

Antes de que te lleve por los plugins específicos que probé, necesitas entender cómo funciona realmente el sistema de tres capas — porque esa arquitectura determina todo sobre lo que los plugins pueden y no pueden hacer.

La arquitectura de tres capas: Skills, Apps y MCP Servers

Cada plugin de Codex es un paquete que contiene hasta tres tipos de componentes, y entender la distinción entre ellos me ahorró horas de confusión durante las pruebas. La mayoría de la cobertura sobre este lanzamiento trata a los "plugins" como un concepto monolítico. No lo son. Las tres capas sirven propósitos completamente diferentes.

Skills: la capa cerebral

Los skills son instrucciones reutilizables que le dicen a Codex cómo abordar tipos específicos de trabajo. Pueden ser tan simples como un prompt de texto — "Al hacer scaffold de un componente React, siempre usa interfaces de TypeScript en lugar de type aliases" — o tan complejos como un script de build de múltiples pasos que gestiona compilación, pruebas y despliegue.

Lo que hace a los skills diferentes de simplemente pegar instrucciones en tu prompt de sistema es la persistencia y la capacidad de compartir. Un skill vive dentro del paquete del plugin. Cualquiera que instale ese plugin obtiene el mismo skill. Y Codex carga los skills relevantes automáticamente según lo que estés haciendo, en lugar de requerir que recuerdes qué instrucciones aplican a qué tarea.

Probé esto con los skills del plugin Build iOS Apps, que incluyen un skill de depuración de iOS y un skill de scaffolding de proyectos. El skill de depuración no solo dice "ayúdame a depurar apps de iOS" — incluye conocimiento específico sobre la integración de Xcode Build MCP, problemas comunes de layout en SwiftUI, y cómo interpretar los notoriamente crípticos mensajes de error de Xcode. Cuando le pedí a Codex que depurara un problema de renderizado de layout en una preview de SwiftUI, invocó automáticamente el skill de depuración y recorrió el proceso de diagnóstico en un orden que tenía sentido.

La limitación: los skills son tan buenos como las instrucciones que contienen. Un skill mal escrito es peor que no tener skill, porque Codex seguirá instrucciones malas con confianza. No hay una capa de validación que verifique si el consejo de un skill es realmente correcto.

Apps: la capa de las manos

Las apps son conectores de servicios de terceros — las piezas que permiten a Codex comunicarse e interactuar con herramientas como Slack, GitHub, Notion, Gmail, Google Drive, Box, Figma, Linear, Canva y otras. Cuando instalas un plugin que incluye un conector de app, le estás dando a Codex la capacidad de leer información de ese servicio y realizar acciones en él.

Aquí es donde entra la autenticación. Cada conector de app requiere su propio flujo de autenticación, y durante mis pruebas, esto varió desde fluido (el OAuth de GitHub tomó unos diez segundos) hasta molesto (un conector me requirió generar manualmente un token de API, pegarlo y reiniciar el plugin). La experiencia de autenticación es inconsistente, y sospecho que variará significativamente dependiendo de qué servicio de terceros estés conectando.

Una vez autenticados, los conectores de apps funcionan bien. Conecté el plugin de Slack y le pedí a Codex que resumiera un canal donde mi equipo había estado discutiendo un problema de despliegue. Extrajo los últimos 50 mensajes, identificó la discusión técnica relevante, y me dio un resumen que realmente capturó el matiz — no solo "la gente habló sobre despliegues" sino "el equipo identificó una condición de carrera en el queue worker que se manifiesta bajo carga superior a 200 conexiones concurrentes." Ese nivel de comprensión contextual es genuinamente útil.

El conector de Figma es otro punto destacado. Poder referenciar un archivo de diseño directamente desde una sesión de programación — "iguala el espaciado de este frame de Figma" — elimina uno de los cambios de contexto más molestos en el desarrollo front-end.

MCP Servers: el sistema nervioso

Los servidores de Model Context Protocol son la capa de middleware que conecta Codex con herramientas de build externas, bases de datos, sistemas de monitoreo y cualquier otra cosa que necesite una conexión persistente y bidireccional. Si los skills son el cerebro y las apps son las manos, los MCP servers son el sistema nervioso que corre por debajo de todo.

El MCP server más importante en el ecosistema actual de plugins es Xcode Build MCP, que viene con el plugin Build iOS Apps. Este servidor gestiona tareas relacionadas con el build — listar targets, activar compilación, capturar la salida del build, y ejecutar la app en un simulador. Transforma Codex de una herramienta de sugerencia de código en algo más cercano a un operador de sistema de build.

He seguido el estándar MCP de cerca desde que Anthropic publicó la especificación, y ver que OpenAI lo adopta para los plugins de Codex es significativo. Significa que los plugins pueden aprovechar la misma infraestructura de MCP servers que Claude Code, Cursor y otras herramientas están construyendo. Un MCP server bien construido funciona en todo el ecosistema, no solo dentro de la herramienta de un proveedor.

La implicación práctica: si ya has configurado MCP servers para otra herramienta de programación, parte de esa configuración podría transferirse a los plugins de Codex. Probé esto con un MCP server personalizado que había construido para un flujo de monitoreo de base de datos, y con algunos ajustes en el manifest, funcionó dentro de una estructura de plugin de Codex. Esa portabilidad importa.

Instalar y gestionar plugins: cómo es realmente el proceso

El flujo de instalación tiene dos caminos, y sirven a diferentes audiencias. Entender qué camino usar me salvó de un falso inicio frustrante.

Camino 1: el directorio de plugins

Escribe /plugins en la interfaz de Codex y obtienes un directorio navegable de plugins disponibles. Cada listado muestra el nombre del plugin, una descripción, qué componentes incluye (skills, apps, MCP servers) y un botón de instalación. Haz clic en instalar, completa cualquier requisito de autenticación, y el plugin está activo inmediatamente.

El directorio actualmente incluye integraciones con:

• Comunicación: Slack (resumir canales, redactar respuestas, publicar actualizaciones)
• Diseño: Figma (referenciar diseños, obtener especificaciones de componentes, verificar espaciado)
• Gestión de proyectos: Linear (seguir issues, actualizar estado, referenciar tickets en el código)
• Documentación: Notion (obtener documentos de referencia, actualizar wikis, buscar bases de conocimiento)
• Almacenamiento: Google Drive (acceder a documentos, hojas de cálculo y presentaciones), Box (gestión de archivos)
• Email: Gmail (leer y gestionar correo dentro del contexto de programación)
• Código: GitHub (gestión de PRs, seguimiento de issues, búsqueda de código), Sentry (monitoreo de errores), Hugging Face (referencias de modelos)
• Herramientas de diseño: Canva (gestión de assets de diseño)
• Flujos de desarrollo: Build iOS Apps, Build macOS Apps

Una vez instalado, invocas un plugin usando el símbolo @ — @slack summarize #deployments o @figma show me the header component from the main design file. Esta convención es familiar de otras herramientas y funciona intuitivamente.

Algo que noté inmediatamente: no se muestra información de versiones para ningún plugin. No puedes saber cuándo se actualizó un plugin por última vez, qué cambió entre versiones, o si estás ejecutando la última versión. Para un sistema que se supone que está listo para producción, esto es una brecha real. Me he quemado suficientes veces con integraciones de herramientas desactualizadas como para considerar esto un riesgo significativo.

Camino 2: builds locales de plugins

Para plugins personalizados — o si quieres modificar uno existente — trabajas con un archivo de manifest y un directorio local de skills. El manifest es un archivo JSON que declara lo que el plugin contiene:

{
  "name": "my-custom-plugin",
  "description": "Custom workflow for my iOS development process",
  "skills": [
    {
      "name": "swift-conventions",
      "type": "prompt",
      "content": "When writing Swift code for this project, always use async/await instead of completion handlers. Prefer struct over class unless reference semantics are required. Use SwiftUI previews for every view component."
    }
  ],
  "mcp_servers": [
    {
      "name": "xcode-build",
      "command": "npx",
      "args": ["xcode-build-mcp"]
    }
  ]
}

El enfoque basado en manifest es poderoso porque permite combinar múltiples skills en un solo paquete instalable. Ya tengo un conjunto de convenciones de programación, scripts de build e instrucciones específicas de proyecto dispersas en varios archivos de configuración. Empaquetarlos en un plugin significa que puedo instalar toda mi configuración de flujo de trabajo con un solo comando en una máquina nueva — o compartirlo con un miembro del equipo que se une a un proyecto.

La instalación de plugins locales consiste en apuntar Codex a tu archivo de manifest. Lee la declaración, configura los MCP servers necesarios, carga los skills y hace todo disponible a través del mismo patrón de invocación @.

Lo que falta en ambos caminos es un sistema adecuado de dependencias. Si el Plugin A requiere una versión específica de MCP server que entra en conflicto con los requisitos del Plugin B, estás por tu cuenta resolviendo el conflicto. Esto no me ha afectado aún con los 20+ plugins actuales, pero a medida que el ecosistema crezca, se convertirá en un problema.

Probando el plugin Build iOS Apps: donde la teoría se encuentra con la realidad

El plugin Build iOS Apps fue el que me hizo cerrar todo lo demás y prestar atención, así que le di la prueba más exhaustiva. Este plugin agrupa varios skills — incluyendo un depurador de iOS y un scaffolder de proyectos — con el Xcode Build MCP server para crear un flujo de trabajo para construir aplicaciones nativas de iOS desde Codex.

La configuración

Tenía una app macOS existente — una herramienta de presentaciones en Markdown en la que había estado trabajando — y quería probar si el plugin podía portarla a iOS. Esta es una tarea real que había estado posponiendo durante semanas porque gestionar proyectos Xcode multi-target es una de esas tareas lo suficientemente tediosas como para seguir empujándola al "próximo sprint."

Creé una nueva rama de Git (aprendí por las malas a nunca dejar que herramientas de IA operen en mi rama principal), abrí el proyecto en Codex, instalé el plugin Build iOS Apps y le pedí que añadiera un target de iPhone a mi app de presentador Markdown existente.

Lo que funcionó

El scaffolding fue genuinamente impresionante. El plugin creó un target de app iOS, configuró la configuración de build, estableció código compartido entre los targets de macOS e iOS, y generó las vistas iniciales de SwiftUI — todo a través de la integración de Xcode Build MCP. No toqué Xcode ni una vez durante la configuración inicial.

El ciclo build-test es donde el plugin demostró su valor. Codex escribía código, activaba un build a través del MCP server, capturaba la salida del build, identificaba errores y los corregía — todo en un ciclo continuo. La herramienta xcodebuild de Apple puede listar schemes y ejecutar acciones de build, test y archive desde la terminal, y el MCP server aprovecha esto para mantener a Codex en un bucle agéntico en lugar de requerir que yo salte a la GUI de Xcode.

Lo vi resolver cuatro errores de build consecutivos — un import faltante, un type mismatch, un uso de API obsoleta y un entitlement faltante — sin mi intervención. Cada vez, leyó la salida del error, identificó la causa, aplicó una corrección y reconstruyó. Ese ciclo me habría tomado quince minutos de forcejeo con Xcode. Codex lo manejó en unos noventa segundos.

Lo que no funcionó

Aquí tengo que ser honesto, porque las demos hacen que esto se vea más fluido de lo que es la realidad.

La app de iPhone que el plugin produjo era funcional en el sentido más estricto — compilaba, se lanzaba en el simulador y mostraba diapositivas de mis archivos Markdown. Pero la UI era tosca. Los colores de fuente no estaban optimizados para las características de pantalla del iPhone. La reproducción de diapositivas era buggy — las transiciones tartamudeaban, y ocasionalmente una diapositiva se renderizaba con dimensiones incorrectas. Los elementos de control (botones siguiente/anterior, un indicador de progreso) estaban posicionados para una ventana de macOS y se veían incómodos en una pantalla de teléfono.

Algunos de estos problemas provienen del desafío fundamental de portar un concepto de app de escritorio a móvil. El skill de scaffolding del plugin asume cierta arquitectura de app, y cuando tu app existente no coincide con esas suposiciones, el código generado se adapta mal. Mi presentador Markdown usa lógica de renderizado personalizada que el scaffolder no contempló completamente.

El skill de depuración identificó algunos de estos problemas de UI cuando los señalé, pero no pudo corregirlos todos de forma autónoma. El problema de color de fuente requería entender la relación entre las configuraciones de apariencia de la app y el manejo de modo claro/oscuro de iOS — un matiz que las instrucciones del skill no cubrían con suficiente profundidad.

¿Y los bugs de renderizado en la reproducción de diapositivas? Resultaron ser un problema de timing de Core Animation específico a la forma en que había implementado las transiciones. El skill de depuración sugirió correcciones genéricas (ajustar duraciones de animación, verificar violaciones del hilo principal), pero la corrección real requería entender mi implementación específica. Comprensible — ningún skill puede anticipar cada codebase.

El veredicto sobre Build iOS Apps

El plugin es un punto de partida sólido pero no una solución terminada. Maneja el tedioso trabajo de configuración — creación de targets, configuración de build, estructura de código compartido — mejor que cualquier herramienta que haya usado. El ciclo de build a través de Xcode Build MCP es genuinamente poderoso y ahorra tiempo real. Pero el código iOS generado necesita refinamiento significativo antes de tener calidad de producción.

Lo calificaría en aproximadamente 60-70% del camino hacia una app lista para publicar. Ese último 30-40% — el pulido, las optimizaciones específicas de plataforma, los casos extremos — todavía requiere experiencia humana. Llamarlo "aún no listo para producción" es preciso, pero llamarlo inútil sería profundamente injusto. Comprimió lo que habría sido un proyecto de portabilidad de dos días en una sesión de refinamiento de cuatro horas.

Construir tu propio plugin: la parte de la que nadie habla

La mayoría de la cobertura sobre este lanzamiento se centra en los plugins preconstruidos. Eso pierde la historia más interesante: la capacidad de crear plugins personalizados que empaquetan tus flujos de trabajo existentes en paquetes compartibles e instalables.

Decidí construir un plugin que combina tres cosas que uso constantemente: mis convenciones de programación en Swift, un script de build-and-run para mi estructura de proyecto estándar, y una conexión a MCP server para inspección del estado de la base de datos. Antes de los plugins, estas cosas vivían en archivos de configuración separados y requerían configuración manual en cada proyecto nuevo.

Paso 1: define tus skills

Comienza con los skills — las instrucciones reutilizables que tu plugin proporcionará. Creé tres:

Un skill de convenciones de código que codifica la guía de estilo Swift de mi equipo: convenciones de nombres, patrones de arquitectura (MVVM con coordinators), requisitos de pruebas (cada función pública obtiene un test unitario), y directrices específicas de SwiftUI (preview providers para cada vista, environment objects sobre singletons).

Un skill de script de build que contiene los comandos shell reales para compilar, probar y ejecutar la app. Esto no es un prompt — es un script que Codex ejecuta a través del MCP server. Maneja el ciclo de vida completo del build: clean, build, ejecutar tests, generar reportes de cobertura y lanzar la app en el simulador con configuraciones específicas de dispositivo.

Un skill de flujo de depuración que define un enfoque sistemático para problemas comunes: verificar primero los logs de build, luego la salida de consola, luego el memory graph, luego los traces de instruments. Este orden refleja cómo realmente depuro problemas después de años de desarrollo iOS, y codificarlo como skill significa que Codex sigue el mismo proceso.

Paso 2: conecta los MCP Servers

El archivo de manifest declara qué MCP servers necesita el plugin. Para mi plugin, eso es el Xcode Build MCP (para operaciones de build) y un MCP server personalizado de SQLite que construí para inspeccionar el estado de la base de datos local durante el desarrollo.

{
  "name": "ios-dev-workflow",
  "description": "Complete iOS development workflow with Swift conventions, build automation, and database inspection",
  "skills": [
    {"name": "swift-conventions", "file": "skills/swift-conventions.md"},
    {"name": "build-script", "file": "skills/build-script.sh", "type": "script"},
    {"name": "debug-workflow", "file": "skills/debug-workflow.md"}
  ],
  "mcp_servers": [
    {
      "name": "xcode-build",
      "command": "npx",
      "args": ["xcode-build-mcp"]
    },
    {
      "name": "sqlite-inspector",
      "command": "node",
      "args": ["./mcp-servers/sqlite-inspector/index.js"]
    }
  ]
}

Paso 3: prueba e itera

Instala el plugin localmente, ejecútalo contra un proyecto real y observa dónde falla. Mi primera versión tenía un conflicto de skills — el skill de convenciones de código decía "siempre usa async/await" mientras que el script de build estaba escrito con patrones de completion handler. Codex siguió ambas instrucciones y generó código confuso e híbrido. Corregir esto significó asegurar que todos los skills dentro de un plugin sean internamente consistentes.

El ciclo de iteración para plugins personalizados es rápido. Edita un archivo de skill, reinstala el plugin, pruébalo. Sin paso de compilación, sin proceso de build. Son solo archivos de configuración y scripts.

El poder de la composición

Lo que me entusiasma genuinamente de los plugins personalizados es el potencial de composición. Puedo empaquetar todo mi flujo de desarrollo iOS en un plugin. Un colega que trabaja en Android puede empaquetar el suyo. Instalamos los plugins del otro e instantáneamente heredamos las mejores prácticas y automatizaciones del otro.

Esta es la misma idea detrás de los sistemas de skills en otras herramientas — he escrito sobre cómo skills.sh funciona con los agentes de Claude Code — pero la implementación de Codex agrega las capas de conectores de apps y MCP servers, haciendo que los plugins sean más pesados pero más capaces.

Para equipos que necesitan estandarizar su proceso de desarrollo, esta es la verdadera propuesta de valor. No la integración preconstruida de Slack — tu equipo puede configurarla en diez minutos de todas formas. El valor está en codificar el conocimiento acumulado de tu equipo en un paquete que cada nuevo miembro del equipo puede instalar en su primer día.

Si prefieres que alguien construya este tipo de flujo de trabajo de desarrollo personalizado desde cero, acepto proyectos de herramientas de IA y automatización. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Cómo se comparan los plugins de Codex con la competencia

No puedo evaluar los plugins de Codex de forma aislada porque estoy usando activamente otros tres ecosistemas de plugins/skills. La comparación importa porque tu elección de herramienta de programación con IA depende cada vez más de qué ecosistema tiene las integraciones que necesitas.

Codex Plugins vs. Claude Code Skills

El sistema de skills de Claude Code es más maduro para flujos de trabajo de programación pura. Los skills en Claude Code están profundamente integrados con el modelo de agentes — pueden generar sub-agentes, gestionar contexto a lo largo de sesiones largas, y aprovechar el fuerte razonamiento de Claude para decisiones arquitectónicas complejas. He estado usando equipos de agentes de Claude Code para tareas de refactorización de múltiples archivos, y la coordinación basada en skills es algo que los plugins de Codex aún no pueden igualar.

Donde ganan los plugins de Codex es la capa de conectores de apps. Claude Code no tiene integración nativa de Slack, Figma o Linear en el mismo formato empaquetado. Puedes configurar MCP servers para esos servicios manualmente, pero la experiencia de instalación con un clic de los plugins de Codex es significativamente más fluida para equipos que quieren integración sin configuración.

Codex Plugins vs. Cursor Composer

El enfoque de Cursor es diferente — se centra en la integración nativa del IDE en lugar de la extensibilidad mediante plugins. Cursor es excelente para entender el contexto de tu codebase y generar código que encaje, pero no tiene un marketplace de plugins ni un mecanismo para compartir skills. Si tus necesidades van más allá de la generación de código — integración con gestión de proyectos, referencias de archivos de diseño, automatización de builds — Cursor requiere herramientas externas.

La apuesta del ecosistema

La evaluación honesta: el ecosistema de plugins de ninguna herramienta es completo todavía. Uso Codex por sus conectores de Slack y Figma, Claude Code por su arquitectura de agentes y profundidad de razonamiento, y Cursor por su integración con el IDE. Consolidar en una sola herramienta significaría perder capacidades que uso diariamente.

La apuesta de OpenAI es que el ecosistema de plugins crecerá lo suficientemente rápido para hacer de Codex la única herramienta que no necesitas abandonar. Esa apuesta depende enteramente de si los desarrolladores de terceros construyen plugins de alta calidad — y ahora mismo, la publicación de plugins por cuenta propia aún no está disponible. OpenAI ha curado los más de 20 plugins iniciales, pero el ecosistema necesita abrirse antes de poder competir con la amplitud de MCP servers disponibles para Claude Code.

Las brechas que necesitas conocer

He sido positivo sobre la arquitectura, y quiero equilibrar eso con las limitaciones reales que encontré. Estas no son quejas menores — son problemas que determinarán si los plugins se vuelven centrales en tu flujo de trabajo o se quedan como algo agradable de tener.

Sin versionado de plugins. Esta es la brecha más grande. Cuando un plugin se actualiza, no tienes forma de saber qué cambió, si podría romper tu flujo de trabajo, o cómo volver a una versión anterior. Para desarrolladores individuales experimentando, esto es molesto. Para equipos que dependen de plugins en flujos de trabajo de producción, es un riesgo genuino.

Autenticación inconsistente. Algunos plugins se autentican fluidamente a través de OAuth. Otros requieren generación manual de tokens y pegado. Al menos un plugin que probé requería reiniciar Codex después de la autenticación para captar las nuevas credenciales. Esto necesita estandarización.

Sin gestión de dependencias. Los plugins no pueden declarar dependencias de otros plugins o versiones específicas de MCP servers. A medida que el ecosistema crece y los plugins comienzan a compartir infraestructura, esto creará conflictos.

Reportes de errores limitados. Cuando un plugin falla, los mensajes de error son a menudo genéricos — "plugin execution failed" sin detalles sobre qué componente (skill, app o MCP server) realmente falló. Depurar problemas de plugins requiere más prueba y error de lo que debería.

Solo macOS para la app de Codex. La experiencia completa de plugins requiere la app de escritorio de Codex, que actualmente solo funciona en macOS con Apple Silicon. La CLI y la extensión de VS Code soportan plugins, pero la experiencia es reducida — pierdes el directorio visual de plugins y algunos de los flujos de autenticación. Las pruebas alfa de Windows han comenzado, pero el soporte para Linux no está en el horizonte todavía.

Qué significa esto para tu flujo de trabajo en 2026

El sistema de plugins de Codex no va a reemplazar tu configuración de herramientas existente de la noche a la mañana. Así no es como funciona la adopción de herramientas de desarrollo. Pero sí cambia la matriz de decisión para equipos que evalúan asistentes de programación con IA.

Si ya estás usando Codex y tu flujo de trabajo involucra Slack, GitHub, Figma o cualquiera de los otros servicios integrados, instala los plugins relevantes inmediatamente. El tiempo ahorrado solo en cambios de contexto justifica los diez minutos de configuración.

Si estás comparando Codex con Claude Code o Cursor, el sistema de plugins se convierte en un diferenciador significativo — pero solo si las integraciones específicas que necesitas están disponibles. Revisa el directorio de plugins antes de tomar una decisión, no después.

Si eres un líder de equipo pensando en estandarizar una herramienta de programación con IA, la capacidad de plugins personalizados es la función a evaluar más cuidadosamente. La capacidad de codificar las convenciones de tu equipo, procesos de build y patrones de integración en un paquete instalable es un genuino multiplicador de productividad. Transforma el onboarding de "lee la wiki y descifra nuestra configuración" a "instala este plugin y empieza a programar."

Y si eres un constructor de herramientas o desarrollador de MCP servers, esta es una señal del mercado. OpenAI está apostando al mismo estándar MCP que Anthropic promovió. Construir para MCP significa que tu integración funciona en todo el ecosistema, no solo dentro del jardín cerrado de un proveedor.

El sistema de plugins se lanzó hace tres días. Algunas de mis quejas se abordarán en actualizaciones. Otras representan decisiones arquitectónicas que no cambiarán rápidamente. Pero la base — skills para conocimiento, apps para integración, MCP servers para infraestructura — es sólida. Lo que se construya encima en los próximos seis meses determinará si los plugins de Codex se vuelven esenciales o simplemente interesantes.

Planeo construir un plugin personalizado que envuelva mi flujo de trabajo completo de desarrollo con IA — skills de Claude Code, MCP servers que he construido para herramientas de base de datos y monitoreo, y conectores de apps para los servicios de los que depende mi equipo. Cuando esté listo, compartiré el manifest y recorreré todo el proceso de construcción.

Por ahora, los más de veinte plugins disponibles en el lanzamiento valen la pena instalarlos y probarlos. Comienza con los que se conectan a servicios que ya usas diariamente. El plugin de Slack por sí solo ya me ha ahorrado más tiempo del que costó todo el proceso de pruebas.

La guerra de herramientas de programación con IA ya no se trata de qué modelo genera el mejor código. Se trata de qué herramienta se integra más fluidamente en la forma en que ya trabajas. Los plugins son el movimiento más fuerte de OpenAI para ganar esa guerra — imperfectos hoy, pero arquitectónicamente posicionados para mejorar mucho muy rápido.

Preguntas frecuentes

¿Qué son los plugins de OpenAI Codex?

Los plugins de Codex son paquetes instalables que agrupan tres tipos de componentes — skills (instrucciones reutilizables), apps (conectores de servicios de terceros) y MCP servers (middleware para herramientas de build y sistemas externos) — en flujos de trabajo compartibles. Se lanzaron el 26 de marzo de 2026, con más de 20 integraciones disponibles en la app de Codex, CLI y extensión de VS Code.

¿Cómo instalo plugins de Codex?

Escribe /plugins en la app de Codex para navegar el directorio de plugins. Selecciona cualquier plugin, completa el flujo de autenticación si es necesario, y queda disponible inmediatamente a través del símbolo @. Para plugins personalizados, crea un archivo JSON de manifest declarando tus skills y MCP servers, luego apunta Codex al archivo local.

¿Puedo construir mis propios plugins de Codex?

Sí. Los plugins personalizados usan un archivo de manifest que declara skills (prompts de texto o scripts), conectores de apps y configuraciones de MCP servers. No se necesita compilación — edita el manifest y los archivos de skills, instala localmente y prueba. La publicación por cuenta propia en el directorio oficial de plugins aún no está disponible a marzo de 2026.

¿El plugin Build iOS Apps produce código listo para producción?

Todavía no. El plugin maneja bien el scaffolding de proyectos, configuración de build y configuración multi-target, y su integración con Xcode Build MCP permite ciclos de build-test poderosos. Pero el código de UI generado necesita refinamiento significativo — espera dedicar tiempo a pulir layouts, corregir problemas de renderizado específicos de la plataforma y optimizar para las características de pantalla de iOS.

¿Cómo se comparan los plugins de Codex con los skills de Claude Code?

Los skills de Claude Code ofrecen coordinación de agentes más profunda y razonamiento más fuerte para tareas de programación complejas. Los plugins de Codex agregan conectores de apps de terceros (Slack, Figma, Linear) y una experiencia de instalación con un clic que la configuración manual de MCP de Claude Code no puede igualar. Los dos sistemas sirven fortalezas diferentes — ninguno reemplaza completamente al otro a marzo de 2026.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io