OpenCode v2.2.6: MCP compartido, worktrees y ejecuciones archivadas

Quien ejecuta OpenCode en varios repositorios a la vez siente el problema: cada proyecto abre su propia conexión al mismo servidor MCP, consume más procesos y tarda más en iniciar. La v2.2.6 lo resuelve con pooling de conexiones y añade dos comandos nuevos que ayudan en automatización y en CI.

En este artículo vas a ver:

• Cómo funciona el MCP compartido entre proyectos
• Cómo ejecutar una sesión en un worktree nuevo con opencode run -w
• Cómo archivar runs de CI con la flag --archived
• Otras mejoras de la release y cómo probar hoy

Qué cambió en OpenCode v2.2.6

La release 2.2.6 de OpenCode trae cinco puntos destacados principales. El primero es el compartir conexiones MCP entre proyectos que usan la misma configuración. El segundo es la posibilidad de que los plugins de interfaz añadan temas de color, acciones en bloques de código y componentes nativos de configuración. El tercero es un dock de compositor para celulares y tablets. El cuarto es la ejecución de runs en worktrees de git. El quinto es el archivado automático de runs de CI.

Además de los destacados, la release trae mejoras en el núcleo, como warming de sesión por proveedor y modelo, una política de uso para búsqueda en la web, una VM experimental de bytecode para Code Mode y soporte para instalaciones de PowerShell 7 desde Microsoft Store en Windows.

MCP compartido entre proyectos

El compartir conexiones MCP es el cambio más útil para quien mantiene varios proyectos. Hasta ahora, cada proyecto abría su propia conexión al mismo servidor MCP. Con la v2.2.6, basta activar el pooling con pool: true en la configuración del servidor. Todos los proyectos con la misma configuración pasan a usar una única conexión.

El resultado práctico es menos procesos corriendo al mismo tiempo e inicio más rápido. Para quien usa servidores MCP pesados, como el de búsqueda o el de archivos, el ahorro de recursos se percibe.

Para activar, añade pool: true en la entrada del servidor MCP en el archivo de configuración de OpenCode. Luego, ejecuta OpenCode en dos proyectos diferentes y verifica que solo aparezca un proceso del servidor. Si el servidor requiere estado por proyecto, desactiva el pooling en ese caso.

Runs en worktree con opencode run -w

La flag --worktree, o -w, inicia una sesión en un worktree nuevo de git. Esto es útil cuando quieres probar un cambio sin tocar el árbol principal del proyecto. Basta ejecutar opencode run -w y OpenCode crea el worktree y comienza la sesión en él.

Si quieres elegir el nombre del worktree, usa --worktree=. La flag no puede combinarse con --continue ni con --session, porque la sesión nueva no tiene historial previo. Quien usa worktrees en CI puede crear un worktree por run y descartarlo al final.

Un flujo común es ejecutar opencode run -w "crie testes para o módulo X" y dejar que el agente trabaje en el worktree aislado. Si el resultado es bueno, integras la branch. Si no lo es, descartas el worktree sin ensuciar el proyecto principal.

Sesiones archivadas para runs de CI

La flag --archived crea la sesión ya archivada. Los runs de CI y los scripts automatizados dejan de aparecer en la bandeja de entrada y en las listas de sesión. Las sesiones archivadas también quedan ocultas en la interfaz de terminal y son ignoradas por --continue.

Esto resuelve un problema común: después de ejecutar decenas de agentes en CI, la lista de sesiones se llena de runs que nadie va a revisar. Con --archived, esos runs quedan fuera del camino, pero aún pueden consultarse cuando sea necesario.

Para usarlo, añade --archived al comando opencode run. En pipelines, combínalo con --format json para capturar la salida de forma estructurada. Recuerda definir timeout en los jobs de CI, porque OpenCode ahora espera a que terminen los comandos en segundo plano, subagentes y jobs de imagen antes de salir.

Otras mejoras que valen la pena probar

La release también cambia el comportamiento de opencode run en modo no interactivo. Ahora el comando espera a los comandos en segundo plano, subagentes y jobs de imagen que inició el prompt y deja que el modelo responda a los resultados antes de cerrarse. Mientras espera, imprime waiting for N background job(s). No hay límite de tiempo: un job que nunca termina, como un servidor de desarrollo, mantiene el run abierto hasta que presiones Ctrl+C o envíes SIGTERM. En CI, define timeout.

El manejo de SIGTERM también cambió. Ahora la señal cancela la sesión y los jobs en segundo plano y finaliza con código 143. Esto hace que OpenCode sea más predecible en pipelines que necesitan interrumpir ejecuciones.

También hay warming de sesión por proveedor y modelo, con modo interval: "auto" basado en el TTL de la caché. Y la política websearch.use para controlar el uso de búsqueda en la web. Quien quiera probar recursos experimentales puede activar todas las flags con OPENCODE_FLAGS=all o experimental.all_flags.

Cómo probar hoy

1. Actualiza OpenCode a la versión 2.2.6.
2. En dos proyectos con el mismo servidor MCP, añade pool: true y verifica la reducción de procesos.
3. Ejecuta opencode run -w "descreva a tarefa" en un repositorio con git y verifica el worktree creado.
4. Ejecuta opencode run --archived "tarefa de CI" y verifica que la sesión no aparezca en la lista principal.
5. En un pipeline, añade timeout y prueba el comportamiento con SIGTERM.

Si ya usas OpenCode con otros agentes, vale la pena comparar el flujo con el MCP server git y con el Claude Code 2.1.319, que también trabajaron en MCP y segundo plano.