Skip to content

Plugins (Plugins): instalar capacidades integradas sin configurar variables una a una

📚 Navegación de la serie: El artículo anterior [22 · Habilidades de los agentes (Skills)] te enseñó a escribir "manuales de instrucciones específicos" para Codex: guías que le indican cómo resolver determinadas tareas. Sin embargo, a medida que avanzas, surge un inconveniente: las habilidades, configuraciones de MCP o integraciones de aplicaciones se configuran una a una. En este capítulo aprenderás a unificarlas en Plugins (plugins): paquetes que se instalan, desactivan o comparten de forma integral. En el próximo artículo [24 · Reglas y ganchos (Hooks)] explicaremos cómo configurar puntos de control automáticos en Codex.

Hoy hablaremos de una funcionalidad que puede parecer secundaria pero que en la práctica es imprescindible: los plugins.

Se suele pensar que los plugins son solo una comodidad para empaquetar archivos y que no son urgentes antes de dominar las funciones básicas. En realidad ocurre lo contrario. Yo mismo cometí este error: en abril de 2025 configuré en un proyecto una habilidad para procesar migraciones de bases de datos y generar esquemas junto con un servidor MCP para conectar herramientas internas; me llevó dos horas. Dos semanas más tarde, quise reutilizar la misma lógica en otro repositorio: copié los archivos del proyecto antiguo uno a uno, pero omití una variable de entorno de .mcp.json; la conexión falló y perdí otra media hora depurándola. Gestionar elementos sueltos es tedioso y propenso a errores.

Los plugins son la solución oficial de Codex a este problema: encapsular habilidades, integraciones de apps y servidores MCP en un único paquete distribuible de instalación inmediata. Si diseñas una capacidad en el proyecto A y la empaquetas como plugin, estará disponible en el proyecto B o en el sistema de tus compañeros al instante, sin copiar carpetas ni perder configuraciones.

Al terminar este artículo, obtendrás:

  • Las tres categorías de recursos que empaqueta un plugin y el criterio de elección frente a habilidades simples.
  • Cómo explorar e instalar desde el directorio de plugins (Plugin Directory) mediante la terminal (CLI) o la app de escritorio.
  • Cómo añadir un mercado de plugins, instalar perfiles en la CLI e invocarlos con @ (con comandos y resultados esperados).
  • La estructura de directorios de un plugin (.codex-plugin/plugin.json y carpetas asociadas) para diseñar tus propios paquetes.
  • La auditoría de seguridad indispensable antes de instalar plugins de terceros o autorizar sus ganchos (Hooks).

01 Comprender primero: qué empaqueta realmente un plugin

Definamos el concepto de entrada: un plugin es un directorio autocontenido que empaqueta flujos de trabajo reutilizables (habilidades, integraciones de aplicaciones y servidores MCP) para gestionarse, compartirse o desactivarse de forma unificada.

¿Por qué son útiles? Porque las configuraciones sueltas implican tres problemas principales: dificultad de reutilización entre proyectos, compartición manual laboriosa entre compañeros e imposibilidad de actualizaciones centralizadas. Si configuras una habilidad y un servidor MCP en un proyecto, trasladarlos a otro requiere copiar los ficheros manualmente; compartirlos con tu equipo exige documentar dónde colocar cada recurso y qué variables modificar. Los plugins encapsulan todo en un único paquete para moverlo o transferirlo con facilidad.

Analogía: El paquete de habitación de Ikea. Imagina que deseas adquirir el estudio de la exposición: escritorio, estantería, flexo y organizadores. Comprarlos por separado exige buscar las referencias de cada pieza, validar las dimensiones y organizar la distribución tú mismo. Ikea te ofrece la opción de adquirir el "conjunto de estudio" completo: realizas un único pedido y, al ensamblarlo, obtienes la habitación idéntica a la exposición. Los plugins de Codex siguen esta filosofía: empaquetar múltiples capacidades aisladas en un paquete integrado para cargarlas juntas sin configurar variables una a una.

