Los mejores plugins para OpenCode 2

Con OpenCode 2 llegó una API de plugins nueva, y los plugins escritos para la versión 1 dejaron de ejecutarse. Así que la pregunta ya no es solo qué plugins merecen la pena, sino cuáles funcionan hoy.

Para contestarla he instalado OpenCode 2.1.2 desde cero, sin nada más, y he cargado uno a uno los plugins de esta guía. Los cinco destacados los he puesto a trabajar de verdad sobre un proyecto pequeño, con GLM-5.3 a través de Ollama Cloud, y lo que ves en las capturas es lo que salió en la terminal.

🗓️ Revisado el 22 de octubre de 2026 con OpenCode 2.1.2. Los diez plugins de la lista cargan con la API de la versión 2. Los que recomendábamos antes y no tienen versión para la 2 están en su propia sección, al final.

Si todavía no has usado OpenCode, empieza por el tutorial de OpenCode en español. Y si aún no has actualizado, lee antes qué trae OpenCode 2 y cómo actualizar.

En este artículo vas a ver:

• Cómo se instalan y se gestionan los plugins en OpenCode 2
• Qué pasa con los plugins de la versión 1
• Los diez plugins que merecen la pena, cinco de ellos con capturas
• Los MCP que siguen siendo imprescindibles
• Los plugins que se quedan fuera y por qué

¿Cómo se extiende OpenCode 2? ¶

OpenCode tiene cuatro mecanismos de extensión: plugins, servidores MCP, Agent Skills y Custom Tools. De serie ya trae lectura, escritura y edición de ficheros, shell, tareas, subagentes y, desde la 2.0.27, worktrees de git.

1. Plugins: módulos en JavaScript o TypeScript que se enganchan a lo que pasa dentro del agente (el prompt, cada herramienta, los permisos, la shell) y pueden añadir herramientas, comandos y paneles.
2. Servidores MCP: herramientas externas que el agente invoca a través del Model Context Protocol.
3. Agent Skills: instrucciones que se cargan cuando hacen falta. Lo tienes explicado en la guía de Agent Skills para OpenCode, Claude Code y Cursor.
4. Custom Tools: herramientas propias definidas en tu proyecto.

Los plugins locales se cargan solos desde .opencode/plugins/ (proyecto) o ~/.config/opencode/plugins/ (global). Los de npm se declaran en la clave plugins de tu opencode.json (en la versión 1 era plugin, en singular). Cada entrada puede ser un paquete, un paquete con versión o un objeto con package y options:

{
  "$schema": "https://opencode.ai/config.json",
  "plugins": [
    "opencode-goal-plugin@0.11.1",
    { "package": "./tools/guardia.ts", "options": { "modo": "estricto" } }
  ]
}

Fija la versión. Varios autores avisan de lo mismo: OpenCode resuelve una entrada sin versión una sola vez, la guarda en caché y no vuelve a buscar actualizaciones. Si escribes solo el nombre, te quedas con la primera versión que se instaló.

Para los plugins globales tienes un comando propio:

opencode plugin add <paquete>     # instala un plugin global
opencode plugin list              # lista los instalados (--builtin para ver los de serie)
opencode plugin check             # busca actualizaciones
opencode plugin update            # actualiza
opencode plugin remove <paquete>  # desinstala

Ojo con check: en la 2.1.2 busca versiones nuevas, no te dice si el plugin carga. Para eso arranca con logs y busca la línea loading plugin:

opencode run --standalone --print-logs --log-level info "Di ok" 2>&1 | grep "loading plugin"

Si un plugin no aparece ahí, o aparece un failed to load plugin, no está funcionando.

💡 Si vienes de Claude Code, piensa en los plugins de OpenCode como hooks con más alcance: pueden cambiar comandos antes de que se ejecuten, decidir permisos, añadir herramientas y comandos, y dibujar paneles en la interfaz.

¿Funcionan los plugins de OpenCode 1 en OpenCode 2? ¶

No. La guía oficial de migración lo dice claro: los plugins de la versión 1 no se ejecutan en la 2. Y fallan sin hacer ruido. Según la prueba de migración publicada en DEV Community, OpenCode 2 arranca con normalidad, deja un aviso en el log y descarta el plugin.

Si ese plugin bloqueaba comandos peligrosos o tapaba secretos, después de actualizar te quedas sin esa protección y la interfaz no te avisa.