La documentación oficial detalla tres categorías de componentes integrables, resumidos en esta tabla:

ComponenteDefiniciónUso tras la instalación
Skills (Habilidades)Directrices de texto reutilizables para tareas específicas, acompañadas de scriptsCargado automáticamente por Codex según la consulta o invocado con @
Apps (Integraciones)Conectores con herramientas como GitHub, Slack o Google Drive para leer y actuarRequiere autorizarse en ChatGPT al instalar o en el primer uso
MCP serversServidores externos para dotar de herramientas o datos a CodexPuede requerir parámetros de configuración o credenciales adicionales

Nota que un plugin de Codex integra estas tres categorías: habilidades, conectores de apps y servidores MCP. Coincide con la línea de herramientas detallada anteriormente: el artículo 22 sobre escritura de habilidades, las explicaciones de MCP y las integraciones de aplicaciones (Apps) para conectar recursos externos (Gmail, Drive, Slack). Los plugins se limitan a unificarlos en un paquete.

¿Cuándo elegir un Skill o un Plugin? Sigue el criterio recomendado en la documentación oficial: si estás diseñando el flujo o trabajando de forma aislada en un único repositorio, limítate a un Skill local; si deseas compartir la capacidad con tu equipo, empaquetar conectores de apps con configuraciones de MCP o publicar una versión estable, utiliza un Plugin.

DimensiónSkill local (uso personal)Plugin (distribuible)
Casos idóneosUn único repositorio, flujos personales o pruebas de diseño rápidasCompartir con el equipo, empaquetar apps y MCP de forma integrada o publicar versiones estables
ComponentesTípicamente una sola habilidadMúltiples habilidades, apps y servidores MCP junto con Hooks de ciclo de vida
DistribuciónTransferencia manual de archivosA través del mercado de plugins o compartido en el espacio de trabajo
Control de versionesNo contemplado formalmenteGestionado mediante la clave version

Regla práctica: usa un Skill simple para flujos personales; si vas a compartirlo, empaquetar recursos o publicar versiones estables, utiliza un Plugin. Evita diseñar un plugin para un Skill temporal de un solo uso para no añadir complejidad innecesaria.

💡 Resumen en una frase: Un plugin de Codex empaqueta habilidades, apps y servidores MCP en un paquete integrado; usa un Skill simple para flujos personales, y diseña un plugin para compartir recursos, agrupar configuraciones o publicar versiones estables.


02 Por qué empaquetar capacidades es mejor que configurarlas por separado

Definido el concepto, analicemos sus ventajas, ya que podrías pensar que copiar archivos manualmente sigue siendo sencillo.

Las diferencias principales se agrupan en tres aspectos prácticos:

1. Reutilización entre proyectos. Como en el error de sintaxis que cometí al inicio: trasladar las habilidades de migraciones y la conexión de MCP a otro proyecto exigía copiar las carpetas skills/ y el archivo .mcp.json uno a uno; omitir una variable de entorno bloqueó la conexión en el nuevo repositorio. Empaquetar el recurso como plugin permite cargarlo de golpe en un nuevo proyecto desde el mercado sin perder configuraciones.

2. Compartición con el equipo. Compartir configuraciones sueltas con compañeros suele requerir instrucciones del tipo "copia esta carpeta aquí y edita la configuración de MCP así", lo que provoca errores de suposición frecuentemente. Los plugins resuelven esto: los publicas en un mercado de plugins (incluso interno privado) o los compartes en la app de escritorio de Codex con tu espacio de trabajo; los compañeros los instalan con un clic y obtienen exactamente la misma configuración, evitando incompatibilidades.

3. Gestión y control de versiones centralizados. Los plugins admiten la clave version para actuar como paquetes formales; tras instalarlos, puedes activar, desactivar o regular los permisos de sus servidores MCP asociados en tu propio archivo de configuración de Codex, sin alterar los archivos del plugin. Modificar configuraciones sueltas exige avisar a todos los usuarios para que actualicen sus archivos manuales.