La API cambia de arriba abajo: el paquete pasa de @opencode-ai/plugin a @opencode/plugin, cada plugin se define con Plugin.define({ id, setup(ctx) }) y los hooks se registran a través del contexto (ctx.tool, ctx.session, ctx.permission…). Tienes la tabla completa de equivalencias en qué trae OpenCode 2.

Antes de dar por buena la migración:

1. Haz inventario: los plugins de opencode.json y los de las carpetas plugins/.
2. Pasa opencode-v2-ready (pip install opencode-v2-ready y opencode-v2-ready check). Lee tu configuración y te dice qué paquetes dependen ya de la API nueva. Es un proyecto de la comunidad y se fija en las dependencias, así que úsalo como primer filtro, no como veredicto.
3. Arranca con --print-logs y confirma la línea loading plugin de cada uno.
4. Prueba cada protección a mano: pide al agente justo lo que el plugin debería impedir y mira si lo impide.
5. Reescribe tus plugins propios con la API nueva.

🛡️ Mientras un plugin de seguridad no tenga versión para la 2, cubre el hueco con las reglas de permissions de OpenCode 2. Por ejemplo, { "action": "shell", "resource": "rm -rf *", "effect": "deny" }. No es un sandbox, pero evita el susto más habitual.

Primero, lo que trae de serie

Antes de llenarlo de plugins, exprime lo que OpenCode ya hace

Plan, revisión, subagentes y MCP aplicados a dos proyectos: un CLI que lee GitHub Trending y un juego web desplegado en Vercel. Después sabrás qué hueco tapa cada plugin.

Asomarme a la guía →

24 vídeos cortos · un CLI y un juego web

¿Qué plugins de OpenCode 2 merecen la pena? ¶

Estos son los diez que pasan el corte: funcionan con la API de la versión 2 y resuelven un problema que vas a tener. He probado a fondo los cinco primeros y el resto los he cargado en la misma instalación para confirmar que arrancan.

opencode-goal-plugin: un objetivo y no para hasta cumplirlo ¶

Le das un objetivo con /goal y el plugin lo mantiene en el contexto. Cada vez que el agente termina un turno sin haberlo cumplido, le manda otro para que siga. Para cuando el objetivo se cumple, cuando el agente dice que está bloqueado o cuando se agota alguno de los límites que tú fijas.

Es el patrón que ya contamos para Codex y Claude Code en cómo usar /goal para que tu agente termine lo que empieza, ahora como plugin de OpenCode 2. Lo mejor es que no se fía del modelo: para cerrar el objetivo exige una línea de evidencia, y si el modelo dice «terminado» sin ella, el plugin rechaza el cierre.

Lo probé con un proyecto de tareas en Node con tres tests en rojo:

/goal haz que pasen todos los tests de npm test sin tocar los tests --max-turns 8

GLM-5.3 encontró los tres fallos en src/tareas.js, los arregló, volvió a pasar los tests en el turno de continuación y cerró el objetivo con la evidencia. Coste estimado: 4 céntimos.

Galería · 3 imágenes

opencode-goal-plugin en OpenCode 2.1.2

Ampliar

1 / 3 · Fija el objetivo y sus límites

1Fija el objetivo y sus límites 2Vuelve a poner al agente a trabajar 3Cierra el objetivo con pruebas

Se instala con una línea en opencode.json. En OpenCode 2 el plugin registra /goal solo; si vienes de la versión 1, borra el command.goal que tuvieras en la configuración, porque taparía el del plugin:

{ "plugins": ["opencode-goal-plugin@0.11.1"] }

Además de lanzar objetivos tienes /goal status, /goal pause, /goal resume y /goal history, y puedes añadir criterios de éxito y restricciones con --success y --constraints. El autor avisa de que depende de hooks experimentales de OpenCode: antes de dejarlo trabajando solo una tarde, pruébalo con tu versión y tu proveedor.

Plannotator: el plan del agente se revisa como un documento ¶

Plannotator cambia cómo revisas lo que propone el agente Plan. Cuando el agente tiene un plan, llama a la herramienta submit_plan y el plan se abre en el navegador. Ahí seleccionas el trozo que no te convence, escribes un comentario y pulsas Send Feedback. El comentario vuelve a la sesión como respuesta de la herramienta y el agente rehace el plan. Si el plan te vale, Approve lo aprueba y se pasa a Build.

En la prueba le pedí al agente Plan que añadiera fechas límite a las tareas. Antes de escribir el plan me hizo tres preguntas, lo envió a revisión y yo le marqué una frase: quería que vencidas() recibiera la fecha de referencia como parámetro para poder testearla. La versión 2 del plan llegó con vencidas(ahora = new Date()).

Galería · 3 imágenes

Plannotator en OpenCode 2.1.2

Ampliar

1 / 3 · Comentas el plan en el navegador

1Comentas el plan en el navegador 2El comentario vuelve a la sesión 3Llega la versión 2 del plan

{ "plugins": ["@plannotator/opencode"] }

Por defecto submit_plan solo está disponible para el agente Plan, así que Build no lo llama por su cuenta. También trae /plannotator-review para revisar los cambios del código, /plannotator-annotate para anotar ficheros o URLs y /plannotator-last para anotar la última respuesta del agente. Si trabajas en un servidor remoto, el plugin escribe la URL de la revisión en la propia conversación para que la abras tú.

OpenCode Quota: tu cuota a la vista mientras trabajas ¶

Si trabajas con varios proveedores, este te ahorra abrir sus paneles. OpenCode Quota enseña cuánto te queda del plan de cada proveedor y cuánto has gastado en tokens, sin pasar por el modelo: los comandos no ocupan contexto.

Añade un bloque a la barra lateral de la sesión, /quota para ver las ventanas de tu plan y una familia de comandos /tokens_* (hoy, por días, por semanas, por sesión o entre dos fechas) que calcula el gasto con el historial local de OpenCode y los precios de models.dev. Soporta una lista larga de proveedores: Anthropic, OpenAI, GitHub Copilot, OpenRouter, OpenCode Go y Zen, Ollama Cloud, DeepSeek, Kimi, Z.ai y más.

Galería · 3 imágenes

OpenCode Quota en OpenCode 2.1.2

Ampliar

1 / 3 · La cuota en la barra lateral

1La cuota en la barra lateral 2/quota y las ventanas del plan 3/tokens_today: el gasto del día

Se instala con npx @slkiser/opencode-quota init o añadiendo @slkiser/opencode-quota a la lista de plugins. Necesita OpenCode 2.0.16 o posterior. Un detalle que me costó un rato: el plugin busca la clave de Ollama Cloud en la variable OLLAMA_API_KEY, no en la que hayas definido para el proveedor. Si /quota te dice que no hay datos, abre /quota_status: lista cada proveedor y por qué no está disponible.

DCP: el agente comprime lo que ya no necesita ¶

DCP (Dynamic Context Pruning) ataca el problema de las sesiones largas. Cada salida de herramienta que el agente ya no necesita (un fichero leído hace veinte turnos, la salida de unos tests que ya pasan) sigue viajando en cada petición. DCP las poda y, cuando se lo pides con /dcp-compress, le da al modelo una herramienta compress para resumir la parte de la conversación que ya está cerrada.

En la prueba, después de arreglar los tests, una sola compresión sacó del contexto unos 5.800 tokens con una relación de 6 a 1: diez salidas de herramientas y siete mensajes sustituidos por un resumen de unos 990 tokens.

Galería · 3 imágenes

DCP en OpenCode 2.1.2

Ampliar

1 / 3 · /dcp-compress resume lo cerrado

1/dcp-compress resume lo cerrado 2Stats: lo que te has ahorrado 3Context: qué queda en el contexto

{ "plugins": ["@tarquinen/opencode-dcp@3.2.0"] }

/dcp abre un panel con las vistas Context y Stats. A mí esas vistas solo me respondieron al ratón, no a las flechas. La configuración vive en ~/.config/opencode/dcp.jsonc (o en .opencode/dcp.jsonc para un proyecto) y ahí decides qué herramientas no se podan nunca y si quieres modo manual. Ojo con el nombre: el paquete actual es @tarquinen/opencode-dcp; el antiguo opencode-dynamic-context-pruning es de la época de la versión 1.

sesh: todas tus sesiones, de todos tus proyectos ¶

La lista de sesiones de OpenCode solo enseña las del proyecto en el que estás. sesh las enseña todas, agrupadas por carpeta, con un buscador que mira también dentro de las conversaciones. Viene bien para lo de «esto ya se lo pregunté al agente en otro proyecto, ¿dónde?».