Analogía: El perfil de configuración de los teléfonos de empresa. Al entregarte un dispositivo móvil de trabajo, el administrador de sistemas no te pide configurar manualmente el Wi-Fi de la oficina, las cuentas de correo, las VPN o instalar certificados uno a uno. Te envía un perfil de configuración único: lo aceptas y todos los parámetros se aplican de golpe; para revocarlos, basta con borrar el perfil. Un plugin es este perfil para tus configuraciones de Codex: permite aplicarlas juntas, gestionarlas centralmente y eliminarlas con facilidad.

Comparativa de flujos de trabajo:

Tarea❌ Elementos sueltos✅ Plugins
Migrar a un nuevo proyectoCopiar archivos manualmente, propenso a omitir variablesInstalación directa desde el mercado con configuración integrada
Compartir con compañerosInstrucciones de copia y pegado manualesPublicación o compartición directa en el espacio de trabajo con un clic
Gestión de actualizacionesExige avisar a cada usuario para modificar archivosControl centralizado mediante números de versión e interruptores

El valor de los plugins aumenta con el número de colaboradores y proyectos. Al coordinar equipos de desarrollo, los plugins simplifican procesos: preparar el entorno para un nuevo desarrollador pasa de requerir guías complejas a ejecutarse con una sola orden de instalación.

💡 Resumen en una frase: Las ventajas principales de los plugins son la portabilidad entre proyectos, la compartición directa en equipos y la actualización centralizada, simplificando configuraciones complejas a gran escala.


03 El directorio de plugins: el "mercado de aplicaciones" integrado

¿Cómo obtener plugins de terceros? Utiliza el directorio de plugins (Plugin Directory), la interfaz integrada de Codex para buscar e instalar recursos.

Organiza los plugins en tres secciones:

Analogía: Las secciones de una tienda de aplicaciones. Dispones de una pestaña de "destacados" (recomendados oficialmente para todos), otra de "compartido en familia/equipo" (perfiles transferidos por tu organización) y la sección de "mis apps" (desarrollados o importados por ti). El directorio de Codex sigue la misma estructura:

SecciónContenido
Curated by OpenAI (Destacados de OpenAI)Plugins auditados oficialmente y abiertos a todos los usuarios
Shared with you (Compartidos contigo)Plugins compartidos por los miembros de tu espacio de trabajo de ChatGPT
Created by you (Creados por ti)Plugins desarrollados por ti o añadidos localmente a tu espacio de trabajo

Puedes explorar e instalar desde la app de escritorio o la CLI:

Desde la app de escritorio: abre el panel Plugins para buscar e instalar integraciones con un clic en Add to Codex.

Desde la CLI: inicia una sesión y abre el gestor de plugins escribiendo (nota que es en plural plugins):

text
codex
/plugins

El explorador en la CLI agrupa los plugins por mercados (marketplaces), permitiendo alternar de pestaña; abre un perfil para revisar su ficha e instalarlo, o pulsa la tecla Espacio en plugins instalados para activar o desactivar su ejecución.

Tras la instalación, dispones de dos métodos de uso:

  • Consultas en lenguaje natural: describe la tarea directamente (p. ej. "resume mis correos no leídos en Gmail" o "descarga la documentación desde Google Drive") y Codex elegirá el plugin adecuado automáticamente.
  • Invocación directa con @: si deseas usar una herramienta o habilidad específica, escribe @nombre_de_plugin en el chat para cargarlo sin dejar que Codex elija.

Esta sintaxis con @ es idéntica a la invocación de Skills explicada en el artículo 22; las habilidades integradas en un plugin se invocan de la misma forma.

💡 Resumen en una frase: El directorio de plugins actúa como catálogo de utilidades agrupadas en tres categorías; gestiónalo desde la app de escritorio en Plugins o en la CLI escribiendo /plugins e invoca los recursos indicando el resultado en chat o declarándolos con @.


04 Gestión de permisos y flujos de datos en plugins

¿Basta con pulsar instalar en el menú de plugins? No es tan simple; la instalación del plugin no implica la concesión automática de permisos de acceso.

La especificación oficial define la pauta: instalar un plugin solo habilita sus flujos de trabajo en Codex, respetando los permisos y estrategias de aprobación generales de tu sesión. El plugin nunca omitirá las restricciones del sandbox del artículo 15 o los límites de seguridad del artículo 16.

El acceso varía según la categoría del componente:

ComponenteComportamiento tras la instalación
SkillsDisponibles al instante sin requerir credenciales o pasos de autorización
AppsRequiere autorizar el conector e iniciar sesión en ChatGPT al instalar o en el primer uso
MCP serversPuede requerir credenciales de acceso o configuraciones de red adicionales para funcionar

En definitiva: las habilidades se ejecutan directamente, mientras que las apps y servidores MCP requieren autorizaciones adicionales. Revisa qué componentes integra el plugin para prever las configuraciones necesarias.

Una advertencia sobre la privacidad: cuando Codex transmite datos a través de una aplicación integrada en un plugin, se aplican los términos de servicio y políticas de privacidad de esa aplicación específica. La transmisión de datos a servicios externos (GitHub, Slack, Drive) se rige por sus políticas particulares, que debes verificar antes de enlazarlas.

Analogía: El instalador de la cerradura inteligente. Descargar la aplicación de domótica en el móvil equivale a instalar el plugin; sin embargo, para abrir la puerta física, requieres escanear el código de seguridad de la cerradura (autorización de la app); y configurar el guardado en la nube exige introducir las credenciales de tu cuenta (credenciales de MCP). Instalar la app es el paso inicial, y dar accesos a cada dispositivo externo son pasos independientes. El modelo de permisos en plugins distingue rigurosamente la instalación de la autorización.

Para eliminar o pausar un plugin, dispones de dos alternativas:

  • Eliminación definitiva: abre la ficha en el explorador de plugins y selecciona Uninstall plugin. Ten en cuenta: desinstalar el plugin solo borra el paquete local, conservando los conectores de apps en ChatGPT, los cuales debes revocar manualmente en sus ajustes.
  • Desactivar temporalmente: para conservar el plugin sin ejecutar sus recursos, edita ~/.codex/config.toml agregando enabled = false bajo su identificador y reinicia Codex:
toml
[plugins."gmail@openai-curated"]
enabled = false

Nota la sintaxis de la clave: nombre_de_plugin@mercado. gmail indica el plugin y openai-curated el mercado de origen. Pulsar Espacio en el explorador de la CLI edita esta misma línea automáticamente.

💡 Resumen en una frase: La instalación no confiere permisos de forma desatendida: las habilidades son inmediatas pero las apps y MCP exigen confirmación independiente, respetando los permisos generales de la sesión; puedes desinstalar el paquete o apagarlo en config.toml cambiando enabled = false.


05 Práctica: añadir un mercado, instalar un plugin e invocar sus recursos

La teoría sin práctica no sirve. Conectaremos un mercado de plugins desde la CLI, instalaremos un paquete e invocaremos sus recursos con @.

A diferencia de la app visual, la gestión de mercados en la CLI utiliza la familia de comandos codex plugin marketplace; son comandos de la consola del sistema, no comandos dentro de la sesión de chat, evita confundirlos.

Primer paso: Añadir un mercado

El método convencional es enlazar repositorios de GitHub. Sustituye owner/repo por la dirección real:

bash
codex plugin marketplace add owner/repo

Formatos adicionales compatibles:

bash
codex plugin marketplace add owner/repo --ref main
codex plugin marketplace add https://github.com/example/plugins.git --sparse .agents/plugins
codex plugin marketplace add ./local-marketplace-root