Pulsas option+o y tienes el selector. Escribes y filtra por título, carpeta o texto de la conversación. option+p enseña los últimos mensajes de la sesión marcada, Enter la abre en su carpeta, ctrl+f crea una copia y ctrl+s la fija arriba.

Galería · 3 imágenes

sesh en OpenCode 2.1.2

Ampliar

1 / 3 · Todas las sesiones por carpeta

1Todas las sesiones por carpeta 2Busca dentro de las conversaciones 3Vista previa antes de abrir

{ "plugins": ["opencode-sesh@2.1.1"] }

Trae además un comando sesh para la terminal, sin abrir OpenCode, que se instala con npm install -g opencode-sesh y sesh install.

Context7: documentación de la versión que usas ¶

Context7 le da al agente la documentación de la versión exacta de cada librería, sacada de la fuente oficial. Es la forma más directa de que deje de usar APIs que ya no existen: si tu proyecto usa Next.js 15, el agente consulta la documentación de la 15 antes de escribir el middleware.

Upstash publica un plugin oficial para OpenCode 2, @upstash/context7-opencode, que configura el servidor MCP de Context7 y una skill de documentación. En mi instalación cargó sin problemas, pero el servidor MCP pidió iniciar sesión antes de responder. También puedes seguir usando npx ctx7 setup --opencode.

Supermemory: memoria entre sesiones ¶

opencode-supermemory guarda preferencias, convenciones y conocimiento del proyecto entre sesiones: que los tests van en __tests__/, que el ORM es Drizzle y no Prisma, que los imports usan el alias @/. Se lo explicas una vez y lo recuerda.

Desde finales de septiembre el mismo paquete funciona en las dos versiones. En la 2.1.2 cargó y el agente tenía sus herramientas supermemory y supermemory_recall. Necesitas una cuenta de Supermemory, y conviene vigilar un bug abierto: como OpenCode 2 sirve varias carpetas desde el mismo servidor, las herramientas solo quedan registradas en la última carpeta que se cargó.

Notifier: un aviso cuando el agente te necesita ¶

opencode-notifier manda una notificación del sistema, con sonido si quieres, cuando el agente pide permiso, termina o falla. Encaja muy bien con OpenCode 2, donde el servidor sigue trabajando en segundo plano aunque cierres la terminal. El paquete es @mohak34/opencode-notifier y soporta las dos versiones.

Landstrip: la shell del agente, en un sandbox ¶

Landstrip mete los comandos que lanza el agente en un sandbox del sistema operativo. Por defecto deja escribir en el proyecto, bloquea la escritura en ficheros sensibles y corta la red. Y es estricto: si el sandbox no puede funcionar, no deja ejecutar nada, ni aunque apruebes la herramienta.

Es el sustituto que propongo para opencode-vibeguard, que no tiene versión para la 2. Se instala con opencode plugin add opencode-landstrip, añade el indicador sandbox a la barra de estado y el comando /landstrip para gestionarlo. Una advertencia honesta: en mi entorno de pruebas, un contenedor sin soporte completo de FUSE, el plugin cargó pero los comandos se quedaban colgados. Antes de confiar en él, comprueba que funciona en tu máquina.

opencode-queue: tareas en cola que se lanzan solas ¶

opencode-queue te deja encolar prompts, comandos / y comandos de shell que se lanzan cuando el agente termina lo que está haciendo. /queue texto (o /q) añade una entrada, /queue:list las enseña y /queue !npm test deja un comando para después. Cada entrada recuerda el agente, el modelo y los ficheros adjuntos con los que la creaste. Necesita OpenCode 2.0.27 o posterior.

¿Qué herramientas MCP merecen la pena? ¶

Los servidores MCP no dependen de la API de plugins, así que el salto a la versión 2 no los rompe: solo cambia dónde se configuran. Los dos con más impacto siguen siendo Chrome DevTools MCP y Firecrawl.

Chrome DevTools MCP: ojos en el navegador ¶

Chrome DevTools MCP, del equipo de Chrome, le da al agente acceso real al navegador: DOM, consola, red, trazas de rendimiento, capturas, auditorías Lighthouse y automatización. Le puedes pedir que abra tu app, revise errores de la consola, mire una petición que falla o compruebe que un cambio visual ha quedado bien.