Los orígenes admiten sintaxis reducidas de GitHub (owner/repo), direcciones Git por HTTP/HTTPS o SSH y rutas locales del sistema. Utiliza --ref para fijar versiones Git específicas y --sparse PATH para clonar directorios parciales en repositorios Git.

Segundo paso: Comprobar los mercados registrados

bash
codex plugin marketplace list

Resultado esperado: se listan los mercados registrados en Codex y sus rutas absolutas. Visualizar el mercado añadido confirma el correcto funcionamiento.

Comandos de administración complementarios:

bash
codex plugin marketplace upgrade                 # Actualizar todos los mercados
codex plugin marketplace upgrade marketplace-name # Actualizar un mercado específico
codex plugin marketplace remove marketplace-name  # Eliminar un mercado registrado

Tercer paso: Abrir el explorador e instalar el plugin

Inicia la sesión y abre el explorador:

text
codex
/plugins

Resultado esperado: se abre el menú agrupado por mercados; navega a la pestaña del mercado que has añadido, entra en la ficha del plugin deseado y pulsa Install plugin.

Cuarto paso: Invocación con @

La documentación oficial especifica: inicia un nuevo hilo (new thread) tras instalar el plugin para poder usarlo. Describe la tarea en el chat o fuerza su uso escribiendo @ seguido del nombre o habilidad del plugin:

text
@<nombre_de_plugin_o_habilidad>

Resultado esperado: Codex carga las instrucciones y capacidades del plugin. Si integra conectores de apps o MCP, solicitará iniciar sesión o autorizar los accesos en ChatGPT para completar la carga.

Completar este flujo verifica el ciclo: "añadir mercado → instalar plugin → iniciar hilo e invocar". Es la base para gestionar cualquier plugin en Codex, variando únicamente el entorno gráfico en la app de escritorio.

⚠️ Si el carácter @ no lista el plugin, comprueba que has iniciado un nuevo hilo de chat tras la instalación. Para conectores externos, confirma que los pasos de inicio de sesión y autorización se han completado.

💡 Resumen en una frase: Agrega mercados con codex plugin marketplace add en la consola, instala seleccionando Install en /plugins e invócalo iniciando un nuevo hilo y escribiendo @ en el chat; probar la secuencia práctica consolida los conceptos.


06 Empaquetar tus propios plugins: estructura del directorio del paquete

Una vez analizado el uso, revisemos la estructura de almacenamiento interna si decides empaquetar tus propios Skills y configuraciones de MCP en un plugin.

El método más directo es usar la habilidad integrada @plugin-creator, diseñada para generar la plantilla base del plugin: crea el archivo obligatorio .codex-plugin/plugin.json e inicializa un registro en el mercado local para pruebas. Es el punto de partida recomendado.

La estructura de directorios consta de dos componentes principales: el archivo de metadatos obligatorio y las carpetas de recursos.

El manifiesto de metadatos se guarda en .codex-plugin/plugin.json con la siguiente estructura básica:

json
{
  "name": "my-first-plugin",
  "version": "1.0.0",
  "description": "Reusable greeting workflow",
  "skills": "./skills/"
}

La clave name es esencial: define el espacio de nombres e identificador del plugin, requiriendo el formato kebab-case (letras minúsculas unidas por guiones, como my-first-plugin). Los parámetros skills, mcpServers, apps y hooks apuntan a sus carpetas respectivas mediante rutas relativas declaradas con ./.

Las carpetas de componentes se estructuran en la raíz del plugin bajo el siguiente esquema oficial:

RecursoRuta de almacenamientoVariable del manifiesto
Habilidad (Skill)skills/<nombre>/SKILL.mdskills
Hook de ciclo de vidahooks/hooks.jsonhooks (omitible si usa la ruta por defecto)
Servidor MCP.mcp.json en la raíz del pluginmcpServers
Conector de App.app.json en la raíz del pluginapps
Iconos o capturas de pantallaCarpeta ./assets/Referenciado bajo la clave interface

La estructura de carpetas consolidada del plugin se asemeja a:

text
my-first-plugin/
├── .codex-plugin/
│   └── plugin.json        ← Manifiesto obligatorio
├── skills/
│   └── hello/
│       └── SKILL.md
├── .mcp.json              ← Configuración de MCP (raíz)
├── .app.json              ← Conectores de Apps (raíz)
└── hooks/
    └── hooks.json

Una consideración crítica de diseño detallada en la documentación oficial:

Únicamente el archivo plugin.json debe ubicarse dentro de .codex-plugin/. Conserva las carpetas skills/, hooks/, assets/ y los archivos .mcp.json o .app.json en la raíz del plugin.

En resumen: el directorio .codex-plugin/ solo admite el archivo plugin.json; los demás componentes se sitúan en la raíz externa, al mismo nivel que .codex-plugin/. Guardar por ejemplo la carpeta skills/ dentro de .codex-plugin/ impedirá la carga de la habilidad aunque el plugin figure como activo.

Dos detalles útiles de simplificación de código:

  • Hooks automáticos: si almacenas el Hook en ./hooks/hooks.json, puedes omitir la clave hooks en el manifiesto, ya que Codex buscará la ruta predeterminada automáticamente.
  • Metadatos de publicación: los manifiestos oficiales de mercados suelen incorporar claves como author, homepage, license y el objeto interface (que regula iconos, colores de marca o prompts de inicio en la UI). Son opcionales y basta con el manifiesto mínimo para desarrollo.

Nota que el diseño coincide con la estructura de directorios de Skills y MCP. Los plugins se limitan a agrupar los recursos de desarrollo en un paquete estructurado. Por tanto, puedes desarrollar localmente en tus directorios de Skills y trasladarlos después a un plugin con la misma sintaxis.

💡 Resumen en una frase: Un plugin consta del manifiesto .codex-plugin/plugin.json (identificador en kebab-case) y las carpetas de recursos externas; recuerda colocar únicamente el archivo plugin.json en .codex-plugin/, situando los Skills, conectores y archivos .mcp.json en la raíz externa; utiliza @plugin-creator para acelerar la creación.


07 La barrera de seguridad: confirmación manual para los Hooks

Esta sección es breve pero esencial: complementa directamente las advertencias de seguridad del artículo 16.

Los principios de seguridad del artículo 16 se aplican en su totalidad aquí. Un plugin puede integrar conectores de apps (con accesos de escritura a cuentas externas), servidores MCP (herramientas locales activas) o Hooks de ciclo de vida (que ejecutan scripts locales en respuesta a eventos del chat). Todos operan dentro de tus límites de permisos.

Por protección, los Hooks no se ejecutan automáticamente al instalar o activar el plugin. La documentación oficial detalla:

Instalar o activar un plugin no autoriza sus Hooks asociados. Los Hooks empaquetados en un plugin se consideran no gestionados, por lo que Codex los omitirá hasta que el usuario revise e indique confiar en sus definiciones de forma explícita.

Esta protección impide que, al instalar por descuido un plugin con Hooks maliciosos, estos se ejecuten de forma silenciosa: Codex detendrá la sesión solicitando tu revisión antes de autorizarlos. Analizaremos la gestión de Hooks en el artículo 24; conserva aquí la noción de que no se autorizan de forma automática.

Analogía: El altavoz inteligente de un remitente desconocido. Al recibir un altavoz de una marca que no conoces y conectarlo al enchufe, se encenderá (el plugin se instala y sus habilidades están disponibles); sin embargo, para enlazarse al Wi-Fi de tu casa o leer tus cuentas de usuario, exige que confirmes cada permiso en la aplicación. De lo contrario, se limitará a funcionar como altavoz local aislado. Los Hooks integrados en plugins siguen el mismo principio: residen en el sistema pero requieren tu confirmación previa para ejecutarse.

Reglas de seguridad básicas antes de integrar plugins externos:

VerificaciónAcción
Origen fiablePrioriza la sección oficial Curated by OpenAI; comprueba los autores en el espacio de trabajo; evita mercados de repositorios públicos desconocidos
Componentes integradosRevisa la ficha del plugin antes de instalar para confirmar si añade apps, servidores MCP o Hooks
Auditoría de HooksSi integra Hooks, inspecciona las instrucciones en la alerta de Codex antes de autorizarlas; evita la aprobación ciega

El diseño de seguridad protege tus límites: los plugins del espacio de trabajo no se exponen al exterior; los Hooks exigen tu auditoría; e instalar un plugin no altera tus políticas de sandbox. Sin embargo, la seguridad final depende de tu criterio: instala únicamente recursos de confianza.

Nota sobre el estado de desarrollo (sujeto a cambios oficiales): la publicación en el catálogo oficial abierto figura como "próximamente disponible (coming soon)" en la documentación. Actualmente la distribución se limita a repositorios específicos en mercados o compartidos en el espacio de trabajo, manteniendo los orígenes relativamente acotados.

💡 Resumen en una frase: Los plugins pueden incorporar apps, MCP y Hooks en tus directorios, pero Codex restringe su acceso: los Hooks no se ejecutan automáticamente hasta ser validados por el usuario; audita el origen, contenido y Hooks asociados de antemano.


08 Resumen

En este artículo hemos revisado los plugins: paquetes versionados que unifican habilidades, conectores de aplicaciones y servidores MCP para gestionarse de forma integrada.

Repasemos las pautas consolidadas:

ObjetivoCanal / HerramientaNoción clave
Qué es un pluginAgrupa Skills, Apps y servidores MCPUsa un Skill simple para flujos personales, y diseña un plugin para compartir o versionar
Orígenes de pluginsCatálogo integradoPestañas: Curated by OpenAI, Shared con el espacio de trabajo y creados por ti
Explorar e instalarPanel Plugins o /pluginsAgrega mercados en la terminal con codex plugin marketplace add
Invocación de recursosConsultas directas o @Inicia un nuevo hilo tras instalar; requiere autorizar apps o MCP externos
Desactivar perfilesArchivo config.tomlDeclara [plugins."nombre@mercado"] enabled = false y reinicia
Estructurar paquetes.codex-plugin/plugin.json y carpetasUbica solo plugin.json en .codex-plugin/, situando los demás recursos en la raíz externa
Auditoría de seguridadPrincipio de prevenciónIncorpora permisos externos; los Hooks integrados requieren aprobación expresa del usuario

Visualiza los flujos consolidados en el siguiente esquema:

Anatomía de los plugins de Codex

Esquema: La línea superior describe los cuatro pasos del flujo del usuario (mercado → instalar → nuevo hilo → invocar); la inferior desglosa el contenido del paquete (habilidades, apps, MCP y Hooks) junto con sus condiciones de acceso.

Ahora deberías ser capaz de: elegir entre un Skill local y un plugin; conectar mercados, instalar paquetes e invocarlos con @ en la CLI; comprender los permisos de apps, MCP y Hooks; estructurar la jerarquía de directorios de tus desarrollos; y auditar recursos de terceros antes de autorizar ganchos. Esta flexibilidad te permite integrar herramientas prediseñadas en tu entorno de trabajo al instante.

Con AGENTS.md, MCP, Skills y Plugins has completado la suite de personalización y orquestación de Codex.


El próximo artículo [24 · Reglas y ganchos (Hooks)]: hemos mencionado que los Hooks de plugins no se ejecutan hasta ser auditados, pero queda detallar qué es un Hook, a qué eventos se asocia y cómo funciona la confirmación manual. En el siguiente capítulo explicaremos: cómo configurar puntos de control automáticos en Codex en respuesta a lecturas de archivos, comandos de consola o aperturas de chat, haciendo obligatorias las directrices de desarrollo. Automatizar comprobaciones antes de confirmar cambios simplifica el mantenimiento.


Lecturas recomendadas