En OpenCode 2 los servidores van dentro de mcp.servers y el comando local es un array:

{
  "mcp": {
    "servers": {
      "chrome-devtools": {
        "type": "local",
        "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
      }
    }
  }
}

Si haces frontend, este va en primera fila.

Firecrawl: scraping dentro del agente ¶

Firecrawl extrae información estructurada de páginas web y la guarda en .firecrawl/ sin llenar el contexto del agente. Sirve para documentación que no está en Context7, precios de servicios o cualquier página que necesites como entrada de una tarea. El paquete actual, @firecrawl/opencode, soporta las dos versiones.

¿Cuándo MCP y cuándo plugin? ¶

• Un plugin se engancha a lo que pasa dentro de OpenCode: el prompt, cada herramienta, los permisos, la shell. Cambia cómo se comporta el agente y puede dibujar en la interfaz.
• Un MCP expone herramientas nuevas que el agente puede invocar. Amplía lo que el agente sabe hacer y sirve para cualquier agente, no solo OpenCode.

🔑 Regla práctica: si necesitas un servicio externo en tiempo real (navegador, API, base de datos), MCP. Si necesitas cambiar cómo trabaja el agente (seguir hasta acabar, podar el contexto, revisar el plan), plugin.

Construye agentes con criterio

Cómo arquitecturar un agente de IA en 6 niveles (con OpenCode dentro)

OpenCode brilla cuando entiendes la arquitectura por debajo. Masterclass con los 6 niveles — tools, guardarraíles, memoria, skills, MCP y orquestación — y un sistema multiagéntico revisado con Open Code y LLM as Judge.

Entrar a la masterclass →

Masterclass en directo · 6 niveles de arquitectura

¿Y si vienes de Claude Code? ¶

En Claude Code un plugin suele venir empaquetado: instalas desde un marketplace una unidad con agentes, skills, comandos, hooks y servidores MCP dentro. Lo tienes en los 15 plugins más populares de Claude Code.

En OpenCode el enfoque es más code-first: un plugin es un módulo que sueltas en .opencode/plugins/ o instalas desde npm. Con la versión 2 las dos ideas se acercan. El primer plugin oficial de la nueva arquitectura, el de Figma que llegó con la 2.0.28, trae su conexión MCP y seis skills dentro. Y un plugin de OpenCode 2 ya puede registrar comandos, agentes, skills y servidores MCP.

MCP y Agent Skills son estándares compartidos, así que Context7 o Chrome DevTools MCP funcionan en los dos con distinta configuración.

El caso Claude: ¿se puede usar la suscripción Max en OpenCode? ¶

OpenCode tenía un plugin integrado, opencode-anthropic-auth, para usar la suscripción Pro o Max de Claude desde la terminal. En enero de 2026 Anthropic bloqueó el acceso OAuth desde herramientas de terceros, y el 19 de febrero actualizó sus condiciones para prohibir de forma explícita usar los tokens OAuth de Free, Pro y Max fuera de Claude Code o claude.ai: “Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service — including the Agent SDK — is not permitted and constitutes a violation of the Consumer Terms of Service”. Ese mismo día, Dax Raad, uno de los responsables de OpenCode, retiró del repositorio todo el código de autenticación con Claude citando “anthropic legal requests”.

Las opciones que quedan para usar Claude con OpenCode:

1. Claves de API directas: pagas por tokens, sin tope mensual fijo.
2. OpenCode Zen y OpenCode Black: las pasarelas de OpenCode, con su propia facturación. Black tiene planes de 20, 100 y 200 dólares al mes.
3. Meridian (antes opencode-claude-max-proxy): un proxy local de la comunidad que traduce las peticiones a llamadas del Agent SDK con tu sesión de Claude Max. El plugin opencode-with-claude, que lo arranca y lo gestiona por ti, ya soporta OpenCode 2.

⚠️ Meridian vive en una zona gris. Usa el Agent SDK oficial, pero las condiciones de febrero de 2026 nombran el Agent SDK de forma expresa, y hay usuarios que cuentan bloqueos de cuenta por usar OAuth en herramientas no autorizadas. Si vas por esta ruta, hazlo sabiendo que Anthropic puede cambiar las reglas otra vez.

¿Qué proyectos van más allá del plugin? ¶

Hay proyectos que no añaden una herramienta, sino que cambian cómo trabajas con OpenCode. No los he revisado para esta actualización, así que antes de instalarlos mira en su repositorio si ya soportan la versión 2.

• oh-my-openagent (antes oh-my-opencode): convierte OpenCode en un equipo de agentes especializados que planifican, ejecutan y validan, con enrutamiento de modelos por tipo de tarea. Tiene mucha opinión y mucha configuración; no lo instales mientras aprendes OpenCode. Lo contamos a fondo en Oh My OpenCode. Su fork ligero, oh-my-opencode-slim, sí soporta la versión 2 y documenta lo que la API todavía no deja hacer.
• ocx: gestor de extensiones con perfiles aislados por proyecto o por máquina.
• opencode-background-agents: delegación de tareas de investigación en segundo plano, con el resultado en markdown.
• Vibe Kanban: un tablero para ver qué hace cada agente cuando lanzas varios a la vez. Si buscas algo con feedback de CI y revisión de código, mira Agent Orchestrator de Composio.
• OpenChamber: interfaz web, de escritorio y extensión de VS Code alrededor de OpenCode. Si quieres la oficial, tienes OpenCode Desktop.
• opencode.nvim: pasa al agente el buffer, la selección y los diagnósticos de LSP, y revisas los cambios en un diff dentro de Neovim.

¿Qué stack montarías para empezar? ¶

1. Base: Context7 y Chrome DevTools MCP si haces frontend.
2. Para tareas largas: opencode-goal-plugin y DCP.
3. Para revisar antes de que toque nada: Plannotator.
4. Para no llevarte sustos con la factura: OpenCode Quota.
5. Si saltas entre proyectos: sesh y Notifier.

Añádelos de uno en uno y comprueba en el log que cada uno carga. Cada plugin y cada MCP suma, y un agente con diez herramientas que no usa trabaja peor que uno con tres que sí usa.

¿Qué errores evitar al configurar el ecosistema? ¶

Instalar todo a la vez. Cada plugin y cada MCP consume contexto o añade comportamiento. Si metes diez el primer día, no sabrás cuál te está ayudando y cuál estorba.

Dar por hecho que un plugin funciona porque OpenCode arranca. Un plugin de la versión 1 se descarta sin avisar. Mira el log y prueba lo que hace el plugin.

Dejar los plugins sin versión. OpenCode no vuelve a buscar la última versión de una entrada sin fijar. Fija la versión y súbela tú.

Olvidar que los plugins viven en el servidor. En OpenCode 2 la terminal, el escritorio y la web se conectan a un único servidor en segundo plano, y los plugins se cargan ahí. Después de tocar la configuración, opencode reload. Y si un plugin se queda atascado instalándose, el servidor en segundo plano también: opencode service restart.

Ignorar los avisos sobre condiciones de uso. Lee la sección del caso Claude antes de usar plugins de autenticación con suscripciones.

¿Cómo crear tu propio plugin? ¶

En OpenCode 2 un plugin es un módulo que exporta Plugin.define con un id y una función setup. Lo dejas en .opencode/plugins/ y OpenCode lo carga al arrancar. Este es el clásico que impide leer los .env:

import { Plugin } from "@opencode/plugin"

export default Plugin.define({
  id: "mi-equipo.env-protection",
  async setup(ctx) {
    await ctx.tool.hook("execute.before", (event) => {
      const args = JSON.stringify(event.input ?? {})
      if (args.includes(".env")) {
        throw new Error("Acceso a .env bloqueado por política de seguridad")
      }
    })
  },
})

Lanzar un error dentro del hook bloquea la llamada, y el id tiene que ser estable porque OpenCode lo usa para aislar el almacenamiento del plugin. El proceso completo, con el hook de permisos, herramientas propias, comandos y almacenamiento, está en la guía para crear plugins en OpenCode 2.

¿Qué plugins de OpenCode 1 se quedan fuera? ¶

Revisión del 22 de octubre de 2026. Estos plugins estaban en versiones anteriores de esta guía. En esa fecha no tenían versión para la API de plugins de OpenCode 2, o no conseguí que cargaran en la 2.1.2. Los dejo como reseña: si alguno publica versión para la 2, volverá a la lista.

opencode-type-inject: tipos de TypeScript inyectados al vuelo ¶

opencode-type-inject añadía las firmas de tipos a las lecturas de ficheros y avisaba de errores de tipos al escribir, para que el agente respetara las interfaces de tu proyecto en lugar de inventarlas. No encontré versión para la 2.

opencode-pty: procesos interactivos bajo control ¶

opencode-pty dejaba al agente controlar procesos que no terminan, como un npm run dev o un REPL, leyendo su salida y mandándole entrada. Publica una entrada opencode-pty/v2 desde septiembre, pero en la 2.1.2 la instalación se quedaba colgada y el plugin no llegó a cargar.

opencode-vibeguard: redacción de secretos antes de enviar al LLM ¶

opencode-vibeguard sustituía claves, tokens y datos personales por marcadores antes de mandar el contexto al proveedor, y los restauraba en local. Sigue siendo solo para la versión 1. Mientras tanto, cubre el hueco con las reglas de permissions y con Landstrip.

Otros plugins de la versión 1 ¶

Preguntas frecuentes ¶

¿Cuáles son los mejores plugins para OpenCode 2? ¶

Los cinco que he probado con capturas en la 2.1.2: opencode-goal-plugin para que el agente siga hasta cumplir un objetivo, Plannotator para revisar el plan, OpenCode Quota para la cuota y el gasto, DCP para podar el contexto y sesh para tus sesiones. Completan la lista Context7, Supermemory, Notifier, Landstrip y opencode-queue.

¿Funcionan los plugins de OpenCode 1 en OpenCode 2? ¶

No. OpenCode 2 tiene una API de plugins nueva (@opencode/plugin, con Plugin.define y un setup que recibe el contexto) y los plugins de la versión 1 no se ejecutan. OpenCode no falla al arrancar: deja un aviso en el log y descarta el plugin. Algunos paquetes, como opencode-supermemory u opencode-goal-plugin, soportan las dos versiones.

¿Cómo sé si un plugin ha cargado en OpenCode 2? ¶

Arranca con opencode run --standalone --print-logs --log-level info "Di ok" y busca loading plugin con el nombre del paquete. opencode plugin check no sirve para esto: en la 2.1.2 busca actualizaciones.

¿En qué se diferencian los plugins de OpenCode de los de Claude Code? ¶

En Claude Code los plugins vienen empaquetados y se instalan desde un marketplace, como ves en los 15 plugins más populares de Claude Code. En OpenCode un plugin es un módulo JavaScript o TypeScript que sueltas en .opencode/plugins/ o instalas desde npm. Con la versión 2 un plugin ya puede traer comandos, agentes, skills y servidores MCP, así que la diferencia se ha reducido.

¿Qué diferencia hay entre un plugin y un MCP en OpenCode? ¶

Un plugin se engancha a lo que pasa dentro del agente (prompts, herramientas, permisos, shell) y cambia su comportamiento. Un MCP expone herramientas nuevas para interactuar con servicios externos y funciona en cualquier agente compatible.

¿Cuántos plugins puedo instalar a la vez? ¶

No hay un límite técnico, pero cada plugin y cada MCP suma contexto o comportamiento. Empieza con dos o tres y añade según los necesites, comprobando en el log que cargan.

¿Context7 funciona solo con OpenCode? ¶

No. Context7 funciona con Claude Code, Cursor, Gemini CLI y cualquier agente compatible con MCP. Para OpenCode 2 tienes el plugin oficial @upstash/context7-opencode o npx ctx7 setup --opencode.

¿Los plugins funcionan igual en la app de escritorio y en la terminal? ¶

Sí. En OpenCode 2 los plugins se cargan en el servidor, al que se conectan la terminal, la app de escritorio y la web. Lo que cambia son los paneles: los que dibujan en la terminal (como la barra lateral de OpenCode Quota) no aparecen en la web.

¿Qué pasa si un plugin deja de mantenerse? ¶

Pasa, y con el cambio de versión ha pasado a muchos. Antes de depender de un plugin, revisa la actividad del repositorio, los issues abiertos y si declara compatibilidad con la versión de OpenCode que usas.

¿OpenCode soporta skills al estilo de Claude Code? ¶

Sí. OpenCode tiene soporte nativo para Agent Skills con ficheros SKILL.md en .opencode/skills/ o ~/.config/opencode/skills/, y un plugin de OpenCode 2 también puede registrar skills.

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